問題タブ [protocol-buffers]

Google のプロトコル バッファを使用して、TCP 接続を介して (プロトコル バッファを使用して別のアプリケーションから送信された) データを逆シリアル化するアプリケーションを作成しようとしています。問題は、Python のプロトコル バッファが文字列からのデータしか逆シリアル化できないように見えることです。TCP には明確に定義されたメッセージ境界がなく、受信しようとしているメッセージの 1 つに繰り返しフィールドがあるため、最終的に逆シリアル化する文字列を渡す前に、どれだけのデータを受信しようとするかわかりません。

Pythonでこれを行うための良い方法はありますか?

なぜグーグルのプロトコルバッファのlua実装ではないのですか？luaのより良い解決策はすでにありますか？

ここで 2 つの質問があります。

質問1：

-- thrift は内部クラスの機能を提供できますか? (次の例を参照してください)

――できれば、そのような機能を簡単に節約できますか？

スクライブ インターフェース (scribe/if/scribe.thrift) は次のとおりです。しかし、そのメッセージ フィールドは文字列のみであり、柔軟性が十分ではないと思います。

次のことができれば素晴らしいと思います（thrift自体がそのドキュメントに従って内部クラス機能を提供するかどうかさえわかりませんが、プロトコルバッファは間違いなく可能です）。

質問2：

-- スクライブは内部データ表現としてプロトコル バッファを簡単に使用できますか? (あまりコードを変更しないでください)

-- 上記の質問に対する答えが「いいえ」の場合、Google はその sribe 実装をオープンソース化しましたか?

プロトコル バッファに、ネストされたメッセージのコレクションを持つメッセージを含める方法はありますか? たとえば、Supervisor というメッセージには、Supervisor の名前と部門とともに Employees のコレクションが含まれている場合があります。

finalプロトコル バッファ クラスは、おそらく効率のためにマークされています。ただし、これによりテストが非常に困難になります。Mockitoは最終クラスをモック/スパイできません。試してみましたがPowerMockito成功しませんでした:テスト用にクラスをClassFormatError準備するときに a が発生します。final

これまでの私の解決策は、モック可能なアダプター インターフェイスを作成することですが、より手間のかからない方法があることを願っています。

エンコーディングスキーム/複数のオペレーティングシステムとエンディアンの歴史は、すべての形式の文字列データ（つまり、すべてのアルファベット）のエンコーディングに関して混乱を招きました。このため、プロトコルバッファは文字列タイプでASCIIまたはUTF-8のみを処理し、C++wstringを受け入れる多態的なオーバーロードは表示されません。問題は、UTF-16文字列をプロトコルバッファにどのように取り込むことが期待されるかということです。

おそらく、データをアプリケーションコードにwstringとして保持し、メッセージに詰め込む（またはメッセージから抽出する）前にUTF-8変換を実行する必要があります。これを行うための最も簡単な-Windows/Linuxポータブルな方法は何ですか（十分にサポートされているライブラリからの単一の関数呼び出しは私の一日を作ります）？

データはさまざまなWebサーバー（LinuxおよびWindows）から発信され、最終的にSQL Server（および場合によっては他のエンドポイント）に到達します。

--編集1---

Mark Wilkinsの提案は法案に適合しているようです。おそらく、ライブラリの経験がある人なら、wstringからUTF-8までのコードスニペットを投稿して、それがどれほど簡単になるかを判断できます。

-編集2-

sthの提案はさらにそうです。ブーストシリアル化についてさらに調査します。

DelphiでGoogleProtocolBuffersを実装するプロジェクトを知っている人はいますか？

アプリケーション レベルのプロトコルが UDP 経由で実装されているとします。クライアントのタイムアウトが必要なため、サーバーは通信する各クライアントの状態を保持する必要があります。

また、使用されていると仮定しますselect。

1. マルチスレッドサーバーを実装するのは常に最善ですか? サーバーのタイムアウトが発生する場合、リンクリストも同じことを行うと思いますtime=Earliest Timeout of a client- CurrentTime。リンクリストは、新しいスレッドを作成するオーバーヘッドを回避しながら、クライアントの状態を保持するのと同じ機能を持ちます (ただし、サーバーがクライアント固有のタイムアウトを維持するためにいくらか複雑になります)。

2. マルチスレッドが選択された場合、それ以降は、新しいクライアントに対して新しいソケットを呼び出すのが最善ですか? これにより、システム リソースのオーバーヘッドが発生します。しかし、デフォルトのサーバーソケット（bindサーバーのウェルノウンポートを使用）は、バッファーを取得したため、同じことを行うと思います（まあ、スケーラブルな数のクライアントには十分な長さではないかもしれません..）

ありがとう！

googleプロトコルバッファエンコーディングの概要では、「ジグザグエンコーディング」と呼ばれるものが導入されています。これは、大きさが小さい符号付き数値を取得し、大きさが小さい一連の符号なし数値を作成します。

例えば

等々。彼らがこれのために与えるエンコーディング関数はかなり賢いです、それは次のとおりです：

これがどのように機能するかは理解していますが、これを逆にして符号付き32ビット整数にデコードする方法を一生理解することはできません。

Message::ByteSizeシリアル化されたメッセージの長さをバイト単位で調べるために、C++ API に相当する protobuf-netを探しています。