[Standards] Distributed chatrooms in PSYC

Philipp Hancke fippo at goodadvice.pages.de
Fri Feb 26 13:37:10 UTC 2010


Peter Saint-Andre wrote:
> I want to make it clear at the start that the main driver for
> distributed MUC is not the desire for an Internet-wide federation with
> stable masters that have good connectivity and never get into trouble.
> Instead, the people who want distributed MUC are mostly interested in
> the problem of endpoints or slaves that lose connectivity to the broader
> network because they are on distressed networks. That kind of scenario
> might lead to very different assumptions and requirements. So we need to
> think clearly about what we're trying to achieve before we go down the
> path of designing something.

Aye. fup2 muc@

Some basic design considerations first. Note that I am using the
master/slave vocabulary instead of source/shadow, but I mean the same
thing.

On-the-fly creation of slaves is probably the way to go, we've stopped 
using manual master/slave trees in 2003. We usually use a master-submit 
strategy, where every stanza is routed through the master, with 
additional clustering/fallback strategies at the master level to avoid 
the single point of failure.

How the messages travel from master to each slave (and individual users) 
is another issue. Top-down spanning trees are a quite good solution, 
easy to implement and can even be used to route around communication 
failures between two domains (as long as both parties can still contact 
a third party). Other architectures may provide more resilience but 
require methods to detect and filter duplicates.

Resilience (or "split mode") as described by you is still possible, but 
has turned out to be dangerous for IRC. In a closed environment this is 
no problem however.

On the C2S level the assumption that the slaves are within the same 
domain as the user and can therefore "fake" addresses is useful. The 
whole dmuc issue can (and should) be handled transparently for the user, 
which reduces the specification requirement to the master/slave protocol.

The join flow I would propose is (since the join is the essential 
problem, let us make sure that we're agreeing on that before continuing):

User sends presence to the master. The master then determines if there 
is a peerhost available in the users domain (an alternative here: the 
peerhost intercepts the stanza locally and it is then forwarded to the 
master by the slave - however, that requires the peerhost to know that 
the user intends to join a muc room, that this muc room is dmuc-capable 
etc.

If there is a peerhost, the master creates a slave on the peerhost and 
sends room roster and discussion history to the peerhost (if necessary). 
After that, the master sends the slave a message to inform the slave 
that the user has joined the room. The slave then sends the room roster 
to the user, followed by the users presence and discussion history. Note 
that the master does not need to resend the room roster or discussion 
history to the slave when additional users join.

The slave could optionally start to intercept any messages sent to the 
master, this is a necessary requirement for split-mode.

Comments?


Kev:
 > In the case where cjo themselves want to have available several
 > available peers, they can set up SRV records for the service to point
 > to pre-agreed peers.

What you're describing is probably better solved by a clustering protocol.
I don't think that we should tackle that problem because
a) there are lots of different approaches to clustering. Most of them 
require much more trust than you have in open federation.
b) there is usually no need for an "open" protocol since you usually 
have a homogeneous cluster with just a single implementation and no 
interop requirements.
c) reinventing IRC is no fun anyway ;-)

philipp



More information about the Standards mailing list