[Standards-JIG] Re: Closing idle streams (server comparison chart)

Carlo v. Loesch CvL at mail.symlynX.com
Wed May 31 17:44:42 UTC 2006


I came up with a solution: The proper strategy to close an idle
connection must be to send </stream:stream>, then wait for the
other side to agree, close the stream and the socket.

This is the only way that you can close an incoming connection
and be sure, if the other side just started sending something,
it will safely make it into your parsers.

And the plan is also compliant to RFC 3920, since according to
Example 4.8 basic "session" a stream can be closed by handshaking
a </stream:stream>.

I have made a little survey on existing jabber server software,
how they handle idle connections.

The good news, most servers do not cause harm.
The bad news, 4 implementations cause loss of data.

Here's a little chart:

			OUT     IN
	jabberd14       RFC     0
	merak           RFC     -
	ejabberd        -       -
	jabber XCP      -       --
	opn antepo      -       --
	googletalk      -       0
	jivemess        -       0
	timp.net        0       0
	jabberd20       0       0
	psyced          RFC/+   RFC/+
	wildfire        +       +

'RFC' means that the session was terminated with a <connection-timeout/>
according to the RFC. since in most cases it was an outgoing connection,
the chances of harm are non-existing and the approach is valid.

'0' means that the connection is still dangling off my server and it
just doesn't time out. This too is a very valid approach, except some
implementations may run into a descriptor shortage. 

'-' means the implementation has killed the tcp connection without
any warning. This is not in accordance to the RFC, won't cause much
harm however, if only applied to the outgoing socket. unfortunately
four implementations also apply this method on incoming streams,
which is very likely to cause loss of data. especially the jabber.com
and the opn antepo implementations kill incoming connections after
one or two minutes of idle time, which makes it very likely to run
into racing conditions and lose incoming messages. that's why i've
put '--' there.

'+' means the implementation is closing idle sockets in the sane and
elegant way i described at the beginning of this mail. i must say i
was very surprised and impressed to find that the 'Wildfire' server
is already implementing this approach.

In the case of psyced, up to today it was closing connections in the
RFC style after 1-2 hours of idle time. now it is using the new failsafe
method instead (if you do a cvs update ;)).

I suggest all implementations to upgrade to the '+' method unless
there are any objections. In particular ejabberd needs a quick fix,
as jabber.org isn't one of the least popular servers. 

Can't wait to see you all enjoy a new level of TCP RELIABILITY!  ;-)

-- 
» Carlo v. Loesch » http://symlynX.com » psyc://ve.symlynX.com/~lynX
	    xmpp:lynX at ve.symlynX.com » irc://ve.symlynX.com/#symlynX
        CryptoChat » https://ve.symlynX.com:34443/LynX/?room=symlynX



More information about the Standards mailing list