アプリケーション層プロトコル - パケットのサイズが異なる

Question

インスタントメッセージング用にTCPの上に独自のアプリケーション層プロトコルを定義したとします。私はメッセージのパケット構造を使用しました。対称型（AES）と非対称型（RSA）の暗号化を使用しているので、さまざまなメッセージタイプに異なる パケットサイズを取得します。今私の質問に。

ソケットから1つのアプリケーション層パケットを受け取る方法は？ 指定する必要があるサイズは？

ありがとうございます。

私は2つのアプローチを念頭に置いています。 TCPから

1. 読むには 実際のパケットサイズを表しバイトの固定量をストリーミングし、最終的にストリームからバイトの元集まっサイズを再読み込み。

2. ストリームから最大パケットサイズを読み取ります。得られたバイトの実際のサイズが であることを確認し、どのメッセージタイプであったかを決定します。

ここでは、より一般的な質問です。パケットサイズ、暗号化方法、受信者、送信者などのメタデータを提供する必要がありますか？はいの場合、これらのメタデータも暗号化する必要がありますか？

Answer 1

TCPを使用すると、ネットワークから読み取るときに、その時点で受け取ったバイト数が保証されないことに注意してください。つまり、クライアントはwrite()、、しかしでフルパケットを送信する可能性があります。つまり、read()が同じバイト数を受け取るわけではありません。したがって、あなたのコードは、常にを読み取る必要があります。バイト数をネットワークから取得し、必要なバイト数を受け取ったことを（累積データに基づいて）確認してから、パケット（タイプ、内容、等）そこから。

一部のアプリケーションでは、ネットワークデータの読み書きにステートマシンのエンコーダ/デコーダと固定サイズのバッファを使用しています。他のアプリケーションは、 "フルパケット"に十分な大きさのバッファを動的に割り当て、 "フルパケット"バッファがいっぱいになるまでネットワークからバイトを読み続ける。どのアプローチをとるかは、アプリケーションによって異なります。したがって、読み込みに使用するサイズは、コードが完全なパケットを受け取ることを保証する方法ほど重要ではありません。

脅威モデル（、つまりのプロトコルが守るべき脅威、プロトコルがクライアント/ユーザーに提供する必要がある保証）に応じて、追加のメタデータを暗号化する必要があるかどうかについては、より多くの文脈/詳細なしでその質問に答える簡単な方法はありません。

希望すると便利です。