java - protobuf RPC结构(嵌入式ARM)

Question

我需要在嵌入式 arm 系统中使用 protobuf。需要纯C的支持。该项目将使用客户端-服务器架构(C服务器与java，Python客户端)。该项目需要考虑扩展协议(protocol)的可能性。例如 - 这样的请求将被发送到服务器:

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

其中地址、长度、类型、值 - 必需；文件名 - 可选。请求必须包含命令之一:写入、读取...(但不能超过一个)。我认为应该是这样的:

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;
    ...
}

我认为在这种情况下最好的选择是 nanopb ( http://koti.kapsi.fi/jpa/nanopb/ )。在我看来 nanopb 的代码写得很好。

据我了解，nanopb 不支持自描述消息。或任何反射方法。这就是我选择这种结构的原因。 这种结构是否适合这种情况？将来会成为问题吗？是否需要为新命令扩展协议(protocol)(例如:listStatus <id> <verbose>)？

如果用作服务器 nanopb(如:http://code.google.com/p/nanopb/source/browse/example/server.c)，我可以用作客户端吗？ (据我了解，nanopb 不支持 .proto 中的服务。):

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

PS:protobuf-c值不值得用？

Answer 1

自描述消息更像是一种特殊情况，我认为即使支持它们也不应该在这里使用它们。 Protocol Buffers 对以后扩展消息有很好的支持，你可以为新的请求类型添加新的可选字段。

您不一定需要那些 ValueType 和 RequestType 字段。相反，您可以只检查每个字段是否存在(has_value_int8 等)。

然后您的请求消息将使用“Union Message”设计模式。如果希望节省内存，可以使用 nanopb 回调机制将函数绑定(bind)到每个请求类型。