[Standards-JIG] Re: MUC traffic issues

Alexander Gnauck gnauck at ag-software.de
Sun Feb 19 17:54:11 UTC 2006

MUC_Punsub is not a good name here. I mean here some kind of 
server-extension where the xmpp-server (jabber.org in my example) has to 
do the Job. Like a email that has multiple receipients. I transmit the 
email once and the SMTP server does the job here.

A extension which allows distribution lists  on the server like pubsub 
would be the optimum. Another solution would be to allow multiple 
recipients inside stanzas.


Alexander Gnauck schrieb:
> Hello,
> i had a small discussion with Ulrich about it in the JSF meeting today, 
> and we had discussions about that in the jdev room quite often in the 
> last weeks.
> With very busy chat servers and chat rooms all current MUC 
> implementaions scale very bad, because too much bandwidth is wasted and 
> too many message and presence stanzas are routed.
> example:
> 5 users in a room room at conference.jabber.org, user1 sends a message to 
> the room. All users are connected to jabber.org in the scenario
> message flow:
> user1 -> jabber.org -> conference.jabber.org
> the messages reached conference.jabber.org which creates now 5 new 
> messages, because the message must be delivered to all participants.
> conference.jabber.org 	|-> jabber.org -> user1
> 			|-> jabber.org -> user2
> 			|-> jabber.org -> user3
> 			|-> jabber.org -> user4
> 			|-> jabber.org -> user5
> we send 2*usercount messages. If the Muc server is build in the server 
> or cluster we could reduce the messagecount by 50% with a good software 
> design. But if MUC is used of the component protocol we can't.
> So Ulrich proposed to use a combination of muc and pubsub to reduce the 
> traffic which is a great idea.
> The message flow would be the following then:
> conference.jabber.org	-> MUC_Pubsub	|-> user1
> 					|-> user2
> 					|-> user3
> 					|-> user4
> 					|-> user5
> We send only usercount+1 messages now.
> Your thoughts
> Alex

More information about the Standards mailing list