[Standards-JIG] Closing idle streams

[Dave Cridland]

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 
> talk
> | to that server again, or...
> 
> No, those are all covered by other conditions in 4.7.3 like
> <system-shutdown/>, <policy-violation/> or even 
> <undefined-condition/>
> 
> 
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 
default?


> | I don't think there's any benefit in eliding the error, and I 
> don't
> | 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 
> error.
> 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:

int fd;
[...]
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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade