したがって、Win32プログラミングとソケットに関する割り当てはほぼ完了しましたが、転送に関するいくつかの統計を生成して分析する必要があります。私が問題を抱えている唯一の部分は、クライアントからサーバーに送信されたパケットの数を把握する方法です。
送信されるデータは可変長である可能性があるため、受信した合計バイト数を#define'd値で除算することはできません。
すべてを行うには非同期呼び出しを使用する必要があるため、サーバーのソケットに対して受け取るFD_READメッセージごとにカウンターをインクリメントしようとしています。ただし、潜在的に大きなファイルサイズを受け入れる必要があるため、約64kのバッファーサイズでrecv/recvfromを呼び出す必要があります。小さなパケット（az）を送っても問題ありません。しかし、1024文字の文字列を10x送信すると、サーバーは2つまたは3つのパケットを受信したと報告しますが、送受信されたバイト数に関しては0％のデータ損失があります。
パケット数を取得する方法はありますか？
前もって感謝します ：）
これは、「パケット」の意味に要約されます。
おそらくご存じのとおり、TCP/UDP メッセージがネットワーク上で送信されると、送信されるデータは対応する TCP/UDP ヘッダーで「ラップ」またはプリペンドされます。これは、IP ヘッダーに「ラップ」され、イーサネット フレームに「ラップ」されます。Wireshark のようなスニッフィング パッケージを使用すると、このブレークアウトを確認できます。
ポイントはこれです。「パケット」という言葉を聞くと、IP レベルのデータを思い浮かべます。IP データは回線上で実際にパケット化されるため、IP について話すときはパケット数が理にかなっています。ただし、データの送受信に通常のソケットを使用している場合、IP ヘッダーと TCP/UDP ヘッダーは取り除かれます。つまり、ソケットからこの情報を取得することはありません。そして、その情報がなければ、送信された「パケット」(これも IP だと思います) の数を特定することは不可能です。
長さとカウンターを使用して独自のヘッダーを追加することで、他の人が提案していることを実行できます。この情報は、受信バッファーのサイズを正確に決定するのに役立ちますが、特に TCP を使用している場合は、パケット数 (ここでも IP...) を決定するのには役立ちません。
Winsock ソケットを使用してパケット数を正確に判断したい場合は、ここで提案されているように「生の」ソケットを作成することをお勧めします。このソケットは、ローカル NIC から見たすべての IP トラフィックを収集します。IP および TCP/UDP ヘッダーを使用して、クライアントとサーバーのソケット、つまり IP アドレスとポート番号に基づいてデータをフィルタリングします。これにより、データの送信に実際に使用された IP パケットの数を正確に把握できます。
パケットに固定ヘッダーがありますか、それとも独自に定義することが許可されていますか? 独自に定義できる場合は、ヘッダーにパケット カウンターと長さを含めます。カウンターでロールオーバーを説明する実行中の合計を保持する必要がありますが、これにより、受信したパケットではなく、送信されたパケットを確実にカウントできます。単純な割り当ての場合、(明らかに UDP を使用すると) 損失が発生することはないでしょうが、損失が発生した場合は、パケット カウンターを使用して、送信されたメッセージが正確に反映されていることを確認できます。
あなたの質問に対する直接的な回答ではなく、別の解決策の提案です。
転送したいデータの前に長さ記述子を送るとどうなるでしょうか? そうすれば、クライアントに適切なバッファ サイズ (多すぎず、少なすぎず) を割り当てることができ、転送が終了したときに損失が発生したかどうかも確認できます。
TCP では、プロトコル自体がエラーのない送信を処理するため、まったく問題はないはずです。さもなければ、意味のあるエラーが発生するはずです。
UDP を使用すると、適切なシーケンス ID を持つ固定サイズのチャンクに転送を分割することもできます。それらを並べ替える前に、すべての受信パッケージを蓄積し (UDP は受信順序を保証しません)、データを一緒に貼り付ける必要があります。
一方、UDP をサポートすることが本当に必要な場合は、それについて考える必要があります。そのプロトコルをエラーセーフにしたい場合は、手動のオーバーヘッドがかなりあるためです... (問題のリストについては、TCP に関するウィキペディアの記事を参照してください)移動する）