-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One of the problems we're having in deploying jabberd 2.0 is the 'c2s' disconnection issue. Right now, if a client sends invalid XML, the c2s disconnects from the router. This means that because of one bad client, ALL clients are bounced from the router.
So, I'm looking for some ideas on how to eliminate this major issue with the jabberd 2.0 'c2s'. I realize that validating the XML before passing it on to the router will impose some overhead, but as far as stability is concerned, it is a necessity. Hence my request for ideas.
I am willing to implement something, because without it, jabberd 2.0's 'c2s' is unusable in a large, enterprise deployment. Right now, this is the only complaint I've heard about Jabber and jabberd 2.0 ... frequent disconnections due to a client sending bad XML. Most of the problems are caused by duplicate attributes, especially in the case of messages that are stored offline.
Now before all the client devs start flaming away, understand that this is an issue that affects the stability and uptime of all jabberd 2.0 implementations. This is even more evident when the enterprise allows the users to choose their client. Since we cannot control the clients people use, shouldn't the server be more robust in the face of less than perfect clients?
Paul
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBYeXe42UCbgBTOCYRAgegAJ9wQ5LXqY0DRaldrFZqeFInmrlbkgCfaLMt oCfl+h6vga3oZYYoFSz6xAQ= =p5dQ -----END PGP SIGNATURE----- _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
