Guy Harris wrote:
> > I had gone into the conversations code, and added an extra integer
> > field (which would default to 0 when not supplied).
>
> Added it to the conversation_t structure?
Yes.
> > The idea was to
> > have taps use a different number for that field, so that a tap could
> > maintain it's own conversation data without stepping on the protocol
> > dissector or other taps (especially the same tap with possibly different
> > display filters...).
>
> So how would that number be used for that purpose?
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.
> 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, there would be no
conflicts, and the normal function calls would work fine.
I like your suggestion. Looking at the code again it seems like the
proper way to add tap conversation support. I don't remember that
particular strategy coming up in past discussion. Maybe that's what I
get for trying to make modifications without having used a conversation
before :)
(One small thing to keep in mind if somebody does go and implement this,
the tap listeners must grab their ID's in init instead of register...
Otherwise overlapping filters would cause trouble.)
> > 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...
