Streamlining remote probes

I wanted to finalize my original topic on improving XMPP presence handling model for subscribers hosted on distributed home servers by looking at presence probes.
XMPP differs from presence protocols such as SIP/SIMPLE by using persistent presence subscriptions, instead of transient subscriptions to be renewed for every session. In this model, an XMPP client publishes its presence states variations to its home server, which in turn generate the appropriate presence notifications.
Furthermore, an XMPP presence server is only responsible, and above all knowledgeable, of its own user's constituency.

When a user want to initiate a presence enabled session, it publishes an initial presence after login. This is intercepted by its home server, which is in charge of

• Responding to the client with the initial known presence state of every watched contact,
• Notifying every contact subscribed to receive the user's presence.

The home server then triggers two processes:

• A user's presence notification to all the watchers of its presence state,
• A probe of each user's subscriptions to receive the contacts' presence states.

When every contact in a user's buddy list is co-located on the same home server, the server has a complete view of each contact's presence state, and using a probe stanza is not necessary. But if the contact resides on a remote server, a probe stanza is sent to that server to trigger a presence state stanza in return. Mridul rightly point out that the current specification leaves open the possibility for a server to cache remote contacts presence states and derive initial presence for additional instances of these contacts from cache. I believe the specification must avoid remote presence state caching. The probing mechanism is a guarantee for the home server to always have the latest initial presence state of remote users.

I can now come back to the early concern of minimizing the network traffic generated by presence handling when subscribers are hosted on distributed home servers. It is to be noted once again that the two processes of notifying all watchers and probing to receive contacts' presence states are asymmetrical. I have shown previously how notifications could be optimized by using transient remote users' lists. Conversely, probing multiple contacts' presence states is a one time operation.
XMPP requires that probes be sent to a global URI (bare JID). In my opinion, to the contrary of notifications, the expected gain of grouping several JIDs in a single stanza are more limited. Leveraging XEP-0033 Extended Stanza Addressing to group JIDs in a single stanza may result in slight traffic improvement if the number of remote contacts located on a single server is important. But for a limited number of remote contacts, the gain will certainly be marginal, so the complexity of implementing this kind of mechanism should be carefully weighted against the actual traffic gain.

An illustration of this mechanism is given bellow, assuming the multi-probe support has previously been discovered through XEP-0030:

<presence to="prober.denmark.lit" from="horatio@denmark.net/palace" type="probe">
  <addresses xmlns='http://jabber.org/protocol/address'> 
    <address type="to" jid="rosencrantz@denmark.lit"/>   
    <address type="to" jid="guildenstern@denmark.lit"/>          
  </addresses>
</presence>
<presence to="horatio@denmark.net/palace" from="rosencrantz@denmark.lit/on-the-road"/>  
<presence to="horatio@denmark.net/palace" from="guildenstern@denmark.lit/motel"/>  

It is rather obvious that the overhead of discovering the support and using multiple addresses in a single stanza will offset the gain when contacts are spread up few at a time amongst many servers. That said, if a significant number of contacts are located on a remote server, the mechanism may prove valuable, not primarily because of the traffic reduction, but rather because all the probe targets are delivered in one single stanza. For the remote server it will generally be more efficient to process a series of JIDs in a single transaction without context switching, rather than processing several atomic stanzas each in its own transaction. I most other cases, the added complexity may not be worth implementing.

Technorati Tags: XMPP, Jabber, Presence, Antecipate