[Standards-JIG] Dead participants in MU-conf, JEP-0045

JD Conley jconley at winfessor.com
Wed Dec 15 22:24:37 UTC 2004

Since we're one-upping each other on generalization, this should really
include provisions for roster related presence, not just directed,
between S2S links.  If a user on a remote system is unreachable a server
needs to notify its local user (if presence subscriptions and privacy
lists allow) that the remote user is unavailable.

So who's going to start the XMPP list thread? :)


> -----Original Message-----
> From: standards-jig-bounces at jabber.org [mailto:standards-jig-
> bounces at jabber.org] On Behalf Of Matt Tucker
> Sent: Wednesday, December 15, 2004 1:56 PM
> To: Jabber protocol discussion list
> Subject: RE: [Standards-JIG] Dead participants in MU-conf, JEP-0045
> JD,
> I agree with your thoughts. However, I see it a bit more broadly
> :) This is really a question of how to implement directed presence
> across s2s. Section 5.1.4 of RFC3921 doesn't cover the s2s case with a
> lot of detail. However, it does say:
> "if the available resource from which the user sent the directed
> presence become unavailable, the user's server MUST broadcast that
> unavailable presence to the entity (if the user has not yet sent
> directed unavailable presence to that entity)."
> Normal behavior of s2s breaks the practicality of this contract -- if
> s2s connection goes down, the user's server may not be able to send an
> "unavailable" directed presence to a foreign entity. Therefore, I
> that all s2s implementations must try to honor the directed presence
> contract from foreign entities themselves. This could be done by:
>  1) Keeping track of all directed presences that come from a foreign
> server.
>  2) Ensure that every X minutes, there is some activity between the
> foreign entity that sent the directed presence and the local entity.
> there is not, perform a presence probe.
>  3) If it's determined that the foreign entity is no longer available,
> the local server should send an unavaialble directed presence on
> of the foreign entity.
> Such a system would solve the zombie user problem in MUC. It will also
> fix all other services that rely on directed presence, which is why I
> think this problem is an s2s one instead of something that should be
> worked around in MUC.
> Regards,
> Matt
> > -----Original Message-----
> > From: standards-jig-bounces at jabber.org
> > [mailto:standards-jig-bounces at jabber.org] On Behalf Of JD Conley
> > Sent: Wednesday, December 15, 2004 1:27 PM
> > To: Jabber protocol discussion list
> > Subject: RE: [Standards-JIG] Dead participants in MU-conf, JEP-0045
> >
> > > It is very simple to test: Setup C <-> S <-> MUC, enter a room,
> > the S
> > > <-> MUC cable, terminate C. S will notice, but is unable to
> > connect to
> > > MUC. Reboot S. MUC keeps the participant forever.
> >
> > But if MUC ever attempted to send a message or presence to C,
> > it would get an error back from its hosting server saying
> > that C is unreachable and should remove C from any rooms
> > they're in.  Obviously this isn't happening today in the MUC
> > service and server you are testing with, but it is how it
> > should be done.
> >
> > If the room is completely idle then this situation will never
> > be resolved.  If we take a step back from MUC we can see that
> > this problem is actually much more general.  I often have
> > orphaned users in my roster due to s2s connection problems.
> > This has been discussed many times.
> >
> > The solution I find the most appealing from a protocol and
> > implementation standpoint is to use presence probes.
> > However, the server hosting MUC should do the probing, not
> > the MUC service itself.  A server should track the sender and
> > recipient of all presence packets it receives.  It should
> > have a "watchdog" system which runs occasionally (every 5 or
> > 10 minutes) and probes any nodes on behalf of the original
> > recipient of the presence packet.  Of course, the probe would
> > only occur if the original sender hasn't been active for a
> > set period of time.  If any of the probes going to remote
> > servers through S2S can't be delivered the MUC service will
> > be notified with a presence error from the node on the other
> > server.  Any delivery related errors received should be
> > treated as unavailable presence by the server.  If any nodes
> > have not responded to probes in a certain timeframe they
> > should be treated as unavailable as well.  If the timeout was
> > the same as the watchdog interval this would happen with
> > every other run of the watchdog.
> >
> > JD

More information about the Standards mailing list