[Standards-JIG] MUC/pubsub multicasting using JEP-0033. Was:MUC traffic issues
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
> track of their JID's that are using external MUC services. They could
> then negotiate random/unique broadcast JID aliases for their domain
> 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.
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards