per Guy Harris -
> On Mon, Oct 02, 2000 at 09:44:23AM -0500, Jeff Foster wrote:
> > I suggest that we change the tcp and tcp sub-dissectors from the current
> > 'data push' where the tcp dissector passes the packet data to the
> > sub-dissector to a 'data pull' system where the sub-dissector requests
> > data from the tcp dissector.
>
> What's the advantage of doing it that way? It looks as if the only
> difference would be whether the sub-dissector or the TCP dissector
> maintained state information and kept as-yet-unprocessed TCP segments.
>
> The former could be done in the sub-dissector as well.
The basic idea is that the TCP dissector will assume the role of ordering
and buffering data. Each sub-dissector field decode/display routine would
request the amount of data needed to complete it's task. If the data is
available the sub-dissector does the decode for that field, tells the tcp
dissector it doesn't need that data any more, and moves on to decode the
next field. This continues until the data stream is empty. Then the sub-
dissector decode routine receives a 'data not available' reply.
This keep all the data stream housekeeping in the tcp dissector and turns
the sub-dissector into a set of small routines required to decode each
field in the protocol. If you combine this with the "gtk/ethclist.c" work
that you are doing Guy, we are making steps toward separating data decode
from data display (I think Richard wanted that).
Jeff Foster
jfoste@xxxxxxxxxxxx