TCP receiver reaction to duplicate data - TCP-IP

This is a discussion on TCP receiver reaction to duplicate data - TCP-IP ; Hello, I'm trying to understand TCP completely, but I'm having some trouble. I can't find some details in the RFCs (793, 2581,1323, and 1122, do I miss any important?). I'm interested in the behaviour of the receiver. Specifically, when exactly ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: TCP receiver reaction to duplicate data

  1. TCP receiver reaction to duplicate data

    Hello,

    I'm trying to understand TCP completely, but I'm having some trouble.
    I can't find some details in the RFCs (793, 2581,1323, and 1122, do I
    miss any important?).
    I'm interested in the behaviour of the receiver. Specifically, when
    exactly should he send ACK's, when may he not send ACKs, and what do
    most implementations do?

    Before I started looking into this I was under the assumption:
    - If you receive a packet, with sequence number RCV.NXT (next sequence
    number expected on an incoming segments, and is the left or lower edge
    of the receive window), delay the ACK, and if this happens a second
    time, ACK the second packet immediatly.
    - If you receive a packet, and the previous case does not hold, that
    is, it's out-of-order (so new data), or duplicate data, send an ACK
    immediatly.
    - Window updates will cause ACKs, which might not be "piggybacked" on
    anything else.
    - Outgoing data also causes ACKs in a way, since all packets in an
    established conenction are ACKs.

    But now I'm in doubt about this. I can't find any conclusive
    information about what happens when duplicate data is received. So the
    main question is:
    Should an ACK be send when a receiver receives duplicate data? If not,
    MAY an ACK be sent? And What do the most common implementations do?

    Any answer to this is very much appreciated!


  2. Re: TCP receiver reaction to duplicate data


    > I'm trying to understand TCP completely, but I'm having some trouble.
    > I can't find some details in the RFCs (793, 2581,1323, and 1122, do I
    > miss any important?).
    > I'm interested in the behaviour of the receiver. Specifically, when
    > exactly should he send ACK's, when may he not send ACKs, and what do
    > most implementations do?
    >
    > Before I started looking into this I was under the assumption:
    > - If you receive a packet, with sequence number RCV.NXT (next sequence
    > number expected on an incoming segments, and is the left or lower edge
    > of the receive window), delay the ACK, and if this happens a second
    > time, ACK the second packet immediatly.
    > - If you receive a packet, and the previous case does not hold, that
    > is, it's out-of-order (so new data), or duplicate data, send an ACK
    > immediatly.
    > - Window updates will cause ACKs, which might not be "piggybacked" on
    > anything else.
    > - Outgoing data also causes ACKs in a way, since all packets in an
    > established conenction are ACKs.
    >
    > But now I'm in doubt about this. I can't find any conclusive
    > information about what happens when duplicate data is received. So the
    > main question is:
    > Should an ACK be send when a receiver receives duplicate data? If not,
    > MAY an ACK be sent? And What do the most common implementations do?


    You will find answers to some of these questions in the TCP/IP sequence
    diagrams at:

    http://www.eventhelix.com/RealtimeMantra/Networking/

    --
    VisualEther 1.0 - http://www.EventHelix.com/VisualEther
    Generate sequence diagram from Wireshark (Ethereal)


+ Reply to Thread