Ethereal-dev: Re: [ethereal-dev] TCP and higher level dissectors (sub-dissector s)
> First thing that I am not sure on is the display of the data.
> The last time I checked there was a follow TCP stream option
> that would generate another window with the data.
>
> Will the high level parser just display in the original caputer
> window along with any of the other fields you select to view or
> will there be a separate window like the follow TCP.
The high-level parser, like all parsers, doesn't display anything, it
just builds protocol trees and constructs the "Info" field.
If you are getting a view in which the packet list shows frames rather
than higher-level messages, the protocol trees for individual frames
will be shown.
If you are getting a few in which the packet list shows higher-level
messages, the protocol trees for individual messages will be shown.
> If the info is displayed in the original capture window the timestamp will
> already be there, but will there be any marks to show that msg1 & msg2
> were retransmissions.
Yes. TCP would put items into the protocol tree to indicate that bytes
0-4 of the third frame are a retransmission of data from the first
frame, and that bytes 5-9 of the third frame are a retransmission of
data from the second frame.
> I agree that it would be hard to have them deal with all the possible
> problems, but I can think of times that the high level would want to
> deal with looking at the details from the lower level.
So what are those times, and what details are those? Details such as
connection startup and termination, and the urgent pointer, are
definitely useful - but those are the sort of details that, in a
networking stack, are exposed to code running atop TCP. The question is
whether details such as retransmissions and out-of-order transmissions
are useful; nobody's yet indicated why a higher-level dissector would
ever need to know about them.
> As long as you need to deal with holes in the data I doubt a simple byte
> stream interface between the levels would be enough.
Yes, but there's a difference between something sufficient to handle
holes and something sufficient to handle out-of-order packets and
retransmissions; there's also a difference in the amount of code
that would be necessary in *every single dissector above TCP* to handle
holes and that would be necessary to handle out-of-order packets and
retransmissions.
