[ejabberd] Late unavailable presence can knock a newer session out of a chatroom
kcrosbie at ravenpack.com
Wed Nov 5 11:55:49 MSK 2008
Peter Saint-Andre wrote:
> Do you want the server to be smart about knowing which rooms the old
> resource was in? AFAIK ejabberd doesn't do that now, and it seems like
> an odd feature to me. Is there a reason why you're logging in with the
> same resource all the time? Perhaps I don't understand your scenario.
Here's a scenario and the reason why I'm running into this problem.
I have a custom client that's supposed to be constantly logged into a room.
The client is aggressive about reconnecting, so it does its best to
check that it is really connected to the server by sending presence
If there is a connectivity issue at some point, the client sees that it
can't communicate. It does not know anything about where the socket is
broken, so it closes the old XMPP stream and socket and tries to
When the network connection becomes active again, the client is able to
log back in. At this point ejabberd doesn't know anything about the
old socket having been closed yet, so I guess it tries to terminate it
gracefully. The client logs into the room as before and some time
later, ejabberd times out trying to terminate the old session, cleans up
the old session's rooms and the new session receives unavailable
presence from the room.
In http://xmpp.org/rfcs/rfc3921.html#session the protocol gives a
scenario where a session already exists for a resource and (assuming
case #1) sends a conflict stream:error to the old session, after which
it returns success to the new session. It's not really clear what
happens to any rooms the old session was in but it appears that
terminating the old session can take time. In ejabberd I'm finding
that after this time an unavailable presence is sent from the room for
the old session which may cause the new session to lose presence.
This doesn't seem right to me... I guess it could be solved as you said,
by making ejabberd aware of the rooms a session was in. The other way
is to make the protocol for replacing a session be:
1. New session authenticates.
2. Any cleanup on the old session is done. Unavailable presence is
sent to any rooms for the old session.
3. Old session is terminated gracefully.
4. Possibly in parallel to step 3 or before step 3 returns, return
success to the new session.
More information about the ejabberd