If shutdownOutput() doesn’t cause other end to start TCP close

Discussion in 'Java' started by Srubys@gmail.com, Jul 2, 2008.

  1. Guest

    Hiya

    I’m learning about TCP/IP and this stuff is just overwhelming


    1. As far as I understand, when the passive-close end receives the
    FIN, it doesn’t know whether the other end wants to stay in half-close
    state ( in this case it should send data ) or to do full close( in
    this case, it should send FIN )

    We use shutdownOutput() to achieve half close, and close() to fully
    close the connection. Now if none of the two methods force the passive-
    close end to start TCP close sequence, why do we then use shutdown()
    for half close connection? Why not just use close(), since it looks as
    if both methods basically do the same thing ( terminating socket’s
    output stream )?



    2. If app does complete close, then TCP prevents infinite wait in
    FIN_WAIT_2 state with setting the timer to aprox 10 minutes and if
    connection is idle for that time period, TCP moves connection to
    closed state.

    a) But if app does half close, then this timer is not set and TCP
    could be in FIN_WAIT_2 state for a very long time?




    3. If linger on close is set to false, does on close() socket enter
    FIN_WAIT_1 and from there to CLOSING state, or does it enter
    FIN_WAIT_1 and from there to FIN_WAIT_2 state?



    4. If client performs active open, but for some reason server doesn’t
    receive none of client’s acknowledgements of server’s SYN, then:

    a) I’m assuming that client is in established connection state, but
    server is not?

    b) does server go to close state and thus sends FIN or does it go to
    listening state?
    If the latter is true, then we have half open connection?


    thank you
     
    , Jul 2, 2008
    #1
    1. Advertising

  2. On Wed, 2 Jul 2008 11:49:34 -0700 (PDT), wrote:
    > I?m learning about TCP/IP and this stuff is just overwhelming


    Your questions belong in e.g. comp.protocols.tcp-ip, not in
    comp.lang.java.programmer.

    /gordon

    --
     
    Gordon Beaton, Jul 2, 2008
    #2
    1. Advertising

  3. EJP Guest

    wrote:
    > 1. As far as I understand, when the passive-close end receives the
    > FIN, it doesn’t know whether the other end wants to stay in half-close
    > state ( in this case it should send data ) or to do full close( in
    > this case, it should send FIN )


    It knows whether or not it is specified in the application protocol that
    the peer will shutdown the output and continue reading.

    > 2. If app does complete close, then TCP prevents infinite wait in
    > FIN_WAIT_2 state with setting the timer to aprox 10 minutes


    Four minutes.

    > and if connection is idle for that time period, TCP moves connection to
    > closed state.


    No. Idleness has nothing to do with it. There can be no activity on a
    port in this state. At the end of the four minutes TCP will move the
    *port* to state CLOSED. This is required to prevent wrong delivery of
    TCP segments to a new connection using that port number.

    > a) But if app does half close, then this timer is not set and TCP
    > could be in FIN_WAIT_2 state for a very long time?


    No, see above.

    > 3. If linger on close is set to false, does on close() socket enter
    > FIN_WAIT_1 and from there to CLOSING state, or does it enter
    > FIN_WAIT_1 and from there to FIN_WAIT_2 state?


    Neither. THe socket is reset instead of being closed, and goes directly
    to the CLOSED state. *Do not do this*. It is *insecure*.

    > 4. If client performs active open, but for some reason server doesn’t
    > receive none of client’s acknowledgements of server’s SYN, then:
    >
    > a) I’m assuming that client is in established connection state, but
    > server is not?


    Correct.

    > b) does server go to close state and thus sends FIN or does it go to
    > listening state?


    The *accepted socket* never gets out of SYN_RECEIVED, unless it times
    out somewhere, when it will go to closed. The original listening socket
    remains in LISTEN state.

    > If the latter is true, then we have half open connection?


    No. (a) You are confusing the accepted socket with the listening socket.
    They are distinct. (b) The server application will never see a
    connection in SYN_RECEIVED state. (c) Any data that arrives for that
    connection from the peer will cause a connection reset (RST) to be
    issued to the peer.
     
    EJP, Jul 3, 2008
    #3
  4. Guest

    hiya


    > > 2. If app does complete close, then TCP prevents infinite wait
    > > in FIN_WAIT_2 state with setting the timer to aprox 10 minutes

    >
    > Four minutes.
    >
    > > and if connection is idle for that time period, TCP moves
    > > connection to closed state.

    > No. Idleness has nothing to do with it. There can be no activity
    > on a port in this state. At the end of the four minutes TCP will
    > move the *port* to state CLOSED. This is required to prevent
    > wrong delivery of TCP segments to a new connection using that
    > port number.
    >


    But Stevens writes in his book:

    “ … Only when the process at the other end does this close will our
    end move from FIN_WAIT_2 state to the TIME_WAIT state. This means our
    end can remain in this state forever. The other end is still in
    CLOSE_WAIT state and can remain there forever, until the app decides
    to issue its close. Many Berkley derived implementations prevent this
    infinite wait in the FIN_WAIT_2 state as follows. If the application
    that does the active close does a complete close, not a half close
    indicating that it expects to receive data, then a timer is set. If
    the connection is idle for 10 minutes and 75 seconds, TCP moves the
    connection into CLOSED state ”


    > > a) But if app does half close, then this timer is not set and
    > > TCP could be in FIN_WAIT_2 state for a very long time?

    >
    >No, see above.
    >


    But half close enables for one end to close its output and still
    receive data. If socket ( which caused half close connection by
    terminating its output ) in FIN_WAIT_2 state can’t receive any data,
    then what would be the point of having half close?!


    > > 3. If linger on close is set to false, does on close() socket
    > > enter FIN_WAIT_1 and from there to CLOSING state, or does it
    > > enter FIN_WAIT_1 and from there to FIN_WAIT_2 state?

    >
    > Neither. THe socket is reset instead of being closed, and goes
    > directly to the CLOSED state. *Do not do this*. It is
    > *insecure*.
    >


    But my book on Java networking claims that if linger is set to false
    ( which is default ):

    “When the socket is closed, the closing thread is not blocked but the
    socket is not destroyed immediately: it first enters a CLOSING state
    while any remaining data is transmitted and the FIN-ACK close protocol
    is exchanged with the other end. The socket then enters TIME-WAIT
    state, which last for twice the maximum lifetime of a TCP segment”

    I was confused why Stevens would argue that normally socket would go
    from TIME_WAIT_1 to TIME_WAIT_2, while the other author claims
    otherwise. But you are arguing that none of the two claims are true
    for Java sockets?



    > > 4. If client performs active open, but for some reason server
    > > doesn’t receive none of client’s acknowledgements of server’s
    > > SYN, then:
    > > a) I’m assuming that client is in established connection
    > > state, but server is not?

    >
    > Correct.
    >
    > > b) does server go to close state and thus sends FIN or does it
    > > go to listening state?

    > The *accepted socket* never gets out of SYN_RECEIVED, unless it
    > times out somewhere, when it will go to closed. The original
    > listening socket remains in LISTEN state.
    >


    a) I assumed that until connection between client and server is
    established, the connection is formed between the listening socket and
    a client socket. Only when listening socket manages to completely
    establish this connection, does it pass this connection to some Socket
    object. Else, why wouldn’t ServerSocket just pass this connection
    request to some Socket object and return immediately from accept()?!
    Afterall, java docs say that ServerSocket only returns from accept()
    when connection is made.


    b) To which socket are you refering to by “accepted socket”? The
    Socket object which ServerSocket creates and gives it the newly
    established connection?


    thank you
     
    , Jul 3, 2008
    #4
  5. EJP Guest

    wrote:
    > But my book on Java networking claims that if linger is set to false
    > ( which is default ):


    Sorry, I got that wrong. linger on false is indeed the default. What I
    was referring to was linger = true, timeout = 0, which causes an RST to
    be issued. Different thing. My mistake.

    > I was confused why Stevens would argue that normally socket would go
    > from TIME_WAIT_1 to TIME_WAIT_2, while the other author claims
    > otherwise. But you are arguing that none of the two claims are true
    > for Java sockets?


    No, I was confused. Anything it says in Stevens is correct. If the other
    book disagrees, it is wrong. If I disagree, I am wrong too.

    > a) I assumed that until connection between client and server is
    > established, the connection is formed between the listening socket and
    > a client socket.


    Not exactly. The half-formed connection is placed in some internal form
    in an internal queue in the server-side TCP stack. When and if the final
    ACK is received, it is then moved to the listen backlog queue. It really
    only becomes a socket, or a Socket, when returned by accept(). The
    connection is between the client IPaddress:port and the server
    IPaddress:port. The server-side socket, when created, is essentially the
    local representation of that 4-tuple, but it's the 4-tuple itself that
    defines the connection.

    > Only when listening socket manages to completely
    > establish this connection, does it pass this connection to some Socket
    > object.


    Correct.

    > b) To which socket are you refering to by “accepted socket”?


    The Socket returned by accept(). This seems perfectly clear to me.

    > The Socket object which ServerSocket creates and gives it the newly
    > established connection?


    Yes.
     
    EJP, Jul 4, 2008
    #5
  6. Guest

    hiya

    1.
    >
    > Sorry, I got that wrong. linger on false is indeed the default.
    > What I was referring to was linger = true, timeout = 0, which
    > causes an RST to be issued. Different thing. My mistake.
    >


    So then it is true that if app does half close, then the TCP doesn’t
    set the timer and thus TCP could be in FIN_WAIT_2 state for a very
    long time ( and in that state it would also somehow be able to receive
    data from other end )?


    2.Wouldn’t it be useful if passive close end knew whether the other
    end wants to stay in half-close state or do a full close? That way
    passive-end would know whether to also send FIN or keep on sending
    data?! I’m guessing there is a reason why TCP protocol developers
    didn’t enable that option?

    thank you for helping me out
     
    , Jul 7, 2008
    #6
  7. EJP Guest

    wrote:
    > So then it is true that if app does half close, then the TCP doesn’t
    > set the timer and thus TCP could be in FIN_WAIT_2 state for a very
    > long time


    Sure.

    > ( and in that state it would also somehow be able to receive
    > data from other end )?


    No 'somehow' about it. Just call read(), or readLine(), or readXXX for
    some other X. TCP does the rest. Somehow ;-)

    > 2.Wouldn’t it be useful if passive close end knew whether the other
    > end wants to stay in half-close state or do a full close? That way
    > passive-end would know whether to also send FIN or keep on sending
    > data?! I’m guessing there is a reason why TCP protocol developers
    > didn’t enable that option?


    I don't think it makes much sense in the abstract. It's an aspect of a
    specific application protocol.


    >
    > thank you for helping me out
    >
     
    EJP, Jul 7, 2008
    #7
  8. Guest

    thank you for your help

    cheers
     
    , Jul 8, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neo Geshel
    Replies:
    2
    Views:
    3,627
    Versteijn
    Aug 18, 2004
  2. HK
    Replies:
    22
    Views:
    7,418
  3. Noam Raphael
    Replies:
    17
    Views:
    523
    Noam Raphael
    May 26, 2004
  4. Tiger
    Replies:
    5
    Views:
    975
    Dave Thompson
    May 1, 2006
  5. Iñaki Baz Castillo
    Replies:
    7
    Views:
    874
    Iñaki Baz Castillo
    Jan 12, 2010
Loading...

Share This Page