[Standards-JIG] Closing idle streams

Brian Raymond brian.raymond at je.jfcom.mil
Fri Jun 2 12:19:35 UTC 2006




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?



More information about the Standards mailing list