[JDEV] jabberd patch

[Richard Dobson]

> 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