5

Socket には、.NET 3.5 以降、SocketAsyncEventArgs (例: Socket.SendAsync() ) で使用するこれらの新しい非同期メソッドがあり、内部で IO 完了ポートを使用し、割り当てを維持する必要がなくなるという利点があります。

StartSendとCompletedイベントだけの単純なインターフェイスを持つUdpStreamというクラスを作成しました。送信用と受信用の 2 つの SocketAsyncEventArgs を割り当てます。StartSend は、SendAsync を使用して単純にメッセージをディスパッチし、1 秒間に約 10 回呼び出されます。受信 SocketAsyncEventArgs で Completed イベントを使用し、各イベントが処理された後、すべての ReceiveAsync で受信ループを形成します。ここでも、1 秒あたり約 10 回受信しています。

私たちのシステムは、これらのUdpStreamオブジェクトを最大500 個サポートする必要があります。つまり、サーバーは 500 の異なる IP エンドポイントと同時に通信します。

MSDN SocketAsyncEventArgs の例では、一度に処理する未処理の受信操作ごとに 1 つ、N x SocketAsyncEventArgs を割り当てることに気付きました。これが私たちのシナリオにどのように関係するのか正確にはわかりません.エンドポイントごとに 1 つを割り当てているだけなので、おそらく SocketAsyncEventArgs の利点が得られていないように思えます. 最終的に 500 receive SocketAsyncEventArgs になった場合、何のメリットもないと思います。おそらく、まだ IO 完了ポートの恩恵を受けているのでしょうか?

  • この設計は、500 にスケーリングするときに SocketAsyncEventArgs を正しく使用しますか?

  • 単一の「UdpStream」を使用している場合、SocketAsyncEventArgs と古い Begin/End API を使用する利点はありますか?

4

2 に答える 2

6

Socket には、SocketAsyncEventArgs (Socket.SendAsync() など) で使用する .NET 3.5 以降のこれらの新しい非同期メソッドがあります。内部で IO 完了ポートを使用し、割り当てを維持する必要がなくなるという利点があります。

Begin/End メソッドも IO Completion ポートを使用します。

単一の「UdpStream」を使用している場合、SocketAsyncEventArgs と古い Begin/End API を使用する利点はありますか?

製品をより速く起動して実行できるようになるため、知っていることに固執する必要があります。しかし、トランスポートを処理する厳密な IO 処理クラスも作成します。輸送性能がボトルネックになっていることが判明した場合に、新しいモデルへの切り替えが容易になります。

于 2011-08-30T07:28:43.283 に答える