[ejabberd] Full-fledged MUC clustering: what would it take?

Daniel Dormont dan at greywallsoftware.com
Sat Mar 12 01:22:02 MSK 2011


I've been getting into the Ejabberd sources recently and learning quite a lot. I can see that in the current state of affairs, MUC clustering has gotten pretty far: I can enable mod_muc on multiple nodes, distribute online rooms across the nodes and let any user join any room on any node. If a node gets shutdown and the room was persistent, it can be restarted on any other node and the room's name, description and most importantly, its affiliations and configuration, are preserved, since they are kept in RAM and Disc copies of muc_room.

I'd like to see what it would take to get it a few steps further, namely:

1) Suppose a room on node A has 100 users on node A, and 100 users on node B. When a message arrives and is to be broadcast to the group,  it would be great if only 1 message could be sent from A to B, instead of 100 messages, one for each user.

2) Suppose node A crashes. As mentioned, node B can restore the room, but users logged into B will not be in it: their presence, Nick and role in the room will have been lost. I would like to preserve this somehow.

To those familiar with the Ejabberd code, and who've been thinking about these problems for longer than I have, what would have to be done - speaking from a high level perspective - to implement this?

thanks,
Dan


More information about the ejabberd mailing list