adnan@sgtech.UUCP (Adnan Yaqub) (10/12/89)
I was looking over the Berkeley TCP code and began to wonder what happens when TCP sequence numbers wrap. In the tcp_input routine duplicate acks are detected by the check (after macro expansion): (int) (segment ack - last unacknowledged) <= 0 It seems to me that if I send a message which ends at, say, sequence number (2**32)-1, then when the ack arrives (which would be 0) I would reject it as a duplicate. Is this comething which is not worried about, or am I missing something? -- Adnan Yaqub Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860 ...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan
solensky@interlan.interlan.COM (Frank Solensky) (10/13/89)
In <ADNAN.89Oct12083745@sgtech.UUCP>, Adnan Yaqub asks: I was looking over the Berkeley TCP code and began to wonder what happens when TCP sequence numbers wrap. In the tcp_input routine duplicate acks are detected by the check (after macro expansion): (int) (segment ack - last unacknowledged) <= 0 It seems to me that if I send a message which ends at, say, sequence number (2**32)-1, then when the ack arrives (which would be 0) I would reject it as a duplicate. Is this comething which is not worried about, or am I missing something? The only difference between "signed" and "unsigned" integers is how the values will be interpreted once they are at or above 2**(N-1), where N represents the integer length on your machine. The large unsigned positive value in your "last acknowledged" can also be thought of as a large signed negative, as the casting of the result will do. Say the last ack is (2**32)-100. That will be stored the same way as the value -100. The expression becomes (int)(0 - (-100)) == (int)(0+100) = 100. So the ack isn't tossed. -- Frank Solensky Racal InterLan