• old pack problem about tcp fin_wait2 ?

    From Terry Tan@21:1/5 to All on Wed May 9 00:21:22 2018
    Hi all,

    for tcp status fin_wait2, i have a question, which is , if a client of fin_wait2 status can still receive old pack and process them ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Terry Tan on Wed May 9 22:07:51 2018
    On Wed, 2018-05-09, Terry Tan wrote:
    Hi all,

    for tcp status fin_wait2, i have a question, which is , if a client
    of fin_wait2 status can still receive old pack and process them ?

    You mean "if A is in FIN_WAIT_2, can its application still receive data
    from B?"

    As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
    a "half-close". A has ended its stream of data to B, but the stream
    in the opposite direction is intact. B may send as much as it
    pleases, forever, or until A resets.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terry Tan@21:1/5 to All on Sat May 12 22:01:04 2018
    Hi Jorgen,

    Thank you so much for your reply.

    I mean A in state fin_wait2 has already received B's Fin request, A knows the fin_seq, here i mean A received fin request earlier than those pack whose seq is smaller than fin_seq (considering the network problem) ,which means A'acked_seq is still less
    than fin_seq, so A will go to state time_wait ,right? wait for those not received pack?


    Another question is for server B ,when it will change to last_ack? i read the source code of linux 1.2 ,it seems after B notified an EOF to application, then the application calls tcp_close, but in tcp_close,it sends the fins request and just changes
    it's state to fin_wait2 ,rather than last_ack.I am confused that if the last_ack is required ,or maybe under some scenario ,it is not required ?


    Jorgen Grahn於 2018年5月10日星期四 UTC+8上午6時07分54秒寫道:
    On Wed, 2018-05-09, Terry Tan wrote:
    Hi all,

    for tcp status fin_wait2, i have a question, which is , if a client
    of fin_wait2 status can still receive old pack and process them ?

    You mean "if A is in FIN_WAIT_2, can its application still receive data
    from B?"

    As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
    a "half-close". A has ended its stream of data to B, but the stream
    in the opposite direction is intact. B may send as much as it
    pleases, forever, or until A resets.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Terry Tan on Sun May 13 06:31:17 2018
    On Sun, 2018-05-13, Terry Tan wrote:
    Hi Jorgen,

    Thank you so much for your reply.

    Jorgen Grahn於 2018年5月10日星期四 UTC+8上午6時07分54秒寫道:
    On Wed, 2018-05-09, Terry Tan wrote:
    Hi all,

    for tcp status fin_wait2, i have a question, which is , if a client
    of fin_wait2 status can still receive old pack and process them ?

    You mean "if A is in FIN_WAIT_2, can its application still receive data
    from B?"

    As far as I can tell from Stevens' "TCP/IP illustrated: vol 1, this is
    a "half-close". A has ended its stream of data to B, but the stream
    in the opposite direction is intact. B may send as much as it
    pleases, forever, or until A resets.

    I mean A in state fin_wait2 has already received B's Fin request,

    Then I think you are misunderstanding what I wrote. In my scenario,
    A sent the FIN. But let's try your new scenario:

    A knows the fin_seq, here i mean A received fin request earlier than
    those pack

    You mean "TCP segment", I think.

    whose seq is smaller than fin_seq (considering the
    network problem) ,which means A'acked_seq is still less than
    fin_seq, so A will go to state time_wait ,right? wait for those not
    received pack?

    I don't know if it's called TIME_WAIT or not, but yes, I think it's
    the same as any out-of-order reception. If A has received the byte
    with sequence number #1, then receives #3, it cannot do anything about
    it until it has also received #2 to fill the hole.

    I don't think receiving a FIN means "let's drop everything and pretend
    the data stream suddenly ended". That sounds more like what RST does.

    Another question is for server B ,when it will change to last_ack? i
    read the source code of linux 1.2 ,it seems after B notified an EOF
    to application, then the application calls tcp_close, but in
    tcp_close,it sends the fins request and just changes it's state to
    fin_wait2 ,rather than last_ack.I am confused that if the last_ack
    is required ,or maybe under some scenario ,it is not required ?

    I won't try to answer that second (or third) question, but quote it in
    case someone else will.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)