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

Heiner Wolf wolf at bluehands.de
Wed Dec 15 20:26:51 UTC 2004


>Is it not possible for your s2s to solve this?  Just periodically reconnect to 
>all the servers that have supposedly delivered online presence, and maybe 
>even issue a presence probe (which should work for directed presence in the 
>case of MUC, right?).  If the server is not responding, your side will know 
>it, and you can delete the participant.

This is exactly what I propose. I called it MUC-ping with jabber:iq:version, You call it "presence probe". My proposal is to add this to mu-conference and add it to the JEP as a hint for everyone.

>True, it is possible for the other server to be confused about the state of 
>his own participant, and might respond to the presence probe with a 
>successful online state when the contact is really a zombie.  But the TCP 
>timeout of that c2s connection will eventually inform the server of the true 
>state.  Yes, it is a long time, generally 20 minutes or so, but at least it 
>will be resolved.  It is s2s that up until now had no resolution, but you can 
>solve this one on your side.

As I wrote this is not about the c2s connection and it's timeouts. I have zombies for a week, because a server managed to connect to the MUC-server, delivered room-presence-available. The client went offline, the server noticed, but it failed to connect to the MUC server. So it did not deliver the room-presence-unavailable. 

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. 

hw
--
Dr. Klaus H. Wolf
bluehands GmbH & Co.mmunication KG
http://www.bluehands.de/people/hw
+49 (0721) 16108 75
--
Jabber enabled Virtual Presence on the Web: http://www.lluna.de/
Open Source Future History: http://www.galactic-developments.com/



More information about the Standards mailing list