1

The considered application (server) has a number of clients connected. It processes each message from the client and sends two output messages. The output messages are generated sequencially and written to the socket. I observe that occassionnaly the second output message is delayed by a big time for a client. I'm trying to understand the reason for this.

Below is the filtered TCP flow between the application and the client captured from the client side.

enter image description here

  1. 14908 is the input message from client. 14910 and 15337 are the two ouput messages
  2. 14910 is not delayed. But 15337 is delayed around 40ms.
  3. As I can see, the 15337 packet is not sent until the ack 15336 is received.

The application sends a packet to TCP layer if the socket does not return EWOULDBLOCK or EAGAIN . I'm assuming the socket is not blocked because the window published in #14908 is 1424 and #15336(len=229) shouldn't send it to EWOULDBLOCK.

So can you please help me understand what causes the TCP layer from delaying the sending of #15337 until the ack for #15336?

Improve this question
5
  • 2
    The stack is simply waiting for more send data. The application needs to use the Urgent option on the TCP socket, so a send buffer is actually transmitted earlier. Commented Oct 4, 2019 at 18:19
  • @Zac67But 15337 is not out-of-band data for the application. It has same priority as 14910 Commented Oct 4, 2019 at 18:51
  • Unfortunately, the behavior of your host OS/application are off-topic here. You could try to ask this question on Server Fault for a business network, or on Stack Overflow for programming help. We could help with the network, but you have not given us a good network description or diagram, the network device models, and the network device configurations. It appears that the network is working, but you have a host problem. Commented Oct 5, 2019 at 0:20
  • Please do not cross-post on SE sites. You have asked at least twice on Server Fault and once here. Choose one site and delete the question on the others, or you may find all the questions deleted as cross-posts. Commented Oct 5, 2019 at 18:07
  • "So can you please help me understand what causes the TCP layer from delaying the sending of #15337 until the ack for #15336?" We can give you answers about TCP theory, but your particular host TCP implementation is off-topic here, so, no, we cannot help with that. You are now definitely in off-topic territory. Commented Oct 6, 2019 at 15:24

1 Answer 1

Reset to default
3

14908 is the input message from client. 14910 and 15337 are the two ouput messages.

14910 is the response to the client and clearly has the PSH flag set so was sent immediately by the server. The server then waits for the ACK from the client before sending 15337.

14910 is not delayed. But 15337 is delayed around 40ms.

This is the time it takes the ACK (15336) to transit from the client to the server, for the server to process it and for the next packet to transit from the server to the client.

As I can see, the 15337 packet is not sent until the ack 15336 is received.

Correct. This is how TCP generally operates.

So can you please help me understand what causes this delay.

You definitely do not provide enough information for us to provide you an answer with any certainty. You are also hamstringing our understanding by providing an image of a filtered capture rather than the capture.

You can note that roughly the same time difference exists between packet 15337 and packet 15756 (slightly shorter at 39.87ms vs 39.93ms). The difference in packet count between the this exchange is 419 vs the first exchange at 426.

So best guess is that this "delay" is the result of the client sending/receiving a significant amount of other traffic between the time it sends the ACK to the server and the next packet arrives from the server.

I couldn't tell you more than that as I don't have the packet capture and can't tell you what that other traffic might be. Nor can I tell you what kind of hardware the client is running or how much load the client might be under. But all of these details are getting outside the scope of this site anyhow.

Improve this answer
13
  • About your comment 'This is how TCP generally operates'.. It suggests you are saying every sent packet shoud be acked by receiver for the next packet to be transmitted. Then why do I see many times when x.48 sends 2,3 or 4 packets before x.50 acks it? Commented Oct 5, 2019 at 16:05
  • 3
    No it doesn't suggest any such thing. Note the use of the PSH flag (which I point out). This flag in effect tells TCP to immediately "send this window" of data even if it isn't actually full or time to send it. It then waits for the ACK before sending the next window. This is how TCP generally operates. Commented Oct 5, 2019 at 16:11
  • Yes. But 15337 also has the PSH flag. I really can't understand why it is not sent without waiting for the ACK. Commented Oct 5, 2019 at 16:14
  • 3
    Because it is part of the next window. Think of it this way, the next window doesn't "open" until the ACK is received. Once it "opens" and the segment is received, it is again immediately sent even though that window isn't full. If both segments should be sent together, then the application should not be setting PSH on the data in 14910. Commented Oct 5, 2019 at 16:18
  • So the summary is if we do PSH into the current window TCP will never send the next packet until the ACK for the first is received (until it is filled or time to send triggers). I didn't know that. Thanks a lot for you help. Commented Oct 5, 2019 at 16:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.