TCP/IP および UDP のパケットには、サイズに関する参照が含まれています。IP ヘッダーには、 IP ヘッダーとデータの長さをバイト単位で指定する 16 ビット フィールドが含まれます。TCP ヘッダーには、TCP ヘッダーのサイズを 32 ビット ワードで指定する 4 ビット フィールドが含まれます。UDP ヘッダーには、 UDP ヘッダーとデータの長さをバイト単位で指定する 16 ビット フィールドが含まれます。
つまりね。
C# で System.Net.Sockets 名前空間を使用している場合でも、Win32 でネイティブの Winsock を使用している場合でも、Windows で標準的なありふれたソケットを使用すると、IP/TCP/UDP ヘッダーは表示されません。これらのヘッダーは取り除かれるため、ソケットを読み取ったときに得られるのは実際のペイロード、つまり送信されたデータです。
私がソケットを使用してこれまで見てきたすべての典型的なパターンは、送信するデータの前にアプリケーション レベルのヘッダーを定義することです。少なくとも、このヘッダーには、続くデータのサイズが含まれている必要があります。これにより、サイズを推測することなく、各「メッセージ」全体を読むことができます。たとえば、同期パターン、CRC、バージョン、メッセージのタイプなど、好きなだけ凝ったものにすることができますが、本当に必要なのは「メッセージ」のサイズだけです。
そして、価値があるので、パケットの終わりの区切り文字の代わりにヘッダーを使用することをお勧めします。EOP 区切り文字に重大な欠点があるかどうかはわかりませんが、ヘッダーは、私が見たほとんどの IP プロトコルで使用されているアプローチです。さらに、メッセージが完了したことを示すパターンがストリームに表示されるのを待つよりも、最初からメッセージを処理する方が直感的に思えます。
編集: Google Protocol Buffers プロジェクトに気付いたばかりです。私が知る限り、これは WCF のバイナリ シリアライゼーション/デシリアライゼーション スキームです (単純化しすぎていると思います)。WCF を使用している場合、送信されるメッセージのサイズについて心配する必要はありません。これは、WCF 配管が舞台裏でこれを処理するためです。おそらく、プロトコルでメッセージの長さに関連するものを見つけられなかったのはそのためです。バッファのドキュメント。ただし、ソケットの場合は、サイズを知っておくと、上で説明したように非常に役立ちます。私の推測では、Protocol Buffers を使用してデータをシリアライズし、それを送信する前に思いついたアプリケーション ヘッダーを追加します。受信側では、ヘッダーを取り出してから、メッセージの残りを逆シリアル化します。