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

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Jun 2 16:14:08 UTC 2006

Not wanting to appear the one "stupidly sticking to his guns", I will join
in and take a minute to apologize to those who expressed their concern about

I take note of Carlo's description of the context in which he made his
survey. After all, I am the one that expressed the most vehemently how
hurting were my feelings. I still believe we would have avoided any
misunderstanding if the survey had not 1/ portrayed your system as being the
only one answering all requirements, 2/ reported behavior and asked for
additional information rather than immediately sticking labels. 
You would have to admit that there was never even a comment from the list on
your XMPP implementation. 

You have observed different responses to your test from the commercial
servers, compared to responses returned by open source implementations.
Considering they serve different purposes and target different users
communities, there is a strong probability for them to act differently. In
particular, they would most certainly be exposed to demonstrate exactly the
opposite of what you were trying to achieve. In particular, they would
accept the connections and then gracefully drop them. This maybe open for
debate, but requirements by customers of these servers often mandate 'polite
blocking' instead of returning an error. (Have you ever tried to explain to
an admiral why the server should return <stream:error/> ;)
Different context, different requirement, different behavior. It is a
business decision, nothing more. Certainly not driven by a fundamental
desire to depart from the specification, or stand out in a test. 

What is more puzzling is your hinting at possible packet loss on the S2S
links when spurious disconnection occurs. Although I understand the
theoretical possibility of this occurring (no connection is perfect), I have
never observed this behavior with the servers I have tested (all the open
source ones and OPN) even under heavy load. You would have to ask JINC if
their experience confirms this observation. 
I'd be interested to better understand what particular case or set of cases
you have in mind when you say this. 

As further information, I have observed the JINC server sending a closing
stream before disconnecting an idle s2s connection. As to OPN, it does what
is described in other posts, which is 1/ disconnecting the outgoing stream
by sending a closing stream and then invalidating the 'write' side of the
socket. 2/ start a timed wait on the 'read' side of the socket for an
incoming closing stream from the other party. Obviously if the timer
expires, the socket is closed.  

-----Original Message-----

Message: 5
Date: Fri, 2 Jun 2006 11:25:35 +0200 (CEST)
From: CvL at mail.symlynX.com (Carlo v. Loesch)
Subject: Re: [Standards-JIG] Re: Closing idle streams (server
	comparison chart)
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <200606020925.k529PaN22508 at fly.symlynX.com>
Content-Type: text/plain; charset=iso-8859-1

Now that the waters have calmed down I'd like to take a minute to apologize
if my "quick survey" hurt any feelings. I have no political or major
interest in Jabber, so I have no gain by attacking anyone. At worst you
argue that I want to leave some more footprints in the sand, if after 18
of work and thought in chat technology I'm still best known for something I
came up with in half an hour, the /me command. And you could say I don't
being proven wrong on issues, a bit more than others maybe. But even 18
can't make me keep all technological implications in my head at the same
especially when looking at a technology I did not design and only got
through Philipp. I learnt Jabber by reading the code he was checking in each
day in the last few years.

I shall explain how I made that quick survey. I sent out version requests
to XMPP counterparts out there in the wild and observed their subsequent
behaviour. Most servers exchanged dialback, replied to the version request,
then showed the socket shutdown behaviour they showed.

A few servers decided not to reply to the version request, like for instance
Google Talk, so I considered that not a criterium for legitimate federation.
It sure isn't useful for identifying the servers.

I admit I wasn't thinking that some servers I talked to wouldn't want to
anything with me. At least I expected if that were the case, they would drop
my connection right away, or otherwise tell me in the face with a suitably
informational error message. Instead they did the dialback (at least
and opn.antepo.com did), then after a couple of minutes changed their minds
about wanting to talk to me, sent a stream close and killed the sockets.
They should have sent a stream:error to be entitled to also close the socket
(it could however have been a one-way-close. I'm not sure what my logs
exactly show me at that point). So in the light of facts that I had no
permission to talk to them, the behaviour is fine.

; C:xmpp:opn.antepo.com      </stream:stream>
C:xmpp:opn.antepo.com disc      "Wed May 31 18:36:17 2006"

In the case of icewarp.com, which I presumed be running a Merak, it did
accept my stream, do negotiation up to a point (db:result type="valid"),
then simply never dialed back, instead too killed the socket. Not strictly
compliant but understandable.

All in all my survey wasn't intended to point some fingers and I was
expecting that I would receive some corrections and updates like the
contribution of SoapBox. All I wanted to point out is that there is
too much diversity in the way this is being handled, and that in some
cases it can produce loss of packets. Also since this isn't something
we should wait for until the IETF likes the new RFCbis, I thought it would
be appropriate to have a Best Practice JEP valid until the next RFC is done.

Maybe we should even sit down and think of a final multicast syntax for
XMPP and put it directly into the RFC, where I think it really belongs,
since so many apps (presence, groupchat, pubsub) need it to perform in
an efficient way. Peter, what is your opinion on Multicast? Be it 'real'
or 'medium' multicast.

More information about the Standards mailing list