[Standards-JIG] MUC traffic issues

David Sutton jabber at dsutton.legend.uk.com
Sun Feb 19 20:34:37 UTC 2006

Hello Alexander,

  Before you go too far with this, I would STRONGLY advise moving this
  into its own JEP. JEP-0045 was designed as a next generation
  'groupchat' protocol, using lessons learned from groupchat and another
  conference protocol that was being trialed at the time. For what it
  is, a simple system for multiple people to communicate together, it is
  great and does precisely that. What everyone seems to be wanting is
  the next generation, more of a MMO MUC implementation, and that has
  its own requirements that lose the simplicity of our current JEP.

  If you are wanting many users on many servers, then one thing you may
  want to look at is something like a broadcast component that lives on
  each server - the conference server would send out the message to each
  broadcaster that had registered with it, and it would then send to all
  the people on that server who were in the room. This alone would
  reduce traffic to the single conference node.



On Sun, 19 Feb 2006, Alexander Gnauck wrote:

> 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

David Sutton - Systems Administrator I
CenturyTel Hostmaster
david.sutton at centurytel.net

More information about the Standards mailing list