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

Pedro Melo melo at co.sapo.pt
Tue Feb 21 13:17:27 UTC 2006


On Feb 20, 2006, at 8:55 PM, JD Conley wrote:

> There are also some interesting things we could do with more cross
> domain protocol optimizations. For example, MUC aware domains could  
> keep
> track of their JID's that are using external MUC services. They could
> then negotiate random/unique broadcast JID aliases for their domain  
> with
> the remote service for each of the roles/affiliations where they are
> needed. Then the remote service would just need to send a few stanzas
> with only a single JID in them for each broadcast. The same could be
> done for PubSub, I assume (I'm not as familiar with that spec).

yes, this is more the stuff I was thinking about.

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 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.

Best regards,
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt

More information about the Standards mailing list