[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>
> Hi Joey,
>
> Joey Salazar wrote:
>
> > Very happy to be joining for this winter's internship! A short blog
> > entry on the beginning of this journey here: https://jsal.home.blog/
> >
> > A new entry every 2 weeks, check it out!
> >
> > Thank you Outreachy, Git, and Wireshark for the opportunity, happy
> > to be working together!
>
> Welcome!  I'm looking forward to working together (starting with an
> initial wireshark patch to get the lay of the land, then fleshing out
> the plan for the project, then executing on it in earnest).
>
> A question for wireshark developers: are there preferences for what a
> high quality dissector looks like?  [1] talks about portability and
> robustness but doesn't address other aspects of convention such as how
> long functions should be (like [2] does).  Is there a rule of thumb
> like "when in doubt, do things the way <such-and-such dissector>
> does?"

Only speaking for myself. This one is tricky.
Most dissectors I think follows [1] and [2] pretty closely, with the
exception that I don;t think
there is any concern about lengths of a function. For a lot of
protocols you may end up with
switch statements with hundreds of cases and then that is just how it
is. Or similar.

Now, this is not uniform across all dissectors. Wireshark has grown
organically over more than two decades
and styles and preferences, which at the end of the day are dictated
by the developers, change.

So do not be surprised to find some dissectors that are very different
in style. In some cases it might
just be that the dissector is very old and also for an obscure
protocol that almost no one cares about.
Sometimes it is that simple.

I would see [1] and [2] as good guidelines but not absolute law. Then
also when in doubt look at how are things done
in popular protocols where there are many developers involved and
where the dissector is well maintained.
For example  packet-smb2.c  is pretty modern and has a fair amount of
crunch to keep up with the evolving standard.

Modern and popular(i.e. people care about them) dissectors also are
much more likely to contain useful examples of more advanced features
such as
* ExpertInfo,
* Preferences,
* Reassembly,
* lots of Generated items (things that are not part of the packet
itself but still useful to show when wireshark deducts it),
* state tracking such as keeping track on Request and Response
matching and response times.
etc etc etc.

This makes the dissectors more daunting to look at since there are so
many different concepts there ontop of just "show what the bits and
bytes mean" but at the same time they show these extra things that we
usually have in a good/popular/mature dissector.


But at the end of the day, for every protocol, what makes a good
dissector is what an experienced engineer would need to do his/her
job.
I think that means that it takes a lot of subject-matter-expert
knowledge to know what is useful and what is not and here you probably
have as good or probably better input on what the dissection features should be.

Hypothetical example: say if wireshark had a feature where it would
reassemble objects and store them under their hash somewhere
and it allowed you to right-click on a sha1 in the dissection pane and
then "export object as file". Would that be useful?
You would know if it would be useful for git developers and engineers.
I have no idea.

ronnie

>
> Excited,
> Jonathan
>
> [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer
> [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe