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

Carlo v. Loesch CvL at mail.symlynX.com
Fri Jun 2 09:25:35 UTC 2006


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 business
interest in Jabber, so I have no gain by attacking anyone. At worst you could
argue that I want to leave some more footprints in the sand, if after 18 years
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 like
being proven wrong on issues, a bit more than others maybe. But even 18 years
can't make me keep all technological implications in my head at the same time,
especially when looking at a technology I did not design and only got involved
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 share
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 jabber.com
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