[Standards-JIG] Re: MUC traffic issues
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:
> 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.
> 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
More information about the Standards