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

Ralph Meijer jabber.org at ralphm.ik.nu
Mon Feb 20 10:33:34 UTC 2006


On Sun, Feb 19, 2006 at 08:35:11PM +0100, Ulrich Staudinger wrote:
> Anyway,
> when we have some sort of a integrated pubsub into the servers, and an 
> on this based MUC protocol, we would have something like this:

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.

As someone else suggested, JEP-0033 would dramatically limit the number
of outgoing messages. That said, I assume that having compressed s2s
connections will probably yield good results as the whole message is
just replicated . I would be interesting to see stats on this.

For 'testing' my own hypotheses, I tried this out with a random
notification from Mimír's aggregator to the news bot:

The single notification takes 2643 bytes, compressed (using gzip) 938
bytes. When replicated 5 more times, with changed 'to' attribute, all on
the same host, the 6 messages together take 15864 (includes some
whitespace).  Compressed this amounts to 1095 bytes.

Using JEP-0033, the same message with 6 'to' addresses takes 3005 bytes.
Compressed this is 1008 bytes.

Note that the more you stream, the better compression you can achieve.
This example may not be completely representative, but at least gives me
some support.

For Bob. I see that JEP-0033 has a provision for providing extra data
inside the <address/> node. This could be used to store subscription ID
information, that'd have to be supported on the receiving end, of
course.

Also, while talking to Edwin Mons about this, he noticed a typo in
example of JEP-0033. The closing tag is </presence> instead of
</message>.

-- 
Groetjes,

ralphm



More information about the Standards mailing list