3

組み込みアーム システムで protobuf を使用する必要があります。純粋な C のサポートが必要です。プロジェクトは、クライアント サーバー アーキテクチャ (C サーバーと Java、Python クライアント) を使用します。このプロジェクトでは、プロトコルを拡張する可能性を考慮する必要があります。たとえば、このようなリクエストはサーバーに送信されます。

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

アドレス、長さ、タイプ、値 - 必須; ファイル名 - オプション。リクエストには、write、read ... のいずれかのコマンドが含まれている必要があります (ただし、複数は指定できません)。私はそれが次のようなものであるべきだと思います：

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 を使用する価値はありますか?

4

1 に答える 1

2

自己記述型メッセージはより特殊なケースです。たとえサポートされていたとしても、ここで使用すべきではないと思います。Protocol Buffers は、後でメッセージを拡張するための非常に優れたサポートを備えています。新しい要求タイプに新しいオプション フィールドを追加するだけです。

これらの ValueType および RequestType フィールドは必ずしも必要ではありません。代わりに、各フィールドが存在するかどうかを確認できます (has_value_int8 など)。

リクエスト メッセージは、「Union Message」デザイン パターンを使用します。メモリを節約したい場合は、nanopb コールバック メカニズムを使用して、関数を各リクエスト タイプにバインドできます。

于 2013-03-19T07:32:41.060 に答える