On Mon, Aug 17, 2009 at 12:27 PM, Bernd Fondermann<bf_...@brainlounge.de> wrote: >> In the federated case where a jabber.org user logs in to >> chat.vysper.org this would still work with the current code. > > There is no way for a jabber.org user to log into vysper.org in XMPP. > He can only log into jabber.org and send stanzas via his homebase server.
Sorry, that's me using the incorrect wording. By "logs in" I mean "enter room". > By putting the stanza on the 'inbound' queue. I still don't understand how StanzaHandlerLookup would be able to understand that this should not go to PresenceHandler again. Or maybe we need to change StanzaHandlerLookup to be able to distinguish between outbound and inbound stanzas and provide different handlers? >>>> In addition to this, the MUC module needs to be informed of the users >>>> going offline without sending this stanza, e.g. the socket dying. This >>>> is currently not handled by MUC. >>> Handling d-p relationships is solely the client's servers >>> responsibility, not MUCs nor the client's, or that of any other >>> extension or component. >> >> Here's what XEP-0045 says on this subject: >> "It is possible that a user may not be able to gracefully exit the >> room by sending unavailable presence directly to the room. > > There is no way in XMPP to send a stanza directly from a client to any > server, only to the user's one. > So that's the way how I read it: > "It is possible that a CLIENT may not be able to gracefully exit the > room by sending DIRECTED unavailable presence to the room VIA HIS OWN > SERVER." > (pardon me the upper-case, it's only for highlighting purposes) That's the same interpretation that I do. >> "If the user >> goes offline without sending unavailable presence, the user's server >> is responsible for sending unavailable presence on behalf of the user >> (in accordance with RFC 3921). If the user's server goes offline or >> connectivity is lost between the user's server and the MUC service to >> which the user is connected (e.g., in federated communications), the >> MUC service is responsible for monitoring error stanzas it receives in >> order to determine if the user has gone offline. If the MUC service >> determines that the user has gone offline, it must treat the user as >> if the user had itself sent unavailable presence." >> >> Reading this, it is my interpretation, that MUC must monitor for error >> cases itself (in addition to the users server). > > ok, this is good in the case where a server might come back online and > should not be DOS'd right away with pending MUC message retries. Rather, > this server's users should be regarded as being offline and gone. Right, and and MUC needs to handle this (obviously, as there is not much the users server can do if it crashes). /niklas
