protobuf RPC structure (embedded ARM)

Question

I need to use protobuf in embeded arm system. Need the support of pure C. The project will use a client-server architecture (C server with the java, Python clients). The project requires to consider the possibility of extending the protocol. for example - such requests will be sent to the server:

read <address> <type> <count> [<filename>]
write <address> <type> <value>
...

where address, length, type, value - required; filename - optional. Request must contain one of the commands: write, read ... (but not more than one). I think it should be something like this:

message WriteRequest {
    enum ValueType {
        INT8 = 0 [(string)="int8"];
        INT16 = 1 [(string)="int16"];
        INT32 = 2 [(string)="int32"];
        INT64 = 3 [(string)="int64"];
        FLOAT32 = 4 [(string)="float32"];
        FLOAT64 = 5 [(string)="float64"];
        BYTEARRAY = 6 [(string)="bytearray"];
    }

    required uint64 address = 1;

    required ValueType value_type = 2 [default = INT32];
    optional int32 value_int8 = 3;
    optional int32 value_int16 = 4;
    optional int32 value_int32 = 5;
    optional int32 value_int64 = 6;
    optional float value_float32 = 7;
    optional double value_float64 = 8;
    optional bytes value_bytearray = 9;
}
...
message Request {
    enum RequestType {
        READ_REQUEST = 1;
        WRITE_REQUEST = 2;
        ...
    }

    required RequestType request_type = 1;
    optional ReadRequest read = 3;
    optional WriteRequest write = 4;
    ...
}

I think like the best choice in this case - nanopb (http://koti.kapsi.fi/jpa/nanopb/). In my view code nanopb written very well.

As I understand it, nanopb not support Self-describing Messages. Or any reflection methods. That's why I chose this structure. Is this structure optimal for this case? Can be a problem in the future? if will need to extend the protocol for new commands (for example: listStatus <id> <verbose>)?

If used as a server nanopb (like this: http://code.google.com/p/nanopb/source/browse/example/server.c), will I be able to use as a client? (as I understand, nanopb not support Services in .proto.):

service MyService {
  rpc Search (Request) returns (Response);
}

PS: Is it worth to use protobuf-c?

Answer 1

Self-describing messages are more of a special case, I don't think you should use them here even if they were supported. Protocol Buffers has very good support of extending messages later, you can just add new optional fields for new request types.

You don't necessarily need those ValueType and RequestType fields. Instead you can just check if each field is present (has_value_int8 etc.).

Your Request message will then use the "Union Message" design pattern. If you wish to save memory, you can use nanopb callback mechanism to bind functions to each of the request types.