From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Friday, January 26, 2001 1:21 PM
> > > Is it possible to have two dissectors for one
> > > conversation (maybe using conversation.old_d,
> > > conversation.new_d)?
> >
> > Maybe. It depends upon what you are using for the 'port'
> > value. The word port is not a very good one because you
> > can use any 32 bit integer here.
>
> Perhaps we should replace it with "selector"?
Yes, something like that. I don't know what is best and since
I picked the word 'port', I defer to greater minds.
> If your conversation are
> based upon TCP ports, as I suspect, you have a problem.
>
> Perhaps conversations should, instead of having a single dissector
> attached to them, have a list of dissectors attached to them, with
> protocol IDs for the protocol that's supposed to hand off to that
> dissector, especially given your suggestion that, when a port is
> matched, at least for TCP and UDP, the conversation have the appropriate
> dissector attached to it, as that'll increase the chances that a given
> conversation already has a dissector attached to it to be called by the
> TCP or UDP dissector.
>
How do we know the protocol ID of the dissector doing the handoff?
Can we check to see what protocol is calling the current protocol?
The dissector that is creating the conversation and setting the
dissector is the 'child' of the dissector that will do the lookup.
So it can't set the dissector based upon it's protocol id it needs
to get the 'parent' protocol id.
>
> Perhaps the same should be done for the data pointer as well.
This can be done and should be done. The dissector that is adding
the data would access the data pointer by call a function with the
conversation pointer and it's protocol id. I expect that we could use
a linked list to hold the actual data pointers because it shouldn't
be long enough to cause a performance hit.
An additional note:
The conversation_new code will have to check for a previous
conversation and just add to it instead of creating it. We should
keep a reference counter so we know that a conversation has multiple
uses. I say this because if a conversation changes from a 'wildcard'
(NO_DST_PORT and/or NO_DST_ADDR) with the
conversation_set_[port|address] it must be duplicated when there are
multiple dissectors using it.
Jeff Foster
jfoste@xxxxxxxxxxxx
