2

marcまたはprotobuf-netの経験がある人へ：

私は、サーバーがクライアントへの（TCPを介した）生涯にわたる持続的接続を保持するアーキテクチャを持っています。接続レイヤー/サーバーは高い稼働時間を必要とするため、メッセージを逆シリアル化してアプリサーバー/レイヤーに渡すだけです。bizロジック自体は含まれていません。

 clients -> connection layer (deserialization) -> app layer (business logic)

問題は、bizロジックに変更を加えることはできますが、接続層が逆シリアル化のためにモデルに依存しているため、アプリ層とクライアントによって共有されるモデルを変更できないことです。

転送/ルーティングの目的で、接続レイヤーにメッセージを部分的にのみ基本クラスに逆シリアル化させる方法はありますか？

それ以外の場合は、基本クラス内にバイナリフィールドを作成する必要があると思います。このフィールドはそのまま渡され、アプリ層によって逆シリアル化されます。1段階のシリアル化、2段階の逆シリアル化。

編集：肉付け

class Message
{
  User user;
  // not much else in here, potentially routing information
}

class RequestType1: Message
{
 // lots of fields 
 // which are specific to this type of request/reply 
}

class RequestType2: Message
{

}

接続層は、特定の要求タイプの構造を気にする必要はありません。そうすれば、クライアント層とアプリ層の両方が同意する限り、自由に変更できます。ただし、現在、接続レイヤーは逆シリアル化を実行するため、モデルを知る必要があります。変更を加えると、接続サーバーを再起動する必要があります。

ルーティングするのに十分な逆シリアル化が必要です。つまり、「ユーザー情報」+「サブタイプ名/番号」を意味します。

4

1 に答える 1

4

まず第一に、TCPはストリームベースであるため、protobufシリアル化メッセージをネットワーク経由で直接送信しないでください。完全なメッセージをいつ受信したかはわかりません。

はそのWithLengthPrefixために使用されます。すべてのメッセージにバイナリの長さのプレフィックスを付けて、完全なメッセージがいつ到着したかがわかるようにします。

もし私があなたなら、ルーティングに十分な情報を含むヘッダーを作成します。長さは必須ですが、転送されるメッセージのタイプなどを含めることもできます。つまり、コストのかかる逆シリアル化を呼び出す代わりに、各メッセージのヘッダーを検査するだけで済みます。

リクエストヘッダーの例：

  • ヘッダーバージョン（byte）
  • コンテンツタイプ（byte）（どこかにマッピングを作成する必要があります）
  • コンテンツの長さ（int）

現在、Griffin.Networking（http://github.com/jgauffin/griffin.networking）用の小さなアドオンを作成しています。このアドオンには小さなヘッダーがあり、メッセージにprotobufを使用します。プロジェクトを監視して、コミットされたときに更新を取得します。

于 2012-06-18T13:03:56.810 に答える