As Guy Harris said:
>
> Yes. I can imagine several flavors of UI that people might want for the
> Ethereal dissecting core (GTK, Qt, etc.; "curses"; a
> "tcpdump"/"snoop"-like version - is that what "tethereal" is?), and if I
> end up having the dissectors generate some data structure, like the
> property lists, that isn't a GTK tree, it's useful for that, too.
The re-writing of packet-ncp.c that I checked in last night is somewhat
related to your data structure idea. NCP request/replies, like NFS, only
identify the type of call in the request packet. When it comes times to
decode the reply packet, ethereal needs to remember what type of call the
NCP request was. But ethereal has no general way of recording data in this
way --- that's part of the problem you want to fix.
For NCP I created a local GHashTable object and when I decode NCP requests,
I store away the type. The key uniquely identifies the NCP request/reply
conversation: NetWare Server address + Client ID + Sequence Number (of the
packet in the conversation).
Similarly, packet-udp.c contains some custom hash routines for doing
somthing related. Perhaps these routines could be chaned to use GHashTable,
since we're already linking against glib anyway, why not use the hash
routine in glib?
--gilbert
--
Gilbert Ramirez Voice: +1 210 358 4032
Technical Services Fax: +1 210 358 1122
University Health System San Antonio, Texas, USA
