[Standards-JIG] Re: Closing idle streams
Carlo v. Loesch
CvL at mail.symlynX.com
Wed May 31 20:14:24 UTC 2006
Matthias Wimmer typeth:
| Carlo v. Loesch wrote:
| > Carlo v. Loesch typeth:
| > | Matthias Wimmer typeth:
| > | | At least you can already close the sending half of a TCP/IP connection
| > | | after you sent the </stream:stream>. It is enough to keep the receiving
| > | | half of the connection open.
| > |
| > | Oh you are right, thank you.
| > | You mean the outgoing TCP line though.
| > No wait, it's not that simple.
| > 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.
More information about the Standards