Guy Harris wrote:
>
> For various reasons, I've been thinking that it'd be useful to be able
> to register protocols as more than just fields for the top-level
> protocol-tree item for that protocol; I'd see protocols as having
I agree.
> a short name, to put in the "Protocol" column and in the tab for
> the "Preferences" dialog (and perhaps elsewhere);
which should be unique and could be used as a key for protocol searching.
> a long name, to put in the top-level protocol tree item;
and elsewhere (manual pages, help, tool tips etc.)
> a filter name, used in filters to refer to the protocol;
The filter name should be the short name for simplicity (like now) but
you might have a good reason ?
> a dissector function;
Which could be directly called for instance to decode the undecoded data
portion of a packet (i.e. assign a particular dissector to "Data" thanks
to the GUI and a protocol tree popup menu item ...)
> a list of preferences;
>
> and perhaps other items as well (e.g., a "medium length" name to set
> "pinfo->current_proto" to, unless we decide that it'll always be the
> "short name" or "long name").
I'd prefer to have only two names ...
> We might also have a "hand off to this particular protocol" routine - or
> routines, one taking old-style arguments and one taking tvbuffified
> arguments - taking a handle on a specific protocol as an argument, which
> would do that stuff and then call the protocol's dissector; they could
> be used by the routines that look up dissectors by port and that call
> heuristic dissectors. (This would perhaps require that all dissectors
> return a gboolean rather than void, so that all dissectors have the same
> function signature.)
Yes.
> It might also be useful to have each registered protocol have a
> "enabled/disabled" flag
This would be simply another item (among others) in the protocol
characteristics database.
Almost all this stuff could be done by extending the current proto.c
implementation. The proto_register_protocol could have some other
parameters (like pointer to dissector function among other things,
it could be simply a protocol characteristics structure) and then
the protocol characteristics could be stored in a hash table (or
a sorted list (key is protocol short name)) instead of the current
header_field_info structure. This would allow to easily extend the
protocol characteristics and to perform some quick protocol lookups
(among other things).
Laurent.
PS: I would like to have a stable 0.8.12 release (which is almost the
case), so it would be nice to initiate some _major_ changes after
that ... ;-) but the proto.c changes might not be so major after
all ? :-)
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | laurent.deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
