我需要在嵌入式手臂系统中使用protobuf。需要纯C的支持。该项目将使用客户端-服务器架构(带有Java,Python客户端的C服务器)。该项目需要考虑扩展协议的可能性。
例如-这样的请求将被发送到服务器:
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不支持自我描述消息。或任何反射方法。这就是为什么我选择这种结构。 这种结构是否适合这种情况?将来会成为问题吗?是否需要为新命令扩展协议(例如:
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?
最佳答案
自描述消息更多是一种特殊情况,即使它们得到支持,我也不认为您应该在此处使用它们。协议缓冲区对以后扩展消息提供了很好的支持,您可以为新的请求类型添加新的可选字段。
您不一定需要那些ValueType和RequestType字段。相反,您可以仅检查每个字段是否存在(has_value_int8等)。
您的请求消息将使用“Union Message”设计模式。如果您希望节省内存,则可以使用nanopb回调机制将函数绑定到每种请求类型。