[Standards] s2s and gracelessly broken streams

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Mar 28 03:55:03 UTC 2007


On Tuesday 27 March 2007 7:57 pm, Peter Saint-Andre wrote:
> Mridul wrote:
> > Hi,
> >
> >   Is there any best practices on how to handle broken s2s connection ?
> > Two primary cases come to mind :
> >
> > 1) Remote server went mia due to some transient network/other jitter and
> > recovers after "some" time (assume enough delay to cause tcp close) : so
> > contacts are still available.
> > 2) Remote server went down and came back up after "some" time : so
> > contacts are no longer available.
> >
> > (Another condition could be server closing the inbound/outbound socket
> > after some delay.)
> >
> > In these cases, assume that unavailable presence was not sent.
> >
> > How is contact's presence expected to be treated on the user's server ?
>
> Good question. I'd be curious to hear how current implementations handle
> this. The options are not exactly appealing. :)

It isn't clear from Mridul's question what exactly a broken s2s connection is.  
Remember that s2s connections can come and go at any time, and unlike c2s 
connections, there is nothing implied when the connection goes away (such as 
any sort of presence unavailability notification).  So, of his 1st and 2nd 
conditions, as well as the unnumbered parenthetical condition, none are error 
situations.  In fact, closing s2s connections is a good strategy to prevent 
stanza loss (there's less likelyhood of tossing a stanza into a dead 
connection if all of your connections are relatively fresh).

This does mean that if a server disappears from the internet, all of its sent 
presences will "stick" until the receivers decide to flush them away.  For 
example, if you have a ghost presence of someone on your roster, a relogin 
will usually fix it (because your server then assumes everyone is unavailable 
again, and starts probing).  However, if you never sign off, then depending 
on your client/server implementation and the lifespan of the earth, it is 
possible that the ghost contact could remain available for all eternity.  
This is also the cause of MUC ghosting (which can seemingly last forever).

The best solution, as far as I can tell, would be for the server to perform 
presence probes on a periodic basis, rather than only on client login.  IMO, 
it is rather silly that the client user can "force" the effect by doing a log 
off/on.  I think it would be a lot better if the server handled this 
transparently, by probing routinely, and then the client should always "just 
work".

I'd also go as far as saying that we should decouple probing from being 
explicitly related to the login process.  For example, if a client were to 
log off/on within a very short timeframe, I'd say that the server shouldn't 
probe the whole roster again.

I think we have the necessary protocol in place to solve this problem, it is 
just a matter of having well-implemented servers.

-Justin



More information about the Standards mailing list