[Standards-JIG] Re: Closing idle streams (server comparison chart)
jd.conley at coversant.net
Wed May 31 17:52:51 UTC 2006
FYI, SoapBox would likely be a "0" on both, even though you didn't
include it. :) We don't currently close idle connections.
From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of Carlo v. Loesch
Sent: Wednesday, May 31, 2006 10:45 AM
To: Jabber protocol discussion list
Subject: [Standards-JIG] Re: Closing idle streams (server comparison
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
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:
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