>> I have worked up the attached code as a lookup routine for the TCP and
UPD
>> port based dissectors. Please review it and make comments.
>
>It looks as if it could be the promised generalization of the UDP
>hashing routines in "packet-udp.c".
>
>Given that, I would be tempted to
>
> 1) have the "port" field be 32 bits (to handle protocols where
> there's a discriminator larger than 16 bits);
Sound like a good idea.
>
> 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; 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.
For example, in the packet-dns.c file -
/* :requires: udp
*/
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.
>
>Could, and should, the GLib hash table routines be used here, instead of
>doing the hashing ourselves?
One of the ideas behind this concept was to allow registering a second
protocol for the same port. I don't know if this would really happen;
it was intended to allow the user better control. The example of ssh
and telnet is the only one that comes to mind. What would the glib
hash stuff do if this happens ? And how would we revert to the original
dissector if the second dissector was un-installed ? I suspect that the
glib hash routines would have problems.
Do we care ?
>
>> DissectorType *FindTcpDissector( guint16 Port1, guint16 Port2) {
>>
>> DissectorType *Tmp;
>>
>> if ( Port1 <= Port2) {
>
>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.
