Wireshark mailing list archives
Re: [TCP Window Update] & bytes_in_flight
From: ronnie sahlberg <ronniesahlberg () gmail com>
Date: Tue, 2 Mar 2010 11:19:42 +1100
On Tue, Mar 2, 2010 at 10:37 AM, Martin Andersson <hello.martin () ownit nu> 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 () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- [TCP Window Update] & bytes_in_flight Martin Andersson (Mar 01)
- Re: [TCP Window Update] & bytes_in_flight ronnie sahlberg (Mar 01)
- Re: [TCP Window Update] & bytes_in_flight Martin Andersson (Mar 01)
- Re: [TCP Window Update] & bytes_in_flight ronnie sahlberg (Mar 01)