Do TcpListener AcceptTcpClientAsync or AcceptSocketAsync use I/O Completion Ports or...

Question

Do the new .NET 4.5 TcpListener AcceptTcpClientAsync or AcceptSocketAsync methods use I/O Completion Ports or do we still need to use SocketAsyncEventArgs to create a high performance socket server?

Any TcpListener async examples anywhere? I could find almost nothing on the new TcpListener async methods and even the MSDN doc that lists them is void of any actual useful info.

I would also love to read about the additional "flexibility" that a Socket offers over a TcpClient and when the former would be more useful.

Thanks for any suggestions and insight, Dave

Answer 1

Yes, the *Async methods use IOCPs. So do Begin/End, for that matter.

The performance increase with SocketAsyncEventArgs is not due to IOCPs. It is due to putting less pressure on the garbage collector by reusing SocketAsyncEventArgs instances. (As a side note, if you're allocating a new SocketAsyncEventArgs for each operation, you're not really gaining anything by using that API).

If you need high-performance sockets, you can see Stephen Toub's post on awaiting socket operations. He defines a SocketAwaitable that wraps SocketAsyncEventArgs and provides similar performance.

However, very, very few applications need that level of performance. Scaling out (or up) is often a better option.

       -Steve

---

Programming blog: http://nitoprograms.blogspot.com/
  Including my TCP/IP .NET Sockets FAQ
  and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer

How to get to Heaven according to the Bible

Answer 2

Thanks Stephen for the reference to Toub's article. I am curious though why you say scaling up (more MHz?) or out (more machines?) would be better than making the socket server as fast as possible? The other two options would always be complementary of course...

Answer 3

If you really need the socket server "as fast as possible", it wouldn't be in .NET. ;)

I find that software maintainability is usually more important than raw speed. Code using SocketAsyncEventArgs (or even SocketAwaitable) is going to be more complex than code that just uses other async methods.

It's not difficult to upgrade a server (MB, not MHz, in this case). It is more difficult to restrict the code so it scales out (e.g., a server farm or Azure).

Consider this: if your server is really going to be busy enough that the regular APIs are insufficient, then you need to use special APIs (which gain you a slight speed advantage). But you're still almost busy enough that the special APIs are insufficient, too. Are the special APIs efficient enough for future traffic?

If the special APIs are sufficient for future traffic, then are the regular APIs sufficient for future traffic? What if we bought a little extra RAM or an additional server - would the regular APIs be sufficient then?

It used to be that the special APIs added a fair amount of complexity (to really get a speed advantage, I mean). I think Stephen Toub's wrapper reduces that complexity bar (but I haven't actually used them). There is a line where the increased code complexity (impacting maintenance) exceeds the value of running on a single small server. The line has just moved, but how far?

You'll have to answer that question for yourself. :)

       -Steve

---

Programming blog: http://nitoprograms.blogspot.com/
  Including my TCP/IP .NET Sockets FAQ
  and How to Implement IDisposable and Finalizers: 3 Easy Rules
Microsoft Certified Professional Developer

How to get to Heaven according to the Bible