Socket has these new async methods since .NET 3.5 for use with SocketAsyncEventArgs (e.g. Socket.SendAsync () ), the benefits are under the hood, they use I / O completion ports and avoid the need to allocate.
We created a class called UdpStream with a simple interface - only StartSend and the Completed event. It allocates two SocketAsyncEventArgs, one for sending and one for receiving. StartSend simply sends a message using SendAsync and is called about 10 times per second. We use the Completed event on SocketAsyncEventArgs, and after each event all ReceiveAsync is processed to form a receive cycle. Again, we get about 10 times per second.
Our system must support up to 500 of these UdpStream objects. In other words, our server will communicate simultaneously with 500 different IP endpoints.
I noticed in the MSDN SocketAsyncEventArgs examples that they allocate N x SocketAsyncEventArgs, one for each outstanding receive operation that you want to process at a time. I don’t quite understand how this relates to our scenario - it seems to me that perhaps we are not benefiting from SocketAsyncEventArgs, because we simply allocate one to the endpoint. If we get 500, get SocketAsyncEventArgs, I guess we won’t get any benefit. Perhaps we still get some benefits from the I / O ports?
Does this design support the correct use of SocketAsyncEventArgs when scaling to 500?
In the case where we use a single "UdpStream", is there any benefit from using SocketAsyncEventArgs versus using the older Begin / End API?