[Standards-JIG] MUC/pubsub multicasting using JEP-0033.Was:MUC traffic issues

JD Conley jd.conley at coversant.net
Tue Feb 21 20:59:53 UTC 2006

> JEP-0033 is not, IMHO, a good solution for multicast. It's not
> multicast, is multi-addressing, a completely different thing, and
> only good enough for hundreds of addresses or even less. The cost of
> putting all those addresses in the same stanza (or even if you break
> the stanza in some parts), I think that it is too much.

I agree. This is the reason we have distribution lists in our server. :)

> I mentioned this a couple of days ago, for pubsub, using a proxy
> address to manage notifications for pubsub. The procotol would be
> something like this:
> 1. client checks local server for a multicast proxy;
> 2. client obtains from local multicast proxy a local broadcast id for
> the service that we wants to subscribe. This ID is unique to each
> remote service, and must be the same to each local client that
> request the same remote service;
> 3. client subscribes to a remote pubsub node or joins a remote room
> using this local broadcast id.
> 4. notifications from pubsub or room traffic is sent to the broadcast
> id. Mind you that some traffic might be sent to the client directly
> (like inicial presence storm from a muc room).
> 5. the proxy multicast service, receives each message and forwards it
> to the interested parties.
> This is a simplified view of course, but it should work. I don't
> change the responsibility of the initial subscription or room join,
> to make sure it is properly validated, just the traffic that follows.

Actually I was thinking of a purely server side optimization -- this
could even apply to internal components, not just s2s. Something like:

1. user at example.com joins room at conference.example2.com
2. example.com has not yet seen anyone join room at conference.example2.com
so it checks disco to see if conference.exmaple2.com supports multicast
aliases. example.com also tracks the affiliation and role of
user at example.com in room at conference.example2.com so that it knows how to
appropriately map the broadcast address.
3. conference.example2.com does support multicast aliases so example.com
creates a unique identifier, that is unlikely to be chosen by a user,
for multicasting to room occupants (i.e. {GUID}{escaped room
JID}@example.com -- taking into account JID overflow, of course)
4. conference.example2.com now sends any occupant presence broadcasts
and messages to {GUID}{escaped room JID}@example.com and example.com
handles broadcasting this to any occupants that map to the broadcast

I think the same protocol flow and namespaces could be used by any type
of cross domain multicasting. In the case of MUC there would be multiple
multicast nodes available for each of the roles that need different
presence and message payload information.

This may be the same in PubSub, though those addresses would need to be
persisted between sessions, correct?

-JD Conley

More information about the Standards mailing list