On Mon, Apr 21, 2003 at 07:15:57PM -0400, Jason House wrote:
> If you have a single conversation, then the data associated with the
> conversation must then become some kind of linked list (or other data
> structure) that holds different blocks of conversation data.
Well, that's what it is *now* - there's a list of data items tagged by
protocol ID. My suggestion replaces "protocol ID" with "ID", and lets
non-protocols get ID numbers.
> > Another way to do that would be to change the
> > "conversation_XXX_proto_data" routines to
> > "conversation_XXX_private_data", and have the "proto" argument become an
> > ID argument, and have a mechanism by which modules other than protocols
> > can request an ID number; those numbers would come from the same number
> > space as the one for protocols and registered fields.
>
>
> I don't see why you'd even need to differentiate between
> conversation_XXX_proto_data and conversation_XXX_private_data if the
> proto field comes from the same number space,
I'm not differentiating - "change the 'conversation_XXX_proto_data'
routines to 'conversation_XXX_private_data'" means "rename the
routines", to indicate that they aren't just for adding protocol data.
> > > The next step was to pull the tcp sequence number analysis out of the
> > > tcp dissector and have it use its own conversation instead of TCP's
> > > conversation.
> >
> > With the scheme I suggested, they could use the same conversation.
>
> Technically, you're right, but...
>
> TCP sequence number analysis and its associated dissector should not
> share the same physically allocated data structure (like any well
> behaved conversation based tap). Because of the separation of
> underlying data structures, there will be some effort required in
> separating access to the data structures. This also includes
> replication of the code to add allocate the new "sequence number
> analysis only" data structure for each conversation...
Yes, but what does that have to do with allocating different
conversations? You keep the data structures separate by allocating them
independently and using different ID numbers when attaching them or
fetching them with the "conversation_XXX_private_data" routines.
