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:
<stream:error>Disconnected</stream:error></stream:stream>
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 disconnection.
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 servers.
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 it.
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.
Richard
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
