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
