[Standards] distributed MUC rooms

[Mridul Muralidharan]

Peter Saint-Andre wrote:
> Last October I talked with some folks in the XMPP community about the 
> idea of distributing MUC rooms across domains. Late this afternoon and 
> this evening I finally got around to writing up an approach to this 
> problem. The document I've started working on is quite tentative, but I 
> figured I'd send it out for feedback anyway (release early, release 
> often!).
> 
> http://www.xmpp.org/extensions/inbox/distributedmuc.html
> 
> I'll try to work on it more this weekend, since I'd like to present some 
> of the ideas at a conference I'm attending next week.
> 
> Peter
> 

A few thoughts in general.

1) What is the scope of the distribution - is it going to be an muc 
service spread across domains ? Or is it going to be a single logical 
muc service (hosted on multiple machines/nodes) ? (With reference to 1.3.3)

 From examples 5 onwards, it looks like the former case ... might get a 
bit tricky. Why would a user join muc.example.net for a conference on 
chat.example.com ?
Wont this not be a potential routing issue ?
I assumed we will be using something like dix[1] for this - where bare 
jid is the same, just that it is distributed and fault tolerant. (or 
integrated into the cluster/pool'ed server).

This could also become potentially confusing for clients - where user of 
a conference is receiving messages from multiple room jids.


2) After creation, do we need to maintain the distinction between 
FIRSTHOST and PEERHOST ? Merging of config can be based on 'timestamp' 
for example (use ntp on all nodes to keep them in sync) ? This way, 
FIRSTHOST could be down, or not participating in the conference which 
was created on it ... and still things would continue working.
With reference to 1.3.4

3) After example 4, can we add the peerhost as a hidden config param to 
the room config (firsthost gets auto-added if room is distributed) ?
This way, recovery would be easier in case of restart/etc - and peerhost 
will know 'who all' to talk to for a room.
Though in light of (1), I am not very sure of this - if it is a single 
logical entity, it will talk to 'all' instances it discovers ... so wont 
be necessary.

4) Section 3.4 - is it that the peer room which received the message 
supposed to be multicast to other peer rooms - which will inturn 
multicasts to their hosted participants ? Or is it that the recipients 
room multicast directly to participants of the remote rooms ?
Would prefer the former - if latter, use xep 33 ?
I was not sure which approach this xep is taking (I could have missed it).


We have been supporting distributed conferences for a while now, and 
there are some interesting routing challenges - even though in our case 
it is directly integrated into the server.
It would be great to see a spec which allow remote components to also 
become distributed and provide highly available conference service !

Regards,
Mridul


[1] http://www.xmpp.org/extensions/inbox/dix.html