Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
    
Thank you for taking the time to respond to my question. And no this is not the whole conversation. Just a small exchange with the vendor. I do have a follow up if you don't mind. The conversation is listed in order on the wire. Why would my first response be for just the first 3 packets? Why not just send 1 reply for all 5 packets plus my response payload? Or 1 reply for the 4 packets and a separate reply with my response payload? And while I'm treading on your good will I'll pile on some more if you are game? –  WileECanisLatrans Dec 30 '10 at 14:25
    
It seems to me if I'm going to receive a series of request that each request should establish a connection exchange information (request/response) and close the connection. But this vendor decided to open a connection. Send requests as they are available and send a heartbeat when there is no request. The connection is only closed if some error occurs or one side has to be closed for some reason. Obviously either approach will work but is there a 'best practice' on how to handle something like this? –  WileECanisLatrans Dec 30 '10 at 14:26
    
The vendors approach is serial; maybe that is a feature. The one connection per request would accommodate a parallel exchange of requests/responses. Thanks again for the education. –  WileECanisLatrans Dec 30 '10 at 14:26
    
Can anyone explain why tcp ack'ed the first 3 packets separate from the 4th and 5th? –  WileECanisLatrans Dec 30 '10 at 16:16
add comment

2 Answers

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.

share|improve this answer
    
Thanks again for your response. I'm still struggling with convincing the vendor the ack value of 78345 is valid. Any suggestions on where I can get over-whelming evidence. Once you get that horse to water how do you make him drink? –  WileECanisLatrans Dec 30 '10 at 16:01
add comment

Briefly, the ACK field is used to indicate the next sequence number that a receiver expects to receive from a sender. That is, the sequence number of the last received segment + length of that segment. (There are some other uses relating to dealing with loss/retransmissions, but we'll leave those out for now).

TCP is designed so that multiple segments may be acknowledged in a single response. This allows for more efficient utilisation of high-latency links. See RFC1122 and RFC2581, in particular the sections on delayed acknowledgments.

In terms of your specific question: a TCP stack will always have some level of interleaving; that is to say, even if the final packet (seq 79785) had been placed in the receive buffer, it may not have been processed in the allowed time before an ACK had to be sent back to the other end of the connection. The headers that you've provided seem to depict a completely normal TCP conversation to me. Your vendor's explanation seems dubious at best.

share|improve this answer
    
You suggested i edit my original question to include the followups. Seems kinda wrong to change the original question. Comments only allow limited characters. And you can't enter multiple comments within 15 seconds. If your associated with the site you might suggest they make some improvements. I did delete my answer and added 3 comments so that I had enough room for my follow-up questions. –  WileECanisLatrans Dec 30 '10 at 14:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.