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

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed May 31 23:38:08 UTC 2006


This post is pure BS. Sorry list, but this is a little far fetched. 

This so called comparison is another example of this guy twisting reality
and quickly jumping to inexact conclusions to support a biased argument. For
good reasons, no OPN server is available for unsolicited tests, either using
a client or S2S. Any inappropriate attempt to connect to a server will be
rejected be the access control service. In this situation, the protection of
the server does not require an undesirable connection to be RFC compliant.
>From my experience, the XCP servers are susceptible of showing a similar
behavior. I cannot vouch for ejabberd. Judging from the wildfire code it
closes the </stream:stream> on an idle connection. So was doing the early
version of jabberd 1.4. 

For your information, both XCP and OPN have been closing </stream:stream>
then the socket on idle authorized connections since they appeared on the
market... So much for your "proper strategy". Let me also add that these two
servers have been selected by customers which would not tolerate losses of
messages on disconnection. Believe me the servers have been put to test to
make sure this was not the case. And they do not loose messages.  

Finally, the XCP server, the OPN server, the Tipic server all requires a
registration procedure in order to qualify a trial request. The Merak server
is available for download but needs an activation key. I strongly doubt you
had all these servers installed in your 'lab' for the test. Let me tell you
what happened: your server list is just a copy and paste of the list
available at jabber.org. And you just made those tests results up. 

I suggest you show a little more modesty and a greater dose of accuracy when
putting forward this kind of statement. In case you never heard of it, a
test requires a protocol describing with precision the testing conditions
and context. True test results are careful and cautious in their reports.
You may have to take lessons from the academic or enterprise world on this
matter. Without this documentation, this post is just unfounded grotesque
affirmation. Carlo, all your posts are smoke in the eyes, all your blunt
statements remain conjectures and you an arrogant bully.    

-----Original Message-----
Message: 1
Date: Wed, 31 May 2006 19:44:42 +0200 (CEST)
From: CvL at mail.symlynX.com (Carlo v. Loesch)
Subject: [Standards-JIG] Re: Closing idle streams (server comparison
	chart)
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <200605311744.k4VHigc12338 at fly.symlynX.com>
Content-Type: text/plain; charset=iso-8859-1

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!  ;-)






More information about the Standards mailing list