Ethereal-dev: Re: [ethereal-dev] TCP and higher level dissectors (sub-dissector s)
I have not started looking at the ethereal code and I don't even have
the source on my machine to check for some things but this along the lines
of what I really want to see in ethereal.
I have been dealing with a lot of military type specs with a simple
len / msg id / data / chk sum format. The system is also intended to
be "real-time" but that will never really happen with TCP, but the
people that did the specs don't seem to care about that.
There are plenty of other reasons why this is a bad setup but there
is nothing that can be done about that.
So here are some of the things I have noticed when looking at the data
by hand.
In this setup it is pretty easy for a parser to recover from missing
data or a bad length field by looking for the first packet after a packet
that is less than the max size. This is because the system does not send
data at rate anywhere near the max rate of the network and the socket
write calls are usually done with a complete message.
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.
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.
I would think that the TCP parser could be helpful but I would like the high
level parser to have enough info to make decision on what to do with holes and
retransmissions.
I am not sure how I would layout a structure to pass this info but it
would need a list of pointers to the original packets captured and pointers
to the data stream.
--
Andrew May
amay@xxxxxxxxxxxxxxxxxxxxxxx
