title: .NET Async Sockets: any benefit of SocketAsyncEventArgs over Begin/End in this scenario?
body: <p>Socket has these <a href="http://msdn.microsoft.com/en-us/library/bb968780.aspx">new async methods since .NET 3.5</a> for use with SocketAsyncEventArgs (e.g. <a href="http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.sendasync.aspx">Socket.SendAsync()</a>), benefits being under the hood they use IO completion ports and avoid the need to keep allocating.</p>
  
  <p>We have made a class called <strong><em>UdpStream</em></strong> with a simple interface - just <em>StartSend</em> and a <em>Completed</em> event. It allocates two SocketAsyncEventArgs, one for send and one for receiving. The StartSend simply dispatches a message using SendAsync, and is called about 10 times a second. We use the Completed event on the receive SocketAsyncEventArgs, and after each event is handled we all ReceiveAsync so that it forms a receive loop. Again, we receive roughly 10 times per second.</p>
  
  <p>Our system needs to support up to <strong>500</strong> of these <em>UdpStream</em> objects. In other words our server will communicate concurrently with 500 different IP endpoints.</p>
  
  <p>I notice in the MSDN SocketAsyncEventArgs examples that they allocate N x SocketAsyncEventArgs, one for each outstanding receive operation you want to handle at one time. I am not clear exactly how this relates to our scenario - it seems to me that perhaps we are not getting the benefit of SocketAsyncEventArgs because we are simply allocating one per endpoint. If we end up with 500 receive SocketAsyncEventArgs I am presuming we will get no benefit. Perhaps we still get some benefit from IO completion ports?</p>
  
  <ul>
  <li><p><strong>Does this design make correct use of SocketAsyncEventArgs when
  scaling to 500?</strong></p></li>
  <li><p><strong>For the case where we have a single "UdpStream" in use, is there
  any benefit to using SocketAsyncEventArgs vs using the older Begin/End API?</strong></p></li>
  </ul>