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.
On Tue, Oct 03, 2000 at 02:23:49AM -0700, Guy Harris wrote:
> On Tue, Oct 03, 2000 at 01:26:35AM -0700, acmay@xxxxxxxxxxxxxxxxxxxxxxx wrote:
> > Another thing to look at would be the timestamping of the messages. There
> > are case where I would want the timestamp of the first time the data is seen
> > on the network and other cases where I want the time of the last time it
> > is on the seen by network.
> >
> > One example of when I would want the first timestamp is with the Nagle Alg.
> > off for stream of small messages at a rate faster than standard Ack delay.
> >
> > TCP packet 1 @0.001 data bytes 0-4 : msg1
> > TCP packet 2 @0.005 data bytes 5-9 : msg2
> > TCP packet 3 @0.010 data bytes 0-14: msg1+msg2+msg3
> >
> > Now in this case I typically want the timestamp to reflect when the sender
> > thinks he is sending the data.
>
> To which timestamp are you referring?
>
> *Each* of those frames will have a timestamp, no matter how we do the
> dissection of TCP or the higher-level protocol; the timestamp is put
> there by the lowest-level dissector, the "frame" dissector.
With the example above the @0.001 etc. are the timestamp from the low level
dissector.
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.
If the info is displayed in a second window what timestamp would be used
for msg1 and msg2. There would be 2 timestamps that are valid from the
low level dissector (ie 0.001 for the first time of msg1 and 0.010 for
the second).
> > The point of all of this is really that the higher level parsers are all
> > going to have different ways to deal with the data "problems".
> >
> > So does a parser for the TCP data really buy you that much for the higher
> > level protocols, since you are going to need logic in the high level parser
> > to deal with possible problems with the TCP stream.
>
> The high-level parser needn't deal with retransmissions; making all of
> them do so would be madness. The same applies to out-of-order
> transmissions.
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. It would be nice if the interface between
the high and low level dissector was flexible enough that some simple high
levels just would look at the byte stream and other could look at more of the
details if necessary.
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.
