Hi,
I think you should structure it the way that makes most sense and is most
useful
for a professional working with that protocol.
Therefore I would assume you would know which way is best much better than,
say, myself which does not
even know which protocol it is.
If uncertain, ask the people that work in depth with that protocol which way
they thinks makes most sense
and would be most useful for them.
Perhaps they say that certain layers are much more important and interesting
than others and perhaps
those layers should be where to create a new branch, so that the important
layers are close to the user and not
hidden several levels deep in the tree .
best regards
ronnie sahlberg
----- Original Message -----
From: "Duncan Thomson"
Sent: Tuesday, May 28, 2002 11:19 PM
Subject: [Ethereal-dev] Sub Dissectors - should I make them protocols?
> I've got a highly structures application level protocol that runs on top
of TCP
> or UDP. By "highly structured" I mean that it has multiple layers. For
> example, there's a top-level Header Type field that says which of various
forms
> of header I've got. Each different type of header has a different
structure,
> but all contain a Message Type field that says what type of message
follows the
> header. There are lots of different types of message, each with it's own
> structure. For example, there's a Management Message. Again, the
Management
> Message has a header that contains a "Management Message Type" field that
says
> what kind of management message it is. And so on...
>
> My question is: to what extent should I register the different layers as
> "protocols" versus just adding them as branches in the protocol tree.
>
> README.developer states:
>
> "Some dissectors will need to create branches within their tree to help
organize
> header fields. These branches should be registered as header fields. Only
true
> protocols should be registered as protocols. This is so that a display
filter
> user interface knows how to distinguish protocols from fields."
>
> I don't find this very helpful. What, exactly, is the definition of a
"true"
> protocol? As far as the display filter interface goes, it seems better to
> register the different layers as actual protocols. It also just seems
much more
> modular to break out the different layers as separate protocols. That
way, for
> example, my Management Message code can be isolated from my Data Message
code.
>
> But before I dive into doing it this way, I'd like to have a better
> understanding of the implications. What are the pros and cons?
>
> Any suggestions?
>
> Thanks,
>
> Duncan Thomson
> The MITRE Corporation
>
> p.s. It seems that README.developer is getting out of synchronization with
the
> code. Luckily there are plenty of examples to work from. If I can get a
good
> enough understanding of this area, I'll try to write it down and
contribute some
> updates to README.developer.
>
