[jdev] MUC Across Unreliable S2S

[Don McGregor]

IRC, as I understand it, generates a spanning tree of
the servers involved, and from what I read in the RFCs
people are complaining about that.

Something NNTP-ish might work, with each site
giving a unique ID to each message and advertising
what messages they have.

There are also some room management issues if
you go distributed--who has authority to do what?


On Oct 25, 2006, at 4:09 PM, JD Conley wrote:

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