What are valid ‘ack’ values

tcp

having an issue with a vendor who claims the cause of a problem is an invalid 'ack' value in the tcp data. I'm using java so I didn't write this layer. I used snoop to capture the traffic on the wire and am using wireshark to display the data. Here is what is happening. After receiving a multi-packet(5) message I see a multi-pack(3) response. The first packet in the response has a value for 'ack' that is different than the 'ack' value in the other two packets. The vendor claims this data is suspect. I've provided sample data below. I'm not a tcp expert so I don't know if this is a problem or not. I've tried to find something on valid ack values and it seems to me the value should be 80018 but that doesn't mean the 78345 is wrong. I found this on the web and it seems to apply but I'm not sure: "the ack value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send". Thanks for your help. My understanding is the vendor has written their own tcp layer.

    source seq     ack    len   time
    me     10734   75465  190   yyyymmdd 09:18:21.785757
    vendor 75465   10924  0     yyyymmdd 09:18:21.789319
    vendor 75465   10924  1440  yyyymmdd 09:18:34.196661
    vendor 76905   10924  1440  yyyymmdd 09:18:34.196762
    vendor 78345   10924  1440  yyyymmdd 09:18:34.196901
    vendor 79785   10924  233   yyyymmdd 09:18:34.196915
    me     10924   78345  0     yyyymmdd 09:18:34.196968
    me     10924   80018  0     yyyymmdd 09:18:34.197102
    me     10924   80018  197   yyyymmdd 09:18:34.579479

Best Answer

http://en.wikipedia.org/wiki/Transmission_Control_Protocol says

Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.

This suggests that the first reply packet is acknowledging receipt of the first three packets from vendor (seq 76905 + len 1440 = 78345)

The second reply packet acknowledges receipt of the 4th and 5th packets from vendor (seq 79785 + len 233 = 80018)

The third reply packet indicates no futher data has been received from vendor (same ack) and contains a payload of 197 bytes.

This looks OK to me.

If your data is the whole conversation, the initial ack would be wrong as it should ack the first packet from vendor with an ack of 75465 (seq 75465 + 1 = 75466).

Here is a sequence I captured with wireshark, First we see the three-way handshake, then the transmission of a HTTP get request followed by an HTTP response

Source    Flags      Seq      Ack     Len  
client    SYN          0        -       0  
server    SYN,ACK      0        1       0  
client    ACK          1        1       0  
client    -            1        1     429     Get ...
server    ACK          1      430       0  
server    -            1      430    1456     HTML response
server    -         1457      430    1456  
client    ACK        430     2913       0  
...

The sequence and ack numbers are relative (to each end's randomly chosen starting number)

Using a single connection for a sequence of requests is a common optimisation. It was added to HTTP at version 1.1 and known as persistent connections. Setting up and tearing down TCP connections has a cost.

Related Topic