[ejabberd] How do conference rooms scale?

Peter Saint-Andre stpeter at jabber.org
Wed May 10 20:00:26 MSD 2006

Hash: SHA1

- From the protocol perspective, I see two main issues.

1. Presence. Large rooms would probably be moderated, else chaos would
ensue (only a few people have voice, everyone else is just part of the
audience). So a MUC implementation should not broadcast room presence
for visitors in a moderated room with many occupants, thus saving a
great deal of stanzas. JEP-0045 does not talk about this yet, but I will
add an implementation note about it.

2. Messaging. Here it would be good to have virtual rooms on different
servers, a.k.a. mirroring. So if the room is "hosted" on muc.jabber.org
it could be "mirrored" on chat.jabber.ru and so on. Any server that has
a lot of users could mirror rooms from across the network. One way to do
this would be for chat.jabber.ru to join muc.jabber.org as a visitor and
set up a local version of the room hosted on muc.jabber.org, then when
people ask to join that room they are seamlessly redirected to the local
version. Thus there is only one message sent from muc.jabber.org to
jabber.ru rather than one message for each occupant who originates from
the jabber.ru domain. However, as noted, we haven't yet worked out the
details of how such service mirroring would work.


Heiner Wolf wrote:
> Hi,
> the scalability issue comes up from time to time.
> Yes, rooms with really many users would be interesting. MUC in
> ejabberd seems to be not clusterable. I wonder why, because isn't it
> Erlang's unique selling proposition, that things you program are
> clusterable. Obviously, I don't know enough about Erlang to judge
> that.
> On the other hand, ejabberd's MUC does not need to be clusterable,
> because if there are so many users in one room that you need a cluster
> of servers, then your rooms presence list would be way to large. In
> other words, the protocol is the first to break.
> Even 1000 in a room is a problem, because traffic in the MUC protocol
> scales with n^2 of the number of participants. We need another
> protocol before we need a clusterable implementation.
> You should check the jabber.org list archives. We discussed ideas
> about how to extend the MUC protocol for many users. The simplest idea
> being not to announce any participant individually, but to send
> summaries and let the client fetch the list if it needs it. This list
> fetching however has the same traffic issues and would be done in
> smart ways with paging, filtering, etc.
> My impression is that MUC in ejabberd
> On 5/9/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
>> I've had some discussions with some people who are interested in very
>> large conference rooms distributed across services, but the protocols
>> for that kind of mirroring or sharing have not yet been worked out.
>> Peter
>> On Tue, May 09, 2006 at 07:39:54PM +0100, Joel Reymont wrote:
>> > Paul,
>> >
>> > You are assuming that all the users would be visible in the
>> > conference room. I'm thinking of a bunch of MUC servers all having
>> > the same JID and implementing the same conference room. You can have
>> > a manageable number of users in each and messages from other servers
>> > could come from a hidden user or admin or something like that.
>> >
>> > I'm not trying to implement a chat per se, I'm just piggybacking on
>> > the XMPP protocol.
>> >
>> > On May 9, 2006, at 7:27 PM, Paul Vixie wrote:
>> >
>> > >>I want to implement "conference rooms" with hundreds of thousands
>> > >>of  users
>> > >>in them where very few would be "typing" and most would be
>> > >>listening.
>> > >
>> > >just downloading the roster would take a megabyte or more per
>> > >user.  this
>> > >can't scale for reasons unrelated to ejabberd.
>> _______________________________________________
>> ejabberd mailing list
>> ejabberd at jabber.ru
>> http://lists.jabber.ru/mailman/listinfo/ejabberd
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.jabber.ru/pipermail/ejabberd/attachments/20060510/d360709c/smime-0001.bin

More information about the ejabberd mailing list