[Standards-JIG] proto-JEP: Smart Presence Distribution

Philipp Hancke fippo at goodadvice.pages.de
Thu May 18 08:54:10 UTC 2006


Jean-Louis Seguineau wrote:
> It would be very pretentious of me to make predictions about XMPP survival
> if we do not follow your recommendation to enhance s2s presence broadcast
> (i.e. simultaneously send the same message to multiple recipients). So I
> would abstain commenting.
> 
> Let me just point out that the discussion threads from last February were
> related to MUC originally and to PubSub at some points. Not presence.

All of them distribute to a group of n people, n >= 1.
Do we agree that in general a distribution strategy smarter than
'send n copies' is needed?


> I have followed this previous discussion without jumping in, because I was
> not in agreement with many of its conclusions. Simplifying, in the case of
> PubSub, it is common practice to allow inter-broker subscriptions in order
> to push the fine grained notifications as near as possible to the
> subscribers. That in turn entails using subscription covering to
> canonicalize subscriptions between brokers. Doing this over XMPP is not a
> matter of changing the protocol, but a matter of PubSub implementation. If
> an implementation is designed as a distributed PubSub, the location of the
> publication can be anywhere in the brokers network. Each broker is the
> multicast group you are looking for, and the existing protocol is adequate.
> As the subscriptions are canonicalized between broker, their scope is wider
> than the individual subscriptions, but the advantage is that you can leave
> the ACLs at the final broker level. This is usually referred to as an
> overlay pubsub network, and it is known to really scale. XMPP has most of
> the protocol bricks to build such a network; it is more a matter for the
> developers to think outside their traditional IM mindset.  

In those overlay pubsub network, is the publisher in control of who
will get an item?
If so, how do you make sure the ACLs are synchronized?


> In the case of MUC, instead of thinking 'hub and spoke' as most
> implementations do, you could easily achieve what you are looking for by
> providing chat rooms delegation amongst several servers. Same idea, bring
> the fine grained messages closest to the room user. Imagine for example
> having a distributed Jdev room. Instead of all the users connecting to the
> jabber.org MUC server, every user will connect to a local JDev room hosted
> on their home server. French user on a French server, US users on an
> American server, and Argentineans on an Argentinean server. To achieve your
> multicast, these distributed rooms would be registered in the jabber.org
> JDev room. So whenever a message is posted in the original JDev room, it is
> sent to every directly connected users, and only one instance will be sent
> to each of the delegated rooms in France, US and Argentina. 

I am not doubting that, we have used that approach for years. There are
several problems related to it, for example:
* how do you discover the local jdev room?
* how do you explain to the end user that he should join the local jdev
   instead of just entering jdev at conference.jabber.org ?
   Especially if they've clicked on xmpp:jdev at conference.jabber.org?join


 > Again this is not a matter of protocol, but a matter of architecture
 > and implementation.

The general architecture we are proposing is to distribute on-site using
distribution lists which are negotiated separately from the message
itself (this is different from JEP-0033).

What we are proposing is to use information readily available to
build those lists:
* for presence you can use the roster.
   * Yes, this assumes synchronized rosters.
     How difficult is it really to achieve this (e.g. using the
     roster serial approach in one of the previous mails)?

   * Yes, this does not work with privacy lists unless you're
     exposing them to the remote server.

If you think that this is impossible for privacy reasons you can
of course renegotiate the list with a remote multicast service
each time you need it. You're probably exposing (parts of) your
privacy lists during that process.


* for MUC, you could probably determine those lists by looking for a
   bidirectional exchange of directed presence with someone that
   is not on your roster / you dont a subscription from/to. Afaics
   MUC is the only place where this bidirectional exchange is used.
   The privacy issues are less severe there, error handling is better
   and as the whole list is more volatile, it is usually less
   out-of-sync.




More information about the Standards mailing list