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.
