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? >
smime.p7s
Description: S/MIME Cryptographic Signature
