[Standards-JIG] Closing idle streams

Brian Raymond brian.raymond at je.jfcom.mil
Fri Jun 2 15:28:23 UTC 2006

On 6/2/06 9:51 AM, "Michal vorner Vaner" <michal.vaner at kdemail.net> wrote:

> On Fri, Jun 02, 2006 at 08:19:35AM -0400, Brian Raymond wrote:
>> On 6/2/06 3:42 AM, "Carlo v. Loesch" <CvL at mail.symlynX.com> wrote:
>> Deleted..
>>> | 
>>> | The fact that stream errors also happen to mandate subsequent closure
>>> | of the stream actually works in our favour, because it makes the
>>> | whole thing nicely backwards compatible. Partly because - in as much
>>> | as I can tell - it's actually how things work now in many cases.
>>> 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?
>>> So a stream-error is clearly NOT the mechanism suited for signaling
>>> a harmless close of an unused connection. There is no other suited
>>> mechanism and there is no need to introduce one, because there is no
>>> other S2S situation where a stream would be closed without a reason.
>>> Server developers correct me please if I am wrong, but at least in
>>> our server implementation there is no such condition.
>> I'm curious why idle stream closures will end up in packet loss for S2S
>> connections because it's something an implementation should recover from.
>> More and more I have run into stateful firewalls, proxies, or other in line
>> devices that will drop long lived TCP connections if they are idle, or
>> simply live too long. Both sides will assume the connection is still open
>> but when either side tries to send they won't get an ACK back. This is the
>> same thing that will happen if one side has data on the wire while the other
>> side closes; no ACK means it didn't get there.
>> Given both of these scenarios should we recommend that a server attempts to
>> recover in that state and not simply toss the data if it didn't get a TCP
>> ACK back?
> We already had this discussion in jep-ack thread. Look at this:
> 1) Connection stays idle for a long time, therefore, one side terminates
> it by dropping the socket.
> 2) Before the closing reaches the other side, the other side sends
> something. It thinks it is done with it, since it entered into the
> socket.
> 3) Close reaches the other side. It sees close and knows the socket can
> not be used any more. However, the software is unable to track what was
> and what was not delivered, since the socket is already in closed state,
> and the socket acts in one way, what you put there, you see never more.
> So, we can recommend servers to recover. But if it is technically
> impossible for them today (yes, would could rewrite the sockets to
> something better, we could rewrite the complete OS, but who would do it,
> it would not be easy). So, this recommendation is useless.

It's completely possible with existing sockets, and not a technical issue.
If I write to a socket and the peer has closed it in the meantime I'll get a
TCP RST. If the system is using a "stealth" mode of some sort that just
swallows packets without a RST I still won't get an ACK from the far side
acknowledging delivery. In any case it does boil up to the application, how
it boils up is somewhat dependent on the implementation in the OS and the
language used (java, C, etc.). It's a feature of TCP that has been available
for decades, guaranteed delivery.

> By agreeing on closing the socket, both sides know the socket will not
> be used any more and can safely close them, because there is nothing on
> the way between.

I agree if one side wants to close a socket it should notify the other side
because it is safer. In the context of TCP this means both sides close the
socket and are aware of it being closed. That is the method by which a
number of TCP apps know the socket has been closed. With that said, you
cannot count on it because the socket can get "closed" by an in line device
without either side knowing it happened.

More information about the Standards mailing list