Is this good TCP close behavior? - TCP-IP

This is a discussion on Is this good TCP close behavior? - TCP-IP ; Greetings! I've recently observed a connection which does the following: All segments in both directions have been acknowledged, and there is no data in flight. Host A then begins to close the connection: 1: A -> B : [FIN,ACK] Seq=152, ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Is this good TCP close behavior?

  1. Is this good TCP close behavior?

    Greetings!

    I've recently observed a connection which does the following:

    All segments in both directions have been acknowledged, and there is
    no data in flight. Host A then begins to close the connection:

    1: A -> B : [FIN,ACK] Seq=152, Ack=879, Len=0
    2: B -> A : [PSH,ACK] Seq=879, Ack=153, Len=0
    ....nearly a minute passes...
    3: B -> A : [PSH,ACK] Seq=879, Ack=153, Len=278
    4: A -> B : [RST] Seq=153, Ack=0, Len=0

    In this scenario, host A is an HTTP server, and host B is the client.
    'A' closed the connection because it reached the limits of it's HTTP
    1.1 persistency timer. The third segment in this exchange is a new
    POST command from 'B'.

    ....So, a few questions:

    1) Increasing the ACK number to 153 is appropriate in segments 2 and
    3, right? I'm guessing this is a special case where the FIN flag
    increments the sequence, but no application data is associated with
    byte 152.

    2) I think that during the interval between segments 2 and 3, 'A' is
    in fin_wait_2, and 'B' is in close_wait. Does that seem right?

    3) I think that 'A' can no longer send any data, but is required to
    process any incoming segments until 'B' sends his FIN. Has the
    application code on 'A' done something inappropriate that causes the
    RST to be sent?

    4) Even if 'A' is wrong in not processing segment 3, it's kind of
    moot: This is an HTTP transaction. There's no way the http server on
    'A' can respond to the client on 'B' after having sent FIN and seeing
    it get ACKed. Does all the blame then rest with the client on 'B' for
    sending data to a server when it knows (should know) that the socket
    in close_wait?

    Thanks very much!

    /chris


  2. Re: Is this good TCP close behavior?

    Rather than call shutdown(SHUT_WR), A has probably called close(),
    which is equivalent to shutdown(SHUT_RDWR). A has explicitly told the
    stack it does not expect to receive any more data, so when data
    arrives the stack senses a broken application handshake and emits the
    RST.

    It isn't the best close behaviour on the part of the application, but
    it is common.

    IMO the best close behaviour would be for A to have issued a
    shutdown(SHUT_WR) on the socket, and then left the socket around for
    "a while" (nice precise length of time until it too could get the
    read return of zero indicating the remote had also called shutdown
    (actually, the side which goes second could just call close()) at
    which point it can call close() or perhaps try to reuse the socket
    somehow (within the limits of the sockets interface).

    Of course, A _could_ have been doing that, and had about a minute as
    its definition of "a while" and then called close(). Since a FIN had
    already been sent, nothing new would be emitted on the connection. A
    system call trace of A would be required to see which of the two
    scenarios (or perhaps a third I've not thought of) took place.

    Now, since you say it was nearly a minute before the data arrived, it
    also suggests that the client application was at least slightly
    broken. It should almost certainly have gotten a read return of zero
    telling it that the remote had said it would send no more data. In
    that case, there isn't much sense sending the server another request
    on that connection since there will be no response data, and so the
    client should have just called close(). If it wanted to issue another
    request to the same server, it should then open another connection,
    which is what it will have had to do in this case anyway, only the way
    it behaved managed to short-circuit TIME_WAIT

    rick jones
    --
    Process shall set you free from the need for rational thought.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: Is this good TCP close behavior?

    Thanks very much for your insight, Rick.

    On Jun 11, 12:33 pm, Rick Jones wrote:
    > IMO the best close behaviour would be for A to have issued a
    > shutdown(SHUT_WR) on the socket, and then left the socket around for
    > "a while" (nice precise length of time until it too could get the
    > read return of zero indicating the remote had also called shutdown




    > Of course, A _could_ have been doing that, and had about a minute as
    > its definition of "a while" and then called close().


    This careful socket handling you describe sounds great, but I think it
    might be academic in the context of an HTTP session. When the server
    has shutdown his end of the connection, the HTTP session is forever
    destroyed.

    I can't think of any (within the bounds of HTTP) use in receiving
    further segments from the client if the server can't reply.


    > Now, since you say it was nearly a minute before the data arrived, it
    > also suggests that the client application was at least slightly
    > broken.


    Only slightly?

    > It should almost certainly have gotten a read return of zero
    > telling it that the remote had said it would send no more data. In
    > that case, there isn't much sense sending the server another request
    > on that connection since there will be no response data, and so the
    > client should have just called close().


    That's pretty much my position on the matter. Sending a new HTTP
    request to the server was silly in this context. Even if the server
    kept the socket around as you described above, the HTTP session still
    wasn't going to work.

    Incidentally, here's a detail I omitted from the original post, so
    that I would be the only one prejudiced by it:
    'A', the http server is apache on solaris.
    'B', the client, is homegrown code running on a mainframe.

    > If it wanted to issue another
    > request to the same server, it should then open another connection,
    > which is what it will have had to do in this case anyway, only the way
    > it behaved managed to short-circuit TIME_WAIT


    Hrm, I don't think I understand. Could you elaborate?

    /chris


  4. Re: Is this good TCP close behavior?

    > This careful socket handling you describe sounds great, but I think
    > it might be academic in the context of an HTTP session. When the
    > server has shutdown his end of the connection, the HTTP session is
    > forever destroyed.


    > I can't think of any (within the bounds of HTTP) use in receiving
    > further segments from the client if the server can't reply.


    Mostly it is to deal with the possibility of a race condition.
    Consider the case of a server deciding to call close() at exactly the
    same time the client calls send(). The server's FIN and the client's
    HTTP request will pass in the network..

    > > Now, since you say it was nearly a minute before the data arrived,
    > > it also suggests that the client application was at least slightly
    > > broken.


    > Only slightly?


    Perhaps I am becoming overly diplomatic as I get older?-)

    > > If it wanted to issue another request to the same server, it
    > > should then open another connection, which is what it will have
    > > had to do in this case anyway, only the way it behaved managed to
    > > short-circuit TIME_WAIT


    > Hrm, I don't think I understand. Could you elaborate?


    RST (modulo a newer RFC that may or may not have wide adoption?) will
    kill a TCP endpoint with extreme predjudice. Poof, gee wiz, all gone.
    As such it will either bypass or prematurely terminate TIME_WAIT.
    TIME_WAIT is the state one end or the other is to enter to maintain
    enough state for the four-tuple of local/remote IP, local/remote port
    to be statistically certain that a new connection by the same "name"
    (that four-tuple) will not receive an old, delayed segment from the
    previous connection with that name.

    Now, from the standpoint of the client, it could look (correctly IMO)
    for the read return of zero, or it could decide not to - at least when
    it isn't looking for data from the server. The client calls send()
    rather than say select()/read(), the send() doesn't fail (since a FIN
    says nothing about receiving data), and then when the client otherwise
    "normally" enters select/poll/whatever to wait for the reply data, it
    gets the connection failure that is indicated by the reciept of the
    RST segment. Then it goes "oops" and can decide to open a new
    connection. Perhaps that was "easier" to code.

    What the client should really be doing, is keeping a
    select/poll/whatever going on that persistent connection to the
    server, even when it isn't expecting data. That way it can see the
    read retorn of zero, and instead of going through the sequence that
    causes the RST, simply finish the connection close and open a new one.

    However, the remote server _cannot_ simply call close() as this still
    leaves that simultaneous close/send race, which is why it needs
    to/should call shutdown() and be prepared to drain requests off to
    /dev/null until the client's FIN arrives (or a timer of sufficient
    length expires).

    Switching back to the RST case again though... RSTs are "unreliable"
    which means that when this broken client blindly sends the request to
    the server, there is no guarantee that the RST will actually make it
    back, and it will not be retransmitted by the server. The client will
    now be "stuck" for at least the length of the client TCP's
    retransmission timer plus one RTT as his request gets retransmitted
    and elicits another RST.

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: Is this good TCP close behavior?

    Rick Jones writes:

    > Mostly it is to deal with the possibility of a race condition.
    > Consider the case of a server deciding to call close() at exactly the
    > same time the client calls send(). The server's FIN and the client's
    > HTTP request will pass in the network..


    The perfect behavior to handle the crossed FIN/SEND is for the server
    to send a RST when it gets the data from the SEND, which is exactly
    what it does if the server calls close(). The way you are trying to
    handle it, the server's TCP connection will *accept and acknowledge*
    as much data as the client sends it, misleading the client into
    thinking that something useful was going to happen to it.

    By the way, to the original problem, it's almost certainly that the
    home grown client isn't getting the EOF signal when the FIN comes in
    with no data in sight. A typical bug in client code is to ignore
    read indications when the application isn't trying to communicate.
    While the client is waiting for more work to do, it needs to monitor
    the read signal just so it can handle this event.

    -don provan

  6. Re: Is this good TCP close behavior?

    don provan wrote:
    > Rick Jones writes:


    > > Mostly it is to deal with the possibility of a race condition.
    > > Consider the case of a server deciding to call close() at exactly
    > > the same time the client calls send(). The server's FIN and the
    > > client's HTTP request will pass in the network..


    > The perfect behavior to handle the crossed FIN/SEND is for the
    > server to send a RST when it gets the data from the SEND, which is
    > exactly what it does if the server calls close(). The way you are
    > trying to handle it, the server's TCP connection will *accept and
    > acknowledge* as much data as the client sends it, misleading the
    > client into thinking that something useful was going to happen to
    > it.


    I have to disagree, fairly strongly because:

    1) A RST blows-away TIME_WAIT

    2) An application must never ass-u-me that simply because TCP has
    ACKnowledged receipt of data at the TCP layer that the remote
    application will work on it, or even received it.

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: Is this good TCP close behavior?

    Rick Jones writes:

    > don provan wrote:
    >> Rick Jones writes:

    >
    >> > Mostly it is to deal with the possibility of a race condition.
    >> > Consider the case of a server deciding to call close() at exactly
    >> > the same time the client calls send(). The server's FIN and the
    >> > client's HTTP request will pass in the network..

    >
    >> The perfect behavior to handle the crossed FIN/SEND is for the
    >> server to send a RST when it gets the data from the SEND, which is
    >> exactly what it does if the server calls close(). The way you are
    >> trying to handle it, the server's TCP connection will *accept and
    >> acknowledge* as much data as the client sends it, misleading the
    >> client into thinking that something useful was going to happen to
    >> it.

    >
    > I have to disagree, fairly strongly because:
    >
    > 1) A RST blows-away TIME_WAIT


    If the connection does not go into the TIME_WAIT state, that will mean
    that any subsequent packets will also receive RSTs. Why is that a
    problem? (It actually turns out that this does *not* "blow away"
    TIME_WAIT: the connection is stuck in FIN_WAIT2 and would remain there
    *forever* if we used the implementation you are suggesting. I *like*
    the idea of the system discarding the connection (i.e., blowing *past*
    TIME_WAIT) if it received data in this state, but I don't think any
    systems do that. I hope I'm wrong, though, now that you bring it up!)

    > 2) An application must never ass-u-me that simply because TCP has
    > ACKnowledged receipt of data at the TCP layer that the remote
    > application will work on it, or even received it.


    Well, of course, that depends on the application. In this case, it's
    true that an HTTP client shouldn't assume the request was successful
    unless it gets a positive HTTP reply (and we hope that's true in this
    case, even though we already know the HTTP client is faulty). But I
    was speaking more to the general case of what any arbitrary
    application that has decided a connection is stale and should be
    terminated. Telnet would a trivial example of the problem: with
    Telnet, accepting the data does, in fact, promise to deliver it to the
    application in the absence of any error signal, and an error signal is
    precisely what can never be sent with the implementation you are
    proposing.

    But really, in this HTTP case, there's a much more obvious reason to
    want the RST response: the application is wasting time and bandwidth
    sending the data. The server is the only component in the system that
    understands that (given that the client did not see or did not
    comprehend the FIN), so it is the server's responsibility for finding
    a way to inform the client of this problem. A complete close of the
    socket (i.e., the UNIX implementation of close: there's not really a
    corresponding concept in the TCP protocol) does this neatly.

    -don provan

  8. Re: Is this good TCP close behavior?

    > > 1) A RST blows-away TIME_WAIT

    > If the connection does not go into the TIME_WAIT state, that will
    > mean that any subsequent packets will also receive RSTs. Why is that
    > a problem?


    A connection by that name has existed. One end should then remain in
    TIME_WAIT until statistically certain that any delayed segments ahve
    died on the network. If the first arriving request (as in this case)
    after the close() nukes TIME_WAIT (which it can unless newer RFCs are
    about) then we lose that protection.

    > (It actually turns out that this does *not* "blow away" TIME_WAIT:
    > the connection is stuck in FIN_WAIT2 and would remain there
    > *forever* if we used the implementation you are suggesting.


    FIN_WAIT_2 implies that the client code here has called close() or
    shutdown to trigger a FIN. It hasn't done that, it has called send()
    after the server has called close(). So, I don't think we are going
    down that path. The server's RST triggered by the clients request
    will nuke the client's connection from CLOSE_WAIT (since it has
    received a FIN from the remote).

    Being stuck forever in FIN_WAIT_2 is something which happens when that
    side initiates close (sends the FIN) and has it ACKed, but then the
    other end terminates with an abortive close and the resulting RST is
    lost in the network. An entirely different issue, all together.

    > I *like* the idea of the system discarding the connection (i.e.,
    > blowing *past* TIME_WAIT) if it received data in this state, but I
    > don't think any systems do that. I hope I'm wrong, though, now that
    > you bring it up!)


    It might be arguably a slight hole in the TCP spec that there is only
    just the one RST and not also an ABT (ABorT). So, there is no way to
    signal to the user that he has done something stupid without also
    blowing away connection state.

    > > 2) An application must never ass-u-me that simply because TCP has
    > > ACKnowledged receipt of data at the TCP layer that the remote
    > > application will work on it, or even received it.


    > Well, of course, that depends on the application.


    I don't see how. _All_ TCP says is that it will provide an indication
    of _probable_ failure to deliver data. It says nothing about
    provbiding indications of actual remote client data reciept.

    > In this case, it's true that an HTTP client shouldn't assume the
    > request was successful unless it gets a positive HTTP reply (and we
    > hope that's true in this case, even though we already know the HTTP
    > client is faulty).


    An application-level "protocol" or semantic if you like, but nothing
    involving TCP. Indeed, the only way an application can know that the
    remote application has done anything with the data is to get an
    application level message back of some sort - as you give in the
    example above, the HTTP response to the HTTP request.

    > But I was speaking more to the general case of what any arbitrary
    > application that has decided a connection is stale and should be
    > terminated. Telnet would a trivial example of the problem: with
    > Telnet, accepting the data does, in fact, promise to deliver it to
    > the application in the absence of any error signal, and an error
    > signal is precisely what can never be sent with the implementation
    > you are proposing.


    What I was talking about was an algorithm for tearing down a
    connection. It would presume that any positive indication of work
    completion had already taken place.

    > But really, in this HTTP case, there's a much more obvious reason to
    > want the RST response: the application is wasting time and bandwidth
    > sending the data.


    The application is sending a request to trigger the RST. The
    asynchronous nature of getting the RST back means that unless the
    client is really slow, or somehow window constrained, the entire
    request is going to get out onto the network before the RST arrives
    anyway, so there really isn't any savings. Now, if the application is
    indeed trying to send boatloads of data, the RST could short circuit
    that, but again we are talking about what is arguably a bug in the
    handshake between the client and server applications that the client
    is sending this data in the first place.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  9. Re: Is this good TCP close behavior?

    Rick Jones writes:

    > A connection by that name has existed. One end should then remain in
    > TIME_WAIT until statistically certain that any delayed segments ahve
    > died on the network.


    Keep in mind that TIME_WAIT is waiting so straggling segments don't
    generate a RST because that RST could mislead the sender into thinking
    that the connection failed to close gracefully even though it really
    did. Guess what? The connection *did* fail to close gracefully, so we
    *want* to respond to those those delayed packets with RSTs.

    > FIN_WAIT_2 implies that the client code here has called close() or
    > shutdown to trigger a FIN.


    With all due respect, go read your text book again and come back when
    you understand what's going on in the protocol. Keep in mind that
    we're talking about the behavior of the server application, so it's
    the state of the server's side of the connection that we're talking
    about. Hint: *Who* has called close()? *Who* has triggered a FIN?

    After you've learned this state transition, maybe we can go on to
    discuss the data handling.

    -don provan

  10. Re: Is this good TCP close behavior?

    > Keep in mind that TIME_WAIT is waiting so straggling segments don't
    > generate a RST because that RST could mislead the sender into
    > thinking that the connection failed to close gracefully even though
    > it really did. Guess what? The connection *did* fail to close
    > gracefully, so we *want* to respond to those those delayed packets
    > with RSTs.


    I thought the main reason behind TIME_WAIT was to protect a new
    connection with the same "name" (four-tuple) from mistakenly accepting
    straggling segments from the previous connection.

    RST is supposed to be for fatal protocol-level problems. However, it
    gets overloaded with "the client and server app didn't agree on
    shutdown procedures."

    > > FIN_WAIT_2 implies that the client code here has called close() or
    > > shutdown to trigger a FIN.


    > With all due respect, go read your text book again and come back when
    > you understand what's going on in the protocol. Keep in mind that
    > we're talking about the behavior of the server application, so it's
    > the state of the server's side of the connection that we're talking
    > about. Hint: *Who* has called close()? *Who* has triggered a FIN?


    I don't know why I thought the discussion had gotten flipped around
    the other way, but endedup there somehow. That may be at the root of
    much of the disagreement.

    rick jones
    --
    portable adj, code that compiles under more than one compiler
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  11. Re: Is this good TCP close behavior?

    Rick Jones writes:

    > I thought the main reason behind TIME_WAIT was to protect a new
    > connection with the same "name" (four-tuple) from mistakenly accepting
    > straggling segments from the previous connection.


    If that were the purpose, then both ends would have to go into that
    state. In your defense, I think a lot of people get taught that myth.
    I assume it comes from misunderstanding why the timeout is 2*MSL.

    > RST is supposed to be for fatal protocol-level problems. However, it
    > gets overloaded with "the client and server app didn't agree on
    > shutdown procedures."


    You have a point here: RST is sometimes abused, and we need to be
    careful that the protocol operates effectively. Indeed, RST's been
    overloaded with "nothing's wrong, but end the connection" (at one
    point, Windows applications did this, for example). But it's perfectly
    reasonable for the application layer protocol to depend on RST as a
    signal to indicate confusion over what state the TCP connection should
    be in. In this case, you could argue that HTTP was badly designed
    because it allows the server to close the connection without
    confirming that new state through HTTP messages, but given the HTTP
    protocol as it exists, since the server *is* allowed to close the TCP
    connection without warning, then this method of close with the RST
    reaction to data, is the best implementation now that we've reviewed
    the protocol behavior for problems.

    > I don't know why I thought the discussion had gotten flipped around
    > the other way, but endedup there somehow. That may be at the root of
    > much of the disagreement.


    No problem. Happens all the time.

    -don provan

  12. Re: Is this good TCP close behavior?

    don provan wrote:
    > Rick Jones writes:


    > > I thought the main reason behind TIME_WAIT was to protect a new
    > > connection with the same "name" (four-tuple) from mistakenly
    > > accepting straggling segments from the previous connection.


    > If that were the purpose, then both ends would have to go into that
    > state.


    Why?

    > In your defense, I think a lot of people get taught that myth. I
    > assume it comes from misunderstanding why the timeout is 2*MSL.


    So TIME-WAIT isn't meant to protect a new connection by the same name
    from old segments from the previous connection?

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  13. Re: Is this good TCP close behavior?

    In article ,
    don provan wrote:

    > You have a point here: RST is sometimes abused, and we need to be
    > careful that the protocol operates effectively. Indeed, RST's been
    > overloaded with "nothing's wrong, but end the connection"


    Because TCP provides no way to say that explicitly, as we're discussing
    over in the thread about what the Stop button does in web browsers. TCP
    only has a way to say "I'm done sending to you", but no way to say
    "Please stop sending to me."

    I think the designers expected that this would be handled in the
    application layer. An example is FTP's "ABOR" command, which tells the
    server to stop a file transfer that's in progress. But few application
    protocols have a similar mechanism.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  14. Re: Is this good TCP close behavior?

    Rick Jones writes:

    > don provan wrote:
    >> Rick Jones writes:

    >
    >> > I thought the main reason behind TIME_WAIT was to protect a new
    >> > connection with the same "name" (four-tuple) from mistakenly
    >> > accepting straggling segments from the previous connection.

    >
    >> If that were the purpose, then both ends would have to go into that
    >> state.

    >
    > Why?


    To keep it from opening such a connection. Think about what you're
    saying: the TIME_WAIT is only "protecting" a new connection for the
    same socket by being in the way: you can't open such a socket because
    the socket in TIME_WAIT state is already there. If that were the
    purpose, you'd need that socket to "be there" on both sides of the
    original connection to prevent *either* of them from trying to open
    the same connection again.

    >> In your defense, I think a lot of people get taught that myth. I
    >> assume it comes from misunderstanding why the timeout is 2*MSL.

    >
    > So TIME-WAIT isn't meant to protect a new connection by the same name
    > from old segments from the previous connection?


    Nope. It's purpose is to handle the case where the last ACK is lost.
    In that case, the other end will retransmit the FIN. Without
    TIME_WAIT, that retransmission would receive a RST response. That
    would leave the local system "knowing" that the three way handshake
    completed successfully while the remote system thinks it fails.
    -don

  15. Re: Is this good TCP close behavior?

    Barry Margolin writes:

    > In article ,
    > don provan wrote:
    >
    >> You have a point here: RST is sometimes abused, and we need to be
    >> careful that the protocol operates effectively. Indeed, RST's been
    >> overloaded with "nothing's wrong, but end the connection"

    >
    > Because TCP provides no way to say that explicitly, as we're discussing
    > over in the thread about what the Stop button does in web browsers. TCP
    > only has a way to say "I'm done sending to you", but no way to say
    > "Please stop sending to me."


    The three way handshake is the perfect way to say "nothing's wrong,
    but end the connection." I agree with you that there's no way for the
    application to say, "WTF? Why are you sending data to me now that I'm
    trying to close the connection," which is why I've been agreeing with
    you that an implementation that gives up on the three way handshake
    and sends RST instead in that case is perfectly reasonable.

    > I think the designers expected that this would be handled in the
    > application layer. An example is FTP's "ABOR" command, which tells the
    > server to stop a file transfer that's in progress. But few application
    > protocols have a similar mechanism.


    To some degree. Also they thought Telnet would be used a lot more, so
    Abort Output could be used without having to tear down the connection.

    > Barry Margolin, barmar@alum.mit.edu


    Nice to see you again.
    -don

  16. Re: Is this good TCP close behavior?

    In article ,
    don provan wrote:

    > Barry Margolin writes:
    >
    > > In article ,
    > > don provan wrote:
    > >
    > >> You have a point here: RST is sometimes abused, and we need to be
    > >> careful that the protocol operates effectively. Indeed, RST's been
    > >> overloaded with "nothing's wrong, but end the connection"

    > >
    > > Because TCP provides no way to say that explicitly, as we're discussing
    > > over in the thread about what the Stop button does in web browsers. TCP
    > > only has a way to say "I'm done sending to you", but no way to say
    > > "Please stop sending to me."

    >
    > The three way handshake is the perfect way to say "nothing's wrong,
    > but end the connection." I agree with you that there's no way for the
    > application to say, "WTF? Why are you sending data to me now that I'm
    > trying to close the connection," which is why I've been agreeing with
    > you that an implementation that gives up on the three way handshake
    > and sends RST instead in that case is perfectly reasonable.


    But there's no way to tell the other side to perform its part of the
    3-way handshake. You send a FIN, which means "I'm done sending". But
    that doesn't necessarily mean "please stop sending". TCP has the notion
    of half-closed connections, where one side has sent a FIN, but the other
    one isn't expected to send its FIN until it has finished sending all the
    data. Consider the following command:

    ssh hostname sort < filename

    This will start an ssh session, send the "sort" command to it, send the
    contents of filename (which sort will receive on its standard input),
    and then send a FIN (using shutdown(fd, SHUT_WR) in the sockets API),
    which will cause sort to read EOF. Then sort will start sending the
    sorted result and exit, which will cause the ssh server to close the
    connection, sending a FIN. The client socket will be in FIN-WAIT-2
    state while it's receiving the results, and the server socket will be in
    CLOSE-WAIT.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  17. Re: Is this good TCP close behavior?

    Barry Margolin writes:

    > But there's no way to tell the other side to perform its part of the
    > 3-way handshake.


    That's correct. The interpretation of FIN is an application issue.
    Most applications that I can think of do take the FIN as meaning that
    the other side should also close the connection, but only after it's
    done transmitting what it needs to transmit. With the addition of the
    full duplex close unrelated to the protocol, an application such as
    HTTP has no problem implemented handling data (by rejecting it) after
    the close, something it would have to do no matter what FIN meant to
    the other side, since they otherside could send the additional data
    *before* receiving the "I'm not listening to you any more" FIN.

    I guess I'm missing your point. Your acting like we don't agree about
    something, but I don't see what it is.
    -don

  18. Re: Is this good TCP close behavior?

    Rick, Don and Barry:

    This has been a very enlightening discussion for me. Thanks very
    much!

    /chris


  19. Re: Is this good TCP close behavior?

    In article ,
    don provan wrote:

    > I guess I'm missing your point. Your acting like we don't agree about
    > something, but I don't see what it is.
    > -don


    You wrote:

    > > The three way handshake is the perfect way to say "nothing's wrong,
    > > but end the connection."


    How can this be the "perfect way" when it's actually ambiguous? It can
    mean either "I'm done sending, but you may continue sending to me" or
    "let's end the connection." The only way to tell is by whether you
    respond to further packets with RST.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  20. Re: Is this good TCP close behavior?

    Barry Margolin writes:

    > How can this be the "perfect way" when it's actually ambiguous? It can
    > mean either "I'm done sending, but you may continue sending to me" or
    > "let's end the connection." The only way to tell is by whether you
    > respond to further packets with RST.


    OK. We both agree on the protocol, but we disagree about whether this
    solution can be considered "perfect". My observation was that even
    *if* there was a unambiguous FIN (I called it the "I'm not listening
    to you any more" FIN), you'd *still* be stuck with nothing to do but
    respond with RST if your peer had sent a packet *before* you send the
    FIN. Of course, we could invent more stuff to solve *that* problem,
    but I'm not sure how the end result would be better in any significant
    way. I think we're into an area were the solution is in the
    application layer.

    -don

+ Reply to Thread
Page 1 of 2 1 2 LastLast