[Standards] distributed MUC rooms

[Peter Saint-Andre]

Mridul Muralidharan wrote:
> Michal 'vorner' Vaner wrote:
>> Hello
>>
>> On Sat, Jun 02, 2007 at 06:34:53PM +0530, Mridul Muralidharan wrote:
>>>  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.
>>
>> As I got the idea, you never get messages from anyone except the muc you
>> connected to. Every MUC would get all messages and route them to its
>> local users.
>>
>> As I got it, it means different rooms where messages teleport from one
>> to every other, so their occupant list and messages are the same.
>>
> 
> In which case, how would directed message, iq, etc work ? multiple hops 
> through the components ? Or are full jids to be shared across 
> components/rooms in different domains ? (trust conf in remote domain ? 
> privacy leaks ?)

Depends on deployment decisions. In general you would send a PM to 
someone in your room and your instance would need to send it to the 
instance in which that occupant really resides. Same for IQ. Naturally 
if the configuration of the room is non-anonymous then you should send 
directly to the person's full JID, and the room might in that case 
forbid PMs and IQs (etc.) through the distributed room.

> So we are back to the question of - what is the intention : only high 
> availability of conferences ?
> Or is the intention also to spread them across domains ? So, they end up 
> talking over s2s (overhead would be quite high in the latter case).

I don't see a conflict or tension between high availability or domain 
distribution. I think this is *mainly* about distribution and not about 
clustering for high availability, but distribution might give you higher 
availability (if s2s link goes down then you can still chat with the 
people in your instance and perhaps other instances as well -- it 
depends on which s2s link goes down).

Also, distributed MUC is not necessarily intended for deployment on the 
existing Jabber network. Maybe people would find it valuable, but I have 
been working on this mainly for use on networks that have more serious 
connectivity issues than what we find on the open Internet (e.g., 
tactical environments).

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070604/97a255a1/smime.bin