[jdev] MUC Across Unreliable S2S

[Norman Rasmussen]

A good place to hash out ideas is also
http://wiki.jabber.org/index.php/Talk:NGMUC

My comment on mirroring mucs:

""" I've been thinking about this one recently. You could create a
'muclinker' component that sends presence to all rooms you want to
'mirror'. That will make all the rooms send you the presence and
messages. You receive these messages and 'bounce' them to the other
rooms. By making this a component you can track enough state in the
entities jid that you don't actually need to store much state on the
component. All of this requires no code changes to any muc
implementations. XEP-0033 support could be added to reduce the
bandwidth consuption.

If you're going to make code changes and enhance the muc XEP, then I
think it would be best to add something to allow an authorised
external source to control the network linkages, and fail-over. This
way the muc's can concentrate on doing what they're good at, and
people can implement their own auto fail-over designs, and swap them
out at will. """

On 10/25/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> I've been planning to write up an approach to this soon (probably next
> week), based on discussions I've had with people in the same situation.
> But more discussion is better! :-)
>
> Peter
>
> Don McGregor wrote:
> > I've got an unusual deployment environment that may
> > require some custom server code, and I'm kicking around
> > ideas for how to handle it.
> >
> > The use case: I've got multiple remote XMPP servers
> > talking to a relatively well connected and stable XMPP
> > server hosting MUC. The IP connections between
> > the remote servers and the muc server are highly
> > unreliable; I'd expect TCP connections to ungracefully
> > go down several times per hour, and the downtime
> > may be from minutes to hours.
> >
> > Users authenticate to their local server and
> > join the MUC on the central server. There
> > may be many users on the local server; when
> > the S2S connection goes down I'd like to
> > have the users on that server to be able to
> > continue to chat with each other. When the
> > S2S connection comes back up the local messages
> > should be sent to the MUC server, and the
> > MUC server's history since the dropped connection
> > should be sent to the users at the remote site.
> >
> > What I'm thinking is that I can modify the
> > Wildfire server and place an "interceptor"
> > piece of code/pattern on the XML router. This
> > develops a list of local users, and when it
> > detects a dropped S2S connection it begins to
> > spool up local messages. It also delivers the
> > messages to local users. When it detects
> > that the S2S connection has come back up,
> > it sends the spooled messages to the MUC,
> > and requests the history of the MUC since
> > the connection dropped.
> >
> > Good idea? Bad idea? Is there a better way
> > to handle this situation?
> >
>
>
>
>


-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/