[jdev] MUC Across Unreliable S2S

[JD Conley]

It seems like this calls for an IRC style "network" approach where MUC
domains can join a specific network and share room names.

-JD

> 
> 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?
> >