[JDEV] jabberd patch
thoutbeckers at splendo.com
Wed Feb 26 09:25:44 CST 2003
"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
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
>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?
>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
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
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
>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
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
Software Engineer @ Splendo
More information about the JDev