BTW, a style point - Ethereal uses the underscore_convention rather than
the InterCapConvention for function names, so the new code should
probably use underscores rather than intercaps in function names and the
like.
> > 2) get rid of the wrappers such as "XXXDissectorDelete()" and,
> > instead, have the code that registers or unregisters a
> > dissector pass in the dissector array - or pass in a protocol
> > name and use that as a key to look up a pointer to the
> > dissector array in a table.
>
> I like this idea, it is a better generalization of the concept. I favor
> using the dissector name. I just don't know how we would do that. I
> guess that part of registering a dissector would include registering it's
> name;
It does:
proto_udp = proto_register_protocol("User Datagram Protocol", "udp");
"proto_register_protocol()" could be given an additional argument that
specifies a protocol-discriminator table, or could be changed to take a
pointer to a structure that contains information such as the full
protocol name, the short name, the discriminator table, etc.. (The
discriminator table pointer would be NULL if the protocol didn't have
subprotocols, or didn't have a discriminator field.)
This would require changing all dissectors, but I'd be willing to do
that.
> I like that part. But when the dissector is registering, the
> dissector that calls it would already have to be in place. How do we
> insure that this all happens in the right order? This could be done
> by adding a comment line in the dissector file that the make-reg-dotc
> script would have to look at. The comment line would specify what
> other dissectors have to be in place before this dissector is
> registered.
The same issue shows up with the discriminator tables we already have,
as per Andreas Sikkema's mail; my response discusses some possible
solutions.
> Then the make-reg-dotc would have to figure out what order to register
> the dissectors. Of course make-reg-dotc would have to handle any loop
> problems, I think that this would be an error condition and could be
> announce and the make process killed.
I'm not sure a cycle in the protocol graph would be an error; my
response, alluded to above, discusses this (IP-in-IP tunneling, for
example).
> >Note that we shouldn't assume that the lower-numbered port is the port
> >number for the service - I put the "PORT_IS()" macros into
> >"packet-udp.c" and "packet-tcp.c" because I had a trace in which the
> >client really *did* use a lower port number than the server, and using
> >the lower-numbered port number as the service's port caused the trace
> >not to be dissected correctly.
> >
>
> Interesting. How do you suggest we generate the hash key ? Since some
> of the TCP ports are above 1024; I suspect using the highest port would
> select the wrong dissector.
I suggest we do as the "PORT_IS()" macro does, and try *both* ports. We
could try the lower-numbered port first, but, if that fails, we don't
quit, we try the other port as well.
