c - Winsock でデータを受信する

Question

現在、オンライン ゲームのネットワークをプログラミングしていますが、データの受信についてどうすればよいかよくわかりません。問題は、パケットのサイズを実際に推測できないことです。そのため、パケットからわずか 4 バイトを読み取り、それらを int に変換して、パケットのサイズを知ることを考えました。次に、そのサイズのバッファを作成し、残りのパケットを受信しますが、それは良い考えですか?

参考までに、ノンブロッキング I/O を使用しています。

Answer 1

あなたのアプローチは合理的に聞こえます-基本的にメッセージサイズをメッセージヘッダーに埋め込むことになります。これは、状況でそれを処理する最も堅牢な方法である可能性があります。別の方法として、固定長のパケット (ick) を使用するか、ある種の区切り文字を使用することもできます (これは、バイナリ メッセージではまったく機能しません)。

このリンクsocket-protocol-fundamentalsには、役立つ可能性のある追加情報がいくつかあります。

Answer 2

注意しないと、提案しているのは作成中のセキュリティ ホールです。したがって、特にネットワーク入力を信頼する場合は、非常に注意してください。

TCP または UDP を指定しなかったので、一般的なガイダンスをいくつか示します。

TCP または UDP の場合、サイズ N のバッファを 1 つ割り当てます。ここで、N は、リモート プレーヤーまたはサーバーから送信できる最大のメッセージ サイズです。UDP の場合、これを 1500 バイト未満に保つことをお勧めします。TCP の場合は、より大きなサイズにすることができます。

UDP か TCP かに関係なく、ソケットをノンブロッキングにします。これは、データの待機中にゲーム ループが停止しないようにするためです。

メッセージのヘッダーにサイズと crc-hash を追加します。メッセージを UDP パケットとして受信するときに、パケット ヘッダーのサイズが N より大きい場合 (つまり、切り捨てられたパケットが既にあることを意味します)、またはハッシュが受信サイズで計算したものと一致しない場合は、単に拒否します。パケット。追加の整合性チェックがなければ、ハッカーや詐欺師がパケット構造を悪用して勝つためです。

TCP の場合、基本的には、説明した方法でメッセージを組み立てます。各メッセージには、後に続くバイト数を指示するヘッダーがあります。ただし、UDP について説明したのと同じことを行います。整合性チェックのために独自のヘッダーを追加します。メッセージの破損と ASSERT が発生した場合は、ソケットを閉じます。

TCP では、TCP セグメンテーションのため、同じ "recv" 呼び出しでメッセージ全体を受信できない場合があります。つまり、メッセージの一部しか受信していない場合は、それを一時バッファーに格納します。(次のゲーム フレームで) recv への後続の呼び出しで、このバッファーに追加します。送信された可能性のある次のメッセージを誤って読み取らないように、予想されるメッセージの終わりを追跡するために変数を保持する必要があります。

幸運を。

Answer 3

TCP ソケットを使用している場合は、パケット サイズに依存しないでください。データ フローは、パケットのストリームではなく、バイトのストリームです。