[JDEV] jabberd patch
richard at dobson-i.net
Wed Feb 26 18:17:37 CST 2003
> In fact when I shutdown my windows jabberd 1.4.2 with ctrl-c it doesn't
> say anything at all.. it just disconnects the socket.
Sure but the win32 server is not the best thing to judge by, it has
notorious problems, hopefully jabberd2 will solve them. Also that just
seems to be another implementation problem to me so doesn't strictly
have much bearing on these discussions.
> Look, I already quoted from the documentation that there can be more
> then one reason why a jabber-server would send a stream:error. What the
> description should be it doesn't say anywhere, nor should it because
> it's supposed to be a human readable description, it's not meant for
> letting your client distinguise what type of stream error it is.
Of course it shouldnt be used if you have an alternative, but at the
moment until the stream error code discussions have finalised we dont,
it is the only thing we can use to even remotely guess what is
happening, im not arguing that the protocol shouldn't be altered to
make it better using the error codes but we need a solution now for all
the misbehaving clients until jabber servers with the new protocol have
been deployed everywhere (possibly quite a long way off).
> Can you agree with me on this?
Yes but as ive said above we need to work with what we have at the
moment to solve the problems until servers with the updated protocol
have been widely deployed. So if you dont want to use the CDATA to
determine the reason for disconnection then we will just need to have
it so clients must not try auto-reconnecting when they get a stream
error followed by a stream end, but if the client gets an error code
(because they are using an updated server) they can use that to
determine if they can try auto-reconnecting, but if there is no error
code must not try to auto-reconnect (the way Exodus works).
> If you can then maybe you can also agree with me that according to the
> documentation there can be different causes, and that some clients will
> want to auto-reconnect in some of those cases.
Yes but if you dont want to use the CDATA to try and find out what the
error is we must just use the lowest denominator, and because at least
one reason for disconnection means you shouldn't reconnect if you get a
stream:error you must not reconnect.
>> But it doesnt just say error, it says and i quote:
> As far as I know jabberd 1.4.2 does this, yes. But it shouldn't make a
> difference what it says. Maybe jabberd2 says <stream:error>Replaced by
> another session: disconnected</stream:error></stream:stream>, it would
> make a lot more sense to me but in your world this would mean all the
> clients would be broken again?
Ah but hopefully we can get the stream error codes into jabberd2 before
it goes final so they can be used to reliably determine the reason for
> They only have this "bug" because the server doesn't let them know why
> they are disconnected. If Exodus fixes this with a hack that scans for
> "Disconnected" (wich I find hard to believe since it really *is* such a
> big hack) or if it simply doesn't reconnect at all on <stream:error>
> that probably work on jabberd 1.4.2 and maybe some others too, but it
> is and will be a hack that no other client has to have, *since it's a
> hack*. That's why the rest don't HAVE to manage, or should IMHO.
Exodus seems to fix this by just detecting stream:error's and not then
trying to reconnect which I think is perfectly reasonable for other
clients to do until stream:error codes are widely spread in servers,
but as ive said to solve the problem we need to handle it for all the
thousands of jabberd servers that are already deployed, not just wait
for the protocol change since that doesn't help the already deployed
> I think this is a bizare way of handeling things, and even if it would
> be a decent approach, it's surthenly not standardized or even
> documented for that matter(at least I haven't seen it anywhere). So
> again, it's a hack that works on jabber1.4.2 and maybe some others (or
> all known for all I care) but who knows what SecretRedmondJabberD and
> ObscureC64JabberD send back instead of "Disconnected". Maybe they even
> send "Disconnected" eg. when the sessionmanager goes down? Maybe some
> current implementions use "Disconnected" for more then just duplicate
> sessions? That would already break your hack.
Ah well since there are not very many different servers available that
have a significant deployment I dont see this as a problem, as since
most new servers will contain the stream:error codes being worked on
(i.e. the newer protocol specs) so it is really only the currently
deployed (legacy) servers we really need to worry about.
So overall I think we should just not auto-reconnect upon the reception
of a stream:error followed by a stream end, but if we receive an error
code (currently being worked on) in the stream:error which tells us the
reason we can use that to do different things.
> Proper error-codes and documented behaviour for closing a stream and
> rejecting login because of duplicate sessions is needed. A means of
> indicating that you don't want to "hijack" another session is nice too,
> since it increases functionality for all clients that want to implement
Yes I think some way of a client specifying that it doesn't want to
hijack an existing session is the best way to go rather than
standardizing the hack Wes has done, since once the anti-hijack is done
the hack is unnecessary and bad for other clients.
More information about the JDev