1

BeginRecieve 呼び出しで提供されるコールバックがいつトリガーされるのか疑問に思っていました。

  • バッファが保持できるほど多くのデータを受信したときですか？もしそうなら - データがバッファよりも小さい場合はどうなりますか）
  • TCP/IP パケットを 1 つ受信したときですか？
  • それは何か他のものですか？

あまり明確にできないので、繰り返します。

現在、すべてのドキュメントには、BeginReceive で指定されているように、「データが受信される」とすぐにコールバックが呼び出されると記載されています。しかし、これはかなりあいまいです: 他のプロセスがどのようにデータを提供しているかを正確に知らない場合、その瞬間は正確にはいつですか?

基準の 1 つは、状態オブジェクトのバッファーが指定されたバッファーサイズまで満たされると、BeginReceive() が完了したと見なされる (したがって、callbask が呼び出される) ことです。しかし、「配信」プロセスがデータを未知の量で不規則なパターンで供給している場合はどうなるでしょうか? たとえば、最初に 100 バイトを連続して配信し、次に 1 ミリ秒の時間間隔があり、さらに 200 バイトが続く場合: BeginReceive は 100 バイトの着信データで完了しますか? それとも300？

http://www.pcreview.co.uk/forums/exactly-beginreceive-socket-considered-completed-t2899270.html

4

2 に答える 2

0

ソケットがTCPソケットであると仮定します。次に、データが利用可能になるとコールバックがトリガーされますが、コールバックで配信されるのは最大でバッファー サイズと同じです。とにかく、フレーミング プロトコルが必要です (BeginReceive(..) を複数回呼び出して、送信したフレームを検出して組み立てる必要があることを意味します)。

于 2012-06-14T10:14:17.940 に答える
0

私の経験では、遅滞なく利用可能なデータに対して呼び出されます。これは、MTU サイズのオーダーであるため、読み取りが 1400 バイト程度のようにかなり小さい可能性があることを意味します。

パケットが順不同で到着した場合、論理的に最初のパケットが到着した瞬間にすべてのパケットがアプリケーションに表示されるため、読み取りはその倍数になる可能性があります。この場合、キューに入れられた連続するすべてのパケットを一度に読み取ることができます。

ネットワークが個々のパケットを配信するのと同じ速さでアプリケーションがバイトをデキューできない可能性があるため、非常に高速な接続では読み取りサイズが増加すると思います。

補足: BeginReceive-callback は、Receive が返されるのとまったく同じタイミングで呼び出されます。そのようにレイテンシを減らすことはできません。(非同期操作はブロック操作よりもオーバーヘッドが高くなる可能性があるため、実際にはレイテンシがわずかに増加します)。

于 2012-06-14T10:24:34.960 に答える