Extending Protocol Buffers to use an existing protocol?

Question

As I understand it, Protocol Buffers is mostly used for projects that have control over both the server and client code. My general question is - can Protocol Buffers be used to serialize / deserialze binary messages to a server that uses an existing protocol? So, my questions:

1. Does Protocol Buffers natively support the ability to define a message in a text file and then to specify how it will be serialized / deserialized? For example, lets say that integers are big endian on the server and little endian on the client. Are there any native keywords that would take this into account? Another example - if a string is passed as one byte for each character in the string and has a fixed length or 2 bytes are used to specify the length, is there a native keyword to specify this so that the serialization / deserialization would be done properly?

2. If Protocol Buffers does not support any way to natively fine tune how serialization / deserialization should be done for an existing protocol, then could that capability be added through extension? Could keywords somehow be added that would be recognized by the serialization / deserialization methods? Perhaps this could be done by extending or modifying the code in protobuf-csharp-port or protobuf-net? The .proto file could use a new type of keyword called a serialization type that could be used to specify the type of serialization behavior for a field. If the methods implementing the serialization types were implemented as public virtual functions, then a custom class could override that behavior for specialized processing. The only other thing that I can think of is that since a schema is used by Protocol Buffers, it could use it when processing messages from the server, but should not try to send it to the server or expect any type of schema messages from the server. Is there anything else that would need to be done to make all of this work with protocol buffers?

3. In this link, protobuf-csharp-port and protobuf-net are compared. It looks like protobuf-net is faster. But, which implementation would be best suited for implementing a new serialization type that could be used to fine tune control on how a type can be serialized / deserialized?

4. If you don't think it would be appropriate to include this functionality in Protocol Buffers, then are there any APIs out there that can take a text file containing a description of a binary message and turn it into a C# class that properly does serialization and deserialization? I am already familiar with the API XSD2Code, which does serialization / deserialization with XML files. But that would not be helpful here since the data is binary, not XML.

Answer 1

1: no, protocol buffers is a single defined format; there are some different options (varint vs fixed length vs zigzag), but: not what you want

2: no

3: not applicable, by 2

I cannot comment on 4

Answer 2

After thinking about this overnight, there does seem to be a solution - although not with protocol buffers. XSD2Code can take as input an XSD file or an XML file and generate a C# class that offers serialization / deserialization methods as output.

So, all that really needs to be done is to write a small utility app that converts a text file containing the binary interface description into a proper XML file - and then run that output XML file through XSD2Code to generate the C# class. That should not be hard to do.