> struct hash_struct {
>
> uint32 src_ip; /* Excuse the non-portability */
> uint32 dst_ip;
You might want to make those arrays plus lengths, to handle other
protocols, such as IPv6.
You'd also have to deal with NetBIOS-atop-non-IP protocols.
Note that the network-layer and transport-layer information that SMB
(and ONC RPC) would need is stuff that lower-level protocols might
register as stuff to be shown in the summary display, i.e. the source
and destination address (IPv4 or IPv6 for NetBIOS-over-TCP or
CIFS-atop-TCP; IPX for the various NetBIOS-over-IPX encapsulations; MAC
addresses for NBF; whatever the network-layer protocol would be for the
MAP/TOP NetBIOS-atop-OSI), and port number for TCP or UDP (link-layer
SAPs for NBF? Some transport-layer stuff for NetBIOS-over-IPX or
NetBIOS-over-OSI?).
I've been looking at better ways of registering those - "better" meaning
"involving as little string copying, etc. as possible" - for
performance reasons; perhaps we could do somethng that lets dissectors
just say "the source address starts at offset X, is Y bytes long, and is
of type Z" rather than copying text into a buffer - the code that sets
up the columns in the summary display would then generate the
human-readable form (thus keeping, say, the link-layer dissector from
generating a human-readable MAC address *and* the IP dissector from
generating a human-readable IP address atop it, if the summary doesn't
explicitly ask for a link-layer address - that avoids one CPU-consuming
step).
(In addition, once we generate a human-readable address, we might want
to store it in the "resolv.c" database, along with any name we found for
it, so that we don't have to do repeated "sprintf()"s or "snprintf()"s
for the *same* address.)
