Protocols vs dissectors, take 23

[Michael Mann <mmann78 () netscape net>]

I really like the flexibility and power that the current dissector table API provides.  The one small shortcoming is 
that a "protocol" needs to be provided when adding a dissection function to a dissector table.  And not all dissection 
functions are a protocol.  The "protocol" API is intentionally separate from the dissector function API because there 
isn't always a 1-1 relationship. This can lead to the creation of "dummy" protocols, or "pinos" (Protocols in name 
only) as I've decided to call them (modeled after [1]).  To me, pinos don't have the same capabilities as real 
protocols.  They don't have hf_ fields or heuristic dissection functions associated with them.  They cannot be 
enabled/disabled.  They are there strictly to satisfy the dissector table API and Decode As functionality by extension 
(names for dissection functions).
 
A good example of where pinos should be used is creating a dissector table for TCP options.   Each option could be its 
own dissection function and the dissector table architecture also allows for options to be implemented outside of the 
TCP dissector file (for things like Lua scripts for experimental or proprietary options). However, it's all under the 
umbrella of the TCP protocol. So if each TCP option is treated as a real protocol, the Enable/Disable dialog (or 
anything else that needs to list all protocols) gets needlessly populated with "protocols" that aren't real.
 
An example of where pinos are questionable is where there are different versions of a protocol, especially when they 
are separate dissector files.  (i.e. Openflow).  Would a user want to enable/disable certain versions of OpenFlow?  I 
don't know, but I guess to be on the safe side, I would say "yes", but that then leads to multiple entries for a single 
"protocol".  I also like "self contained" dissector files and sharing a protocol ID across files so hf_ fields can be 
registered under the same protocol ID can be dangerous based on how the register-cache.pkl works.
 
Another example of where pinos are questionable are "object oriented protocols".  Dissector tables are set up to key 
off of an "object ID", and that turns into a protocol ID (that typically has it's own hf_ fields for the data within 
that object).  It varies per protocol, but I would guess most of protocols don't need enable/disable and the protocol 
IDs created for the objects are just for the dissector table itself and to modularize the hf_ fields and/or dissection 
functionality across files.
 
The last example I have is one of the reasons for writing this email in the first place - Bluetooth.  I know nothing of 
how the Bluetooth protocol works or is architected, I just know it has over 400 entries in the protocol list, which is 
over 20% of the total list. That's a lot of real estate to take up for the many users that don't use Wireshark for 
Bluetooth.  It looked simple enough to remove most of those entries from the Enabled Protocol dialog by turning them 
into pinos with a few lines of code (https://code.wireshark.org/review/19482).   However it was met with resistance 
from people more familiar with Bluetooth (they felt enable/disable is warranted).
 
So I'm back to asking for ways to better categorize these situations.  How much of it is "GUI presentation" and how 
much of its "underlying architecture"?  As developers we can be lazy and have GUI just mirror the underlying 
architecture, which is not always advantageous to the user.  I don't think we want to expose every dissection function 
with its own name to the user, at least on "main" dialogs.  If we create more "Advanced" dialogs that seems more 
acceptable, but I also don't want GUI code to be that knowledgeable about dissectors (nothing like "if Bluetooth - 
create separate dialog", or even "if protocol has more than 10 children, create separate dialog").  However, what I'm 
interested in working on is the underlying architecture.   I can work on writing/implementing rules categories (so GUI 
could follow), but I'm still at a loss as to what those categories would be. So far I have
 
1. Real protocols
2. 'tweeners.  Things like protocols with multiple versions, object oriented protocols.  Should there be a parent/child 
relationship with a "real" protocol?
3. heuristic functions.  Should they really have a parent/child relationship with real protocols like is presented in 
the GUI?  Historically they have had their own category which I think ranks them above pinos.
4. pinos
 
I'm open to discussing what the rules of pinos should be, but I intentionally started with the most strict (name only). 
 If pinos support hf_ fields or heuristic functions should they be called something else that would be considered 
"better" hierarchically than a pino?  I would also like APIs to be more implicit and relationships handled "under the 
covers" and not have something like proto_set_type(enum proto_category) function.
 
Parent/child relationships in the underlying architecture lend themselves well to subtrees in the GUI.  This is a case 
where I don't have better suggestions, but it does feel like that's the lazy developer option.  It's also where sheer 
volume (for things like Bluetooth) really cause it to break down.  The search functionality does mitigate it some, I'm 
just not sure it's enough.  Does having "real protocols" as the root node of a tree for all other categories make sense?

Ideas/opinions welcome.

Michael
 
P.S. I'm not trying to pick on Openflow or any other protocol example I give in the email.  They are just examples of 
problems to be solved or questions that need to be asked when new dissectors come in for review.
 
 
[1] https://en.wikipedia.org/wiki/Republican_In_Name_Only

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe