[JDEV] jabberd patch

[Tijl Houtbeckers]

"Richard Dobson" <richard at dobson-i.net> wrote on 26-2-2003 16:02:01:
>
>> "At the level of the stream" sounds pretty vague to me, but 
>> thankfully after that the example we're talking about is given. 
>> (Actually is sais "an attempt" to authenticate rather then "a 
>> succesfull attempt" even ;). 
>>  But look at the other examples given.. shutdowns.. internal errors. 
>>  In those cases I would want my client to reconnect till the server 
>>  is up again. You can tell me that this makes me a bad person/client 
>>  but I'm not gonna press the "connect" button 20 times a minute just 
>>  cause of that opinion :)
>
>Ah but do those error cases you talk about create errors of 
>"Disconnected" ??

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. 

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. 

Can you agree with me on this?

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. 

>
>> As you can see in the documentation (and this does happen in the real
>> world too) there are more cases in wich this can happen. It's not 
>> wise to tell clients to cripple themselves because we have a protocol
>> problem. Rather, let's fix the protocol problem and *then* bug the
>> client authors till they update it.
>>
>> I want my client to reconnect unless the server tells it there is a
>> good reason not to. Right now it does not, it's just sais there is an
>> "error".
>
>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? 
>
>Now AFAIK that error is only caused by other sessions causing the
>termination of an old session, so clients dont really have an excuse 
>even now to not handle that, Exodus manages it why cant the rest. So 
>as ive said any clients that exhibit the session fighting behaviour do 
>have a bug and need to be fixed since there is a way to properly 
>handle it. 

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. 

>> I agree with you that the "normal behaviour" regarding logging in 
>> with the same resource should not be changed. There should be proper 
>> "error"- codes or alternate elements for closing the stream though. 
>> Also it's not a bad idea for clients to expect the possiblity of a 
>> "409" when logging in on a server that has this enabled.. though 
>> it's unlikely to happen (any time soon) it won't make them worse 
>> clients for having it. 
>
>Yup proper error codes will help a lot, but at the moment the server 
>does effectively tell you what has gone wrong and gives you a 
>"Disconnected" error so clients dont really have any excuse not 
>handling it.

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.. 
 
>
>> Another alternative would be letting the client(s) decide wether they
>> want to take over an excisting session (or whether they want to allow
>> this). If we have proper error-codes for this such a system could
>> always be created later on without breaking or confusing excisting
>> clients.
>
>Ah yes I was thinking about this option, that could solve the previous
>gentlemans problem with sessions being terminated without altering 
>basic behaviours of the server for other clients. So maybe we need 
>some kind of option introduced into the auth so the client can tell 
>the server it doesnt want any existing sessions terminated if they 
>exist, I think this is the best option to solve the problem for all 
>parties involved. 

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. 


-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands