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

Matt Tucker matt at jivesoftware.com
Wed Dec 15 21:56:09 UTC 2004


JD,

I agree with your thoughts. However, I see it a bit more broadly still.
:) 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 an
s2s connection goes down, the user's server may not be able to send an
"unavailable" directed presence to a foreign entity. Therefore, I think
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. If
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 behalf
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, cut
> 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
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig
> 



More information about the Standards mailing list