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

JD Conley jconley at winfessor.com
Thu Dec 16 17:46:10 UTC 2004

>   Direct presence probing sounds good in theory, i'm just worried
> some of the 'worst' case scenarios - all the examples have been of a
> single user in a single room. Lets look at this from a different
> Let have 100 people in a room, multiple rooms on a server, some people
> multiple rooms. Imagine the amount of traffic generated each time the
> server checks who is still available.

Actually worst case is a very active server with multiple rooms
containing nearly 1000 people (like you see in IRC at times).  The key
to the probe approach is that the server knows which endpoints have been
"active" and which have not.  In a MUC with a significant number of
users there will most often be a message sent within the idle timeout
interval of 5 or 10 minutes before probes are sent.  When one of the
endpoints are active it can be assumed the S2S engine will return a
stanza error if delivery is not successful.

>   Surely in the example that you have given, where the s2s link is
> and then regained, the client would still receive the
> If so, why couldn't the client simply re-issue the request to leave
> room, since it would be obvious that the previous attempt failed.

Well, s2s being lost and regained is a different matter.  S2S goes up
and down like a yo yo.  It's just a matter of it comes back up when
packets need to be routed there.  If it can't the client and the MUC
room should end up with service-unavailable error packets.  The most
likely cause would be that one of the servers went down, in which case
the error would be more fatal to that side of things.


More information about the Standards mailing list