On Mon, Aug 17, 2009 at 10:24 AM, Bernd Fondermann<[email protected]> wrote: > On Mon, Aug 17, 2009 at 09:55, Niklas Gustavsson<[email protected]> wrote: >> I'm might be a bit slow here, so have patience :-) >> >> On Mon, Aug 17, 2009 at 9:25 AM, Bernd >> Fondermann<[email protected]> wrote: >>> It's only that the server in general (with or without MUC doesn't >>> matter) doesn't currently handle directed presence stanzas from the >>> client. >>> Think of it as if it wouldn't handle unavailable stanzas. Then, MUC >>> wouldn't receive notice when a user goes offline. >>> >>> It works like this: >>> 1. Client sends presence to server ("outbound" in the notion if the RFCs). >>> 2. server (the client's server side session) handles the presence and >>> looks what to do with it >>> (in this case: it's directed presence => throw not implemented exception!) >>> 3. server routes the stanza (locally, to another client or to >>> component, or to another server). >>> even if it's only routing server-locally, the stanza is now "inbound". >>> 4. server handles "inbound" stanza and forwards to MUC. >> >> When exiting a room (which would be the same thing as going offline in >> MUC), the client would send: >> <presence >> from='[email protected]/res' >> to='[email protected]/nick' >> type='unavailable'/> >> >> This will be picked up by the MUC module, without going through the >> regular presence handling. > > No, this is not how it's intended to work and how it will work, if you > are not talking about the "inbound" case. > > I tried this "outbound == inbound" approach for a long time and you > cannot possible make it work, because they have different semantics. > The stanzas goes through the server two ways, once from the client to > the server (outbound handler), then back from the server to MUC > (inbound handler) in your case, and from server to client in other > cases.
So far, the MUC module has only cared for outbound stanzas. > One reason for this is that the client's session on the server MUST > keep track of all (outbound) directed presence stanzas. You cannot > possible do this within a MUC-specific handler. > > Trust me, you are missing an important point about the XMPP protocol > and how Vysper works (should work). Most likely :-) >> Meaning, the stanzas would not go into step >> 2-4 above. Instead, the MUC module would get the stanza before 2 since >> it will get all stanzas destined for "chat.vysper.org". Maybe this is >> the wrong way, but I think it's the way it currently works. > > We have to change that. > The MUC specific use case is that it receives _inbound_ presence > stanzas directed at "chat.v.o". They are "directed presence"s because > the two communicating parties (client and MUC) have no established and > persistent subscription relationship. They connect "on-the-fly" as far > as presene is concerned. Yes, MUC does not have persistent subscriptions at all. You can only be in a room when your online, when you're not, the room does not know you (except for information on that you might be for example an admin or outcast but that's not handled as a subscription as far as I can understand). > An example why it does not work the short way: Say we have > chat.vysper.org, but no user's on the v.o.-domain whatsoever. Now > [email protected] wants to participate in a chatroom. He sends /outbound/ > directed presence to "chat.vysper.org". jabber.org receives the d-p > stanza, records the fact and forwards to vysper.org server. The > vysper.org server now receives the /inbound/ d-p and routes it > unchanged and unprocessed to chat.vysper.org for further handling. The > chat (currently a monologue, but anyway) can start. > Now [email protected] goes away. No more messages flow. How would > chat.vysper.org receive notice? Well, pretty easy. jabber.org becomes > aware of the fact that me's session ended, so he sends unavailable > stanzas to all d-p contacts and discards them, because they have to be > re-established on next login. To make this work, outbound d-p cannot > go directly to MUC, even if the client is a local user. In the federated case where a jabber.org user logs in to chat.vysper.org this would still work with the current code. In the case where a vysper.org user connects to conference.jabber.org, it would not work, but of course also not involve the MUC module. In the case where a vysper.org user logs into chat.vysper.org, it's less clear to me: The server at vysper.org receives a <presence to="[email protected]/nick" />. This should, if I understand you correctly, be routed to PresenceHandler and then to PresenceAvailabilityHandler. The (currently missing) implementation of directed presence should record this, and than relay to the MUC presence handler. How would the last relay work? That is, how would StanzaHandlerLookup know to first route the message the PresenceHandler, and then to MUCPresenceHandler? >> 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. 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). > To better understand how a presence stanza travels, look into (and > step through probably) PresenceHandler. I've done this quite a few times and think I understand the code somewhat. However, it does not tell me that the PresenceAvailabilityHandler must record stanzas before being sent to the MUC module, in the case of local users. /niklas
