[Standards-JIG] Re: Closing idle streams

Matthias Wimmer m at tthias.eu
Wed May 31 20:24:01 UTC 2006


Carlo v. Loesch wrote:
> | > If you properly close the socket sending </stream:stream>, then the
> | > other side will want to reply with its own </stream:stream>. This
> | > will cause a TCP error and the whole transaction will look like
> | > there was an error even though there wasn't, and poof we're back
> | > in fake-unreliability-land where we are just trying to escape from.
> | >   
> | Why should this cause a TCP error if we only closed the sending half of 
> | the TCP/IP connection? The receiving half will still be available.
>
> If we send proper </stream:stream>, then the other side wants to close
> its </stream:stream> too. It will thus write to the TCP socket and boom
> receive an error because the socket has been closed in the meantime.
>
> If we simply close the socket without sending anything, then the other side
> will wonder why its stream didn't get closed, and consider the operation
> an error. So we have to declare this official by means of RFC. I don't
> think the current RFC allows you to just close a TCP without closing the
> stream first. And closing the stream is a handshake operation, unless
> you output an error first. But then we have an error again.
>
> So the only way to close the socket in both a TCP and XMPP compliant way
> is to do the </stream:stream> handshake, no matter if the socket is
> incoming or outgoing.
>
>   

I did not talk about the outgoing half of a s2s-link.

I only suggested that the outgoing-half of the single TCP/IP connection 
can already be closed. So exactly this TCP/IP connection is closed for 
sending, but not for receiving data. So the recipient of the 
</stream:stream> token can still use the other direction of the same 
TCP/IP connection to send it's own </stream:stream> token.

See "man 2 shutdown" for a discription on how to halfway close a TCP 
connection (in C).


Tot kijk
     Matthias



More information about the Standards mailing list