This is our old Q&A Site. Please post any new questions and answers at

I am tracing wireshark and matching tcp packets in order to calculate the delays occuring, i can match a data packet and it's acknowlegment, but my problem is, when i have an ack packet with window size two for example, i receive this ack at the sender side and comes right after it 2 data packets sent from the sender side, but this ack and it's stream of data at the RECIEVER side are my problem, i have this ack packet as source and i receive the stream of two packets sometime in the future and they might overlap with other packets do i match this ack and 1 and this ack and 2 at the receiver ??

sender receiver

ack windowSize=2






next ack


asked 30 Jun '15, 02:14

yas1234's gravatar image

accept rate: 0%

Hm, I'm confused about what you are asking here
The headline goes : matching ack packet and the next stream of data
So one could guess that you want to see the next incoming data for the same tcp session after an ACK was sent.

Your 'picture' suggests that the ACKs would be flowing controlled by the window_size - which it is not!

sender                       receiver
    <------------------------ (0) ack windowSize=2 "This ack"
(1) ------------------------>
(2) ------------------------>
     <----------------------- (3) "next ack"

"how do i match this ack and 1 and this ack and 2 at the receiver ??"
"this ack (0) and (1) " is easy as the tcp.ack number at the receiver is the next expected tcp.seq number from the sender (1).
"this ack (0) ... and (2) " is not so trivial as (2)'s sequence number is dependent of the tcp.len of (1): tcp.seq plus tcp.len - wireshark does the math for you in field tcp.nxtseq
I don't know how you can predict this information by looking at segment (0). My suggestion is to add following fields to the column list
alt text

Than you can see in the packet list which segments are 'ack-ed' - even the frame number

alt text

permanent link

answered 30 Jun '15, 07:08

mrEEde's gravatar image

accept rate: 20%

you do get my question but i do not understand this "your 'picture' suggests that the ACKs would be flowing controlled by the window_size - which it is not! " do u mean that after a stream of packets i get one ACK only for that stream 'collective ack' and thus the number of acks is not equal to the window size ?

(01 Jul '15, 03:00) yas1234

Typically a receiver acknowledges 'every other segment', that is
for every 2 received segment you see 1 outgoing ACK acknowledging both segments.

If there is only one segment left to be sent (= the receiver will only see a single segment coming in) you will/should see a 'delayed' ACK aknowledging the only left segment. Window_size is used for TCP Flow Control and is a different topic...

(01 Jul '15, 05:39) mrEEde
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 30 Jun '15, 02:14

question was seen: 2,190 times

last updated: 01 Jul '15, 05:39

p​o​w​e​r​e​d by O​S​Q​A