On Tue, Mar 2, 2010 at 10:37 AM, Martin Andersson <hello.martin@xxxxxxxx> wrote:
> Hello
>
> I have two questions.
>
> 1.
> What defies an [TCP Window Update]
> By looking at a trace, do I understand this correctly that wireshark mark a
> packet as Window Update when it receives a "duplicated ACK" when the window
> size has changed as well.
A window update is an ACK packet that does not ACK any more additional
data, but only expands the window.
The window is often opened like this when an application reads data
that has been sitting in a buffer and could indiocate
an application that does not keep up with the rate of received data.
Something like this
S->C 10 bytes of data
C->S ACK for this data and "shrinks the window" by 10 bytes. Data is
written to the TCP RX buffer
time passes
data is still stored inside the RX buffer
C->S the application finally reads these 10 bytes from the socket
ACK is sent with the same ack number but the window has "grown" by 10
bytes again.
So, often Window updates occur if there is a long delay between when
TCP receives data and stores it in its RX buffer and until the
application is acrually reading this data from the socket.
>
> 2.
> What does "Number of bytes in flight" means. By the wording I get the
> impression it should represent number of bytes "sent" which has not been
> acknowledged yet. If so will the tcpgraph then be close to the windowsize (i.e
> the upper gray line) if bytes_in_flight is close to advertised window size.
Yes.
> Also can bytes_in_flight > Window size (at least it seems so in my trace).
No, not unless the TCP implementation is broken, or unless there is
WindowScaling used and you didnt capture the initial SYN pacekts.
Note that "window scaling" may be in use, in which case the numberic
value of the window as reported in the packet needs to be multiplied
by a multiplier to get the true window value.
This is negotiated in the initial SYN packets, so you need to have
the initial SYN packets in the trace in order to know if you can trust
the window value or not.
>
> brg/Martin
>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>