This is a static archive of our old Q&A Site. Please post any new questions and answers at

Should I handle very detailed subdissectors internally or externally with dissector table


Hi, forks, this is a best practice question. I am decoding a protocol set on top of UDP. The UDP payload is encapsulated in MotherProto, and the payload of MotherProto takes on several dozens of forms.

Each form represents a different message type, and is identified with UDP port number. For example,

udp port 64000 means A01 message, in which byte 1 is status, byte 2 is data_freshness, byte 3-4 is measurement_1
udp port 64001 means B02 message, in which byte 1 is status, byte 2 is data_freshness, byte 3 is command_1, byte 4-5 is command_2


There are two ways to handle this as I see it. One way is to set up a sub_dissector table "mothеr.port", and register each tiny little message type as a sub-dissector

Or, I can make call a unique subdissector in MotherProto, Childproto, and handle the message classification internally. One good thing about this is that I don't need to write so many handoff routines and I can put port-to-messageType information in a xml, which is easy to maintain and update (the correlation between port and message type may change between different releases).

Which is the best practice? Or is there a better/standard way? Mother and Child proto are both niche protocols unlikely to be encapsulated in any other way.

Thank you for your help!

asked 18 Jul '17, 20:09

nickzhang's gravatar image

accept rate: 0%

edited 18 Jul '17, 21:53

sindy's gravatar image


One Answer:


So basically the question is maintainability, which is an important metric to consider. But also one of the tougher to grasp, because of the amount of uncertainty of future developments. So, both mechanisms you described are in place to handle either situation. Whichever is best, that is something for you to determine.

answered 18 Jul '17, 23:04

Jaap's gravatar image

Jaap ♦
accept rate: 14%