Thank you for pointing to something which is similar to my purpose. It looks like WSGD registers exactly one protocol and one dissector per WSDG file.

So lets think about alternative 3: Register one fixed protocol as a placeholder where the use can configure preferences for protobuf. I will check whether dynamic registration and deregistration of protocols is possible or the user has to restart wireshark after altering the list of protobuf message types.

Most protocols have either a fixed (iana assigned) port number or one particular TCP OR UDP port number can be configured in the protocols preferences.

In the case of Google Protocol Buffers I don't like the scheme because ... ... protocol buffers are not a protocol itself, so they have no standard port numbers. ... protobuf messages may be sent via TCP, UDP or something completely different (e.g. HDLC or raw ethernet frames). ... I don't see a way to let the user configure this various possibilities via the protocols preferences page

I would prefer when exclusively the "Decode As..." dialog can used to select protobuf as the dissector for data using a particular transport. Unfortunately it seems that I'll have to call dissector_add_for_decode_as() for each dissector table individually.

In case my dissector is called this way, pinfo->match_uint may contain something like the port or protocol number, but this is not useful for me because if don't let the user configure the port number via the protocol preferences page, I also don't have any relation between pinfo->match_uint and the assigned protobuf message type (did anybody understand my problem?).

Conclusion: I think that alternative 2 is not an ideal option. If multiple dissectors per protocol are not possible, I will have to register multiple protocols.

It's true that protocol buffers aren't a protocol themselves but generally people are implementing a protocol using protocol buffers (i.e., they make a protocol with N message types whose formatting happens to be the protocol buffers format). When they are implementing a protocol they often (in my experience) do things like choose a transport and a (probably not IANA registered) port. IOW I don't think just knowing the port number will tell you the message type. But it could tell you what group of message types the message will be from.

If your dissector had a configuration file or UAT which allowed the user to specify the name of the protocol, the transport, the "port" (or equivalent), and the path to the proto file then you could establish a (dynamically configured) dissector for that protocol(**). If the port wasn't specified (or was 0) then the "protocol" would only be available via Decode-As.

(**) Actually I think I'm starting to remember that the .proto file doesn't give you enough information. You need the "compiled" output to match the names to the numbers. Or something like that...

Perhaps I think too complicated, but how can I let the user choose a transport via UAT? Do I have to use UAT_VS_DEF() and code my own enum with transports which I think may be suitable for protobuf together with an additional uint field?

Option 1: Offer a list of transports I personally use for protobuf --> Users who use another transport than me, will have to change the code.

Option 2: Make protobuf available for ALL transports. No idea how to do this. In order to be available in "Decode As...", I would have to call dissector_add_for_decode_as() for ALL dissector tables. Not sure whether this makes sense.

Both options depend on that my preferred/all dissector tables use an uint for matching the higher layer protocol.

Decoding protobuf itself (by giving a textual proto file) is already solved in the original protobuf-runtime implementation. The protobuf definition is "compiled" on the fly inside wireshark and dissection is done by a protobuf feature called "reflection".

So as an example if you "told" the Tcp dissector to decode port x as protocol buffer and had a preference in the protocol buffer dissector to decode to port x as protocol type Y and loaded the protocol description for that port. That would work? In that case use a unit dissector table in the protocol buffer dissector per transport type and dynamically register a dissector with the Def there.

I'm not too familiar with UATs but I would think there would be a way to do it with an enum.

Personally I don't think it's realistic to support ALL transports. Maybe there is a way to do it gracefully but I think trying to register for all dissector tables isn't very nice.

You'll probably cover 99% of use cases by doing TCP and UDP and another 0.9% by adding SCTP. And anyway it's Open Source software: if someone actually wants to run protobufs over, say, Bluetooth, they can always add support when they find the need. And Wireshark doesn't get bloated with a bunch of stuff that nobody actually uses.