https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6683
Paul Munford <munford@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |munford@xxxxxxxxxx
--- Comment #1 from Paul Munford <munford@xxxxxxxxxx> 2012-09-14 12:39:00 PDT ---
Copy/additional viewpoint from bug 7703:
Perhaps the real answer is to have two tcp.analysis fields (choose what names
you want, just making a point):
1) tcp.analysis.highest_expected_sequence = tcp.nxtseq - [most recent] tcp.ack
2) tcp.analysis.bytes_in_flight =
[from most recent data packet] tcp.nxtseq -
[from most recent ack] tcp.ack -
tcp.options.sack_re1 - tcp.options.sack_le1
tcp.options.sack_re2 - tcp.options.sack_le2
tcp.options.sack_re3 - tcp.options.sack_le3
tcp.options.sack_re4 - tcp.options.sack_le4
where sack_re1, sack_re2, sack_re3, sack_re4 indicate the right edge of each
of the four allowed ranges in the SACK field of the Options section of the TCP
header.
In this manner, the "true" bytes in flight will only ever require knowledge of
the most recent data packet from the sender and the most recent prior ACK from
the recipient. Similarly, the packet analyzer will be able immediately
understand "bytes in flight" as well as "when the Sender should stop
transmitting as per RFC793", making analysis easier.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.