[Standards-JIG] Closing idle streams
Michal vorner Vaner
michal.vaner at kdemail.net
Fri Jun 2 15:58:37 UTC 2006
On Fri, Jun 02, 2006 at 11:28:23AM -0400, Brian Raymond wrote:
> 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.
Guaranteed delivery - yes, guaranteed by the life of the connection.
Deliver it or die.
I can detect when something got wrong. But it is hard to know what
exactly went wrong.
I do not see a way how to get the unsent data back. I must admit, I did
not study the socket interface too much, but as much as I understand it,
you either get the socket closed in a clean way and you know your data
went trough, or you know there was a problem.
OK, if you get it back out again, what do you do with it? If it is only
the other side closed it because it was idle, then the whole stanza
comes out. OK, nice, it can be handled, but it must be parsed again and
But, what if someone pulled the cable somewhere in the middle and you
get acked only half of stanza. Something like:
comes out. So nice, I know something odd happened, something did not get
trough. But what to do with it?
> > 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.
This message has optimized support for formating.
Please choose green font and black background so it looks like it should.
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