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

JD Conley jd.conley at coversant.net
Mon Feb 20 20:55:28 UTC 2006


Interestingly enough we have actually spent a lot of time addressing
this specific issue. One of our ISV customers sells emergency alerting
software based on our platform. After baseline analysis of SoapBox we
realized we needed to do something special. We now have code specific to
each broadcast scenario which greatly decreases the outgoing packet
processing time in SoapBox. This applies to PubSub, MUC, and
distribution group aliases. We can broadcast 10,000 messages on
commodity hardware (bandwidth permitting) in a couple seconds.

We also have large customers with 1000+ (mostly read-only) users in
multiple conference rooms. It just takes an adequate amount of hardware,
bandwidth, software architecture, and many hours of analysis and tuning.

I'm sure there are other implementations that explicitly handle these
scenarios as well. I just thought I'd point out that the specs do work
as-is.

As far as S2S goes, well, I think we're just going to have to get a
little smarter about what we do there. AMP is a good start, as well as
compression. Having multiple outgoing S2S channels to the same domain
would also be helpful.

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

-JD Conley

> On Mon, Feb 20, 2006 at 08:57:30PM +0100, Ulrich Staudinger wrote:
> >     I don't see how this is different from an integrated MUC
> implementation
> >     using the current protocol. Replacing MUC's distribution scheme
with
> >     pubsub's doesn't change anything. You'll still have as many
messages
> >     coming into to the server (now as publishes) and the
notifications
> >     coming out are also similar.
> >
> >
> > Actually, in the case of ejabberd where pubsub is built into the
server
> you
> > have only one notification coming into the server and in the former
> scenario,
> > 50 messages coming out.
> 
> So, as I said, this also holds if you integrate MUC into the server.
No
> need to drag pubsub into this.
> 
> --
> Groetjes,
> 
> ralphm



More information about the Standards mailing list