[jdev] jabberd 2.0 c2s -- an issue
Paul Curtis
pfc at terrapin.com
Mon Oct 4 19:07:59 CDT 2004
-----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-----
More information about the JDev
mailing list