sahlberg@xxxxxxxxxxxx said:
> By popular request,
> make ethereal be able to measure the time it took to transfer a PDU atop
> TCP.
>
> This is great for analyzing performance issues caused by network/frame
> loss/congestion.
>
> See http://wiki.ethereal.com/TcpPduTime
"This field is inserted in the TCP protocol layer for the segment where
the PDU starts. Since it is based of information in packets received
further down in the capture file, this field will not be shown in the
protocol tree until you have refiltered the capture file at least once. It
will not show up during the initial load and dissection of the capture
file. In the same way, coloring rules that use this field will not take
effect until after you have redissected the capture at least once.
Tethereal can not use this field at all at this time."
Perhaps it should be put into the segment where the PDU ends, as well,
which would
1) make it work with Tethereal
and
2) make it show up in the initial load and dissection
or put in another entry marked as "Time since the first segment of this PDU".
(Or perhaps it should be "Time since the first segment of the PDU that
ends in this segment", as the last segment could have additional PDUs in
it, or the beginning of a subsequent PDU. A similar description change
might make sense for the item for the first segment of the PDU.)
Other frame loss/congestion issues might be detected by detecting
retransmissions; some protocols do that (e.g., ONC RPC - does the DCE RPC
dissector do that for connectionless transports? - but perhaps other
dissectors could do that for transaction-oriented protocols with
transaction IDs in them.