Java protobuf RPC结构（嵌入式ARM）

我需要在嵌入式arm系统中使用protobuf。需要纯C的支持。该项目将使用客户机-服务器体系结构（带有java、Python客户机的C服务器）。该项目需要考虑扩展协议的可能性。 例如，此类请求将发送到服务器：

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

我认为在这种情况下最好的选择是nanopb（）。在我看来，nanopb代码写得非常好

据我所知，nanopb不支持自描述消息。或任何反射方法。这就是我选择这种结构的原因这种结构适合这种情况吗？将来会有问题吗？如果需要为新命令扩展协议（例如：

listStatus

）？

如果用作服务器nanopb（如：），我是否可以用作客户端？（据我所知，nanopb不支持.proto中的服务。）：

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

---

PS：protobuf-c值得使用吗？

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

您不一定需要这些ValueType和RequestType字段。相反，您只需检查每个字段是否存在（具有值等）

---

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

谢谢您的回复。服务怎么样？使用nanopb编写的兼容服务器是否与客户端兼容，是否由.proto文件中的指令

services

创建？nanopb目前不支持

service

关键字。此外，协议缓冲区没有定义

服务

的实现，因此它不会在不同的库之间兼容。我建议不要使用

服务

关键字。谢谢。所以我只是不明白

服务
关键字的含义。。。（这是我第一次使用protobuf）。我认为在不同的实现之间的兼容性是必要的。。。
service MyService {
  rpc Search (Request) returns (Response);
}