ejabberd - Comments for "duplicate login"

Good news: fixed on SVN.

mfoss — Tue, 22 Nov 2005 20:50:27 +0000

Good news: fixed on SVN.

Feature request added to Bugzilla

mfoss — Thu, 27 Oct 2005 22:51:46 +0000

I've formalized this feature request sending this to ejabberd's Bugzilla:
Bug 170: Send a warning when the session is replaced.

http polling issue

A2Jay — Wed, 26 Oct 2005 12:26:25 +0000

Thanks for your prompt reply. I thought that I had missed a critical point with http polling connections in ejabberd. I think there should be a way to inform the client that it has been disconnected due to a login with the same account/resource credentials. If we follow the JEP, I think that either a server error (-1:0) or bad request(-2:0) should be sent; then again it would depend on you guys how and what to send. I think it should be easy enough to check this for the client to determine that its session is already invalid.

Hmm, seems like we found a crucial bug in http polling implementation here. Will be waiting for updates on this thread. Thanks!

You're right! If using http-poll, there's no report

mfoss — Wed, 26 Oct 2005 10:10:24 +0000

You're right! If using http-poll, the client will not be informed in any way. I tried it with Tkabber, that supports http-poll, and since the first client does not receive any XMPP packet, and is not connected using a TCP socket, he does not know he is disconnected.

I'll ask Aleksey about the subject, and submit it to bugzilla. But even if a patch is available, and included in SVN, and the next ejabberd release is published in some months, it will take more time for public servers already deployed to update to the latest versions.

I'll post here updates on this subject.

duplicate login

A2Jay — Wed, 26 Oct 2005 08:38:13 +0000

Thanks for your reply. When you mean that the socket was closed by the server, do you mean that this assumes I'm connected via a persistent connection through port 5222, right? But what if I connect via http polling, what does ejabberd do? Does it send server error(ID=-1:0) or bad request(ID=-2:0) to indicate that my http polling session is discontinued?

In case of conflict, the socket is closed

mfoss — Tue, 25 Oct 2005 14:32:43 +0000

This is the full paragrgraph, with some lines bold:

If there is already an active resource of the same name, the server MUST either (1) terminate the active resource and allow the newly-requested session, or (2) disallow the newly-requested session and maintain the active resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1. In case #1, the server SHOULD send a stream error to the active resource, terminate the XML stream and underlying TCP connection for the active resource, and return a IQ stanza of type "result" (indicating success) to the newly-requested session. In case #2, the server SHOULD send a stanza error to the newly-requested session but maintain the XML stream for that connection so that the newly-requested session has an opportunity to negotiate a non-conflicting resource identifier before sending another request for session establishment.

It seems ejabberd prefers case #1. In that case, ejabberd SHOULD:

send a stream error to the active resource,
terminate the XML stream
(terminate the) underlying TCP connection for the active resource,
and return a IQ stanza of type "result" (indicating success) to the newly-requested session.

If you use Tkabber on the first connection and enable debugging, this will be reported by Tkabber:

10/25 16:05:40 jlib         (jlib::inmsg) (1) ''
10/25 16:05:40 jlib         error (jlib::inmsg) Socket is closed by server. Disconnecting..

So the TCP socket connection is closed, but no XMPP or XML message is received. This behaviour is in compliance with the RFC since that report messages are not required, they are recommended.

There was no feedback from ejabberd that I could use for notification that my login was disconnected because of a second login of the same account and resource. [...] how do I know that ejabberd disconnected my first login when I do a second login?

You know that ejabberd disconnected your session because the socket was closed by the server. I guess it would be more client-friendly if the server informs with a 'conflict stream error' message, too.

But anyway, your client must be able to handle inadverted socket closing, not only in this particular case, but others too. Even if ejabberd implements the report message, your client would have the same problem with other Jabber servers that do not follow the 'SHOULD'. And what if the server does a restart, or you loose connection to internet? The Jabber client must know that the connection was lost, and the session was closed.