[Standards-JIG] Closing idle streams
dave at cridland.net
Fri Jun 2 14:27:00 UTC 2006
On Fri Jun 2 08:42:22 2006, Carlo v. Loesch wrote:
> Dave Cridland typeth:
> | No, it could be server shutdown, or a policy decision never to
> | to that server again, or...
> No, those are all covered by other conditions in 4.7.3 like
> <system-shutdown/>, <policy-violation/> or even
Well, sure, they should be marked. How do you tell between a buggy
server that didn't, and a good server that's trying to indicate some
> | I don't think there's any benefit in eliding the error, and I
> | think there's ever a good argument for using implicit errors. If
> | you're explicit, then even a bad implementation knows what's
> going on.
> Wanting to close a socket because you need the descriptor is not an
> What's the error about it!???
The arbitrary limitation on the number of descriptors in the design
of the OS? ;-)
Don't think of it as an error. Think of it as a reason for closing,
which happens to be delivered as an error.
> No it does not work in our favour at all. This is why there has been
> packet loss in Jabber S2S communications all along, because closing
> the socket unilaterally bears the risk of losing data that is just
> being submitted on the other side.
> Why do you think I'm submitting a BP if it wasn't a problem?
I don't think I said anything about closing the socket unilaterally.
Send the stream error and the stream close, half close, and wait for
the remote end to close the socket, same as for any stream error. You
don't need to worry about whether the remote end does the stream
closing tag or not, because the remote end will close the socket when
it's done - let TCP do the closure handshake. Even an older or buggy
remote end will perform nicely with this, and "new close sequence
aware" servers will know what's happening and behave nicely.
You're looking at, approximately:
send( fd, "<stream:error>[...]</stream:error></stream:stream>", n );
shutdown( fd, SHUT_WR ); /* half-close */
/* Read data until remote end closes */
close( fd );
Remote end behaves either by closing the socket immediately after
half-close, or by formally sending "</stream:stream>" back to
confirm, and then closing.
By the way, you say that, "there has been packet loss in Jabber S2S
communications all along" - I appreciate there's a theoretical risk,
of course, but I didn't realise that there are well-documented cases
of this happening, and I can't find them currently - could you give a
pointer to the list?
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards