0

enter image description here

I am sending packets of known length from client (63396) to server (50001)

frameTime 1659456858651175 frameSeq: 0 Packets 1 bytes 23425
frameTime 1659456858667639 frameSeq: 1 Packets 1 bytes 19556
frameTime 1659456858683377 frameSeq: 2 Packets 1 bytes 24036
frameTime 1659456858698961 frameSeq: 3 Packets 1 bytes 19174
frameTime 1659456858716629 frameSeq: 4 Packets 1 bytes 21337
frameTime 1659456858731652 frameSeq: 5 Packets 1 bytes 16714
frameTime 1659456858748493 frameSeq: 6 Packets 1 bytes 23054
.
.
.

If you look at the wireshark dumps [PSH,ACK] Len shows the corresponding correct packet size (bytes). However on line 9, client sends an ACK piggy-bagged with extra data. It misses an ACK from the server. Any specific reason behind this weird response. How to know the exact reason for this delay?

Improve this question
4
  • I'm not sure if I understand your question. There is no need for the recipient to acknowledge everything immediately. And the sender can send more data even if there are not yet acknowledged data as long as the current window allows it (which is true in this case). Where the delay comes from - who knows, maybe from inside the server program, from the OS scheduler ... Commented Aug 2, 2022 at 18:11
  • Is there any way to find out what causes this issue exactly, as it is happening just once in my tests where I am sending 1000s of frames repeatedly. If it has been an OS or server related issue I was hoping to see some random nature regarding this miss ACKs Commented Aug 2, 2022 at 18:21
  • Setting TCP window scaling to 0, solved the issue. Commented Aug 2, 2022 at 21:07
  • If you have solved your problem, please post an answer detailing the solution instead of editing the question Commented Aug 3, 2022 at 1:31

0

Reset to default

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.