[Standards-JIG] Dead participants in MU-conf, JEP-0045
jabber at dsutton.legend.uk.com
Thu Dec 16 15:09:29 UTC 2004
Direct presence probing sounds good in theory, i'm just worried about 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 angle. Let have 100 people in a room, multiple rooms on a server, some people in multiple rooms. Imagine the amount of traffic generated each time the server checks who is still available.
Surely in the example that you have given, where the s2s link is lost and then regained, the client would still receive the messages/presences? If so, why couldn't the client simply re-issue the request to leave the room, since it would be obvious that the previous attempt failed.
--- Included Message ---
On Thu, Dec 16, 2004 at 02:14:57AM -0500, Justin Karneges wrote:
> On Thursday 16 December 2004 03:54 am, Jacek Konieczny wrote:
> > On Wed, Dec 15, 2004 at 02:01:50PM -0500, Justin Karneges wrote:
> > > This would be great, and it is what I was advocating also, except that it
> > > appears to violate the protocol:
> > > http://www.xmpp.org/specs/rfc3921.html#presence-resp-probes
> > >
> > > 'If the user is not in the contact's roster with a subscription state of
> > > "From", "From + Pending Out", or "Both" (as defined under Subscription
> > > States), the contact's server MUST return a presence stanza of type
> > > "error" in response to the presence probe...'
> > So _that_ error should be ignored. But all the "timeout" and "connection
> > failed" errors still could be processed as proposed.
> For MUC this it not enough. MUC exists in the abstract world of Jabber, and
> availability of an s2s connection doesn't necessarily mean anything. If the
> s2s link comes back up, but the client has since left the room, how can the
> MUC know this? It will keep sending presence packets, and possibly even
> messages, without receiving a bounce. The ability of the MUC's server to
> probe for a participant's direct presence would allow the MUC to really know
> if the person is still considered to be in the room.
> From your other mail:
> > What about the s2s connections coming back to life?
> > How much additionall processing and resource usage will that require
> > from the servers?
> > What about distributed servers, with multiple s2s and other components?
> While I'm no server developer, the procedure for handling probing of direct
> presence would appear to be the same as that of subscribed presence. So it
> should not be that difficult to incorporate.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
More information about the Standards