1

現在、リモート ベンダーにデータを転送するコードを書いています。転送は TCP ソケットを介して行われます。私が抱えている問題は、データが可変長であり、フレーミングやサイズ マーカーがないことです。データの送信は問題ありませんが、返されたデータを処理する最善の方法がわかりません。

データは個別の「メッセージ」で構成されていますが、サイズは固定されていません。各メッセージには、このメッセージに含まれるコンポーネントを示す 8 または 16 バイトのビットマップがあります。一部のコンポーネントは固定長で、一部は可変長です。各可変長コンポーネントには、メッセージ全体のその部分のサイズ プレフィックスがあります。

最初にソケットを開くと、メッセージが送信され、それぞれが応答を受け取るはずです。データの読み取りを開始するときは、メッセージの先頭にいる必要があります。どのメッセージ フィールドが含まれているかを知るには、ビットマップを解釈する必要があります。データが到着したら、ビットマップで示される各フィールドが存在し、正しいサイズであることを検証する必要があります。

最初のメッセージをすべて読んだら、次のメッセージが始まります。私の懸念は、送信がメッセージの途中で切断された場合、どのように回復して次のメッセージの開始を正しく見つけることができるかということです。

接続障害をシミュレートする必要があり、コードはそのメッセージをキャンセルする前に、設定された回数だけ自動的に再試行する必要があります。

リモート エンドのコードを制御できず、フレーミング バイトやサイズ プレフィックスをメッセージに追加できません。

ベスト プラクティス、設計パターン、またはこれを処理するための最善の方法に関するアイデアはすべて歓迎されます。

4

3 に答える 3

1

ユーザーの観点から見ると、TCP はデータのストリームであり、シリアル ポート経由で受信する場合と同じです。パケットもマーカーもありません。

ノンブロッキングの read/recv 呼び出しは、解析可能な時点で現在到着しているものを返します。解析中にメッセージの最後に到達する前にデータが不足した場合は、さらにデータを読み取り/受信して解析を続行します。リンス。繰り返す。別のメッセージが続いた場合、特定のメッセージに必要なバイト数を超える可能性があることに注意してください。

TCP ストリームは、バイトを失ったり、並べ替えたりしません。接続が切断されたり、送信者にバグがない限り、メッセージが切り捨てられることはありません (たとえば、一部しか書き込み/送信できず、残りを書き込み/送信しようとしなかった場合など)。壊れている TCP ストリームを続行することはできません。新しいものを開いて、新たに始めることしかできません。

于 2012-10-02T17:45:53.883 に答える
1

TCP ストリームは、メッセージの途中で「カット」してから再開することはできません。

送信に十分な短い中断がある場合、両端の O/S が対応し、必要に応じてパケットが再送信されますが、ストリームが連続している限り、これはエンド ユーザー アプリケーションには見えません。

TCP 接続が完全に切断された場合、両端で接続を再開する必要があります。その時点で、送信システムは新しいメッセージ境界で最初からやり直す必要があります。

于 2012-10-02T14:07:13.683 に答える
0

このような場合は、ネットワーク フレームワーク (netty など) を使用するか、Play 2.0 の Iteratee IO などの別の IO メカニズムを使用する方がずっと簡単です。

于 2012-10-02T14:10:55.190 に答える