[Standards-JIG] Closing idle streams
Michal vorner Vaner
michal.vaner at kdemail.net
Fri Jun 2 13:51:21 UTC 2006
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:
> > |
> > | 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
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.
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.
One semi-random fortune:
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
-- Fred Brooks
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards