 <p>Personally I'd suggest that you use an IOCP based design, but then I would say that as I have <a href="http://www.serverframework.com/" rel="nofollow">an IOCP based framework</a> that I've used for years to develop high performance servers for clients.</p> <p>I recently put together some of my reasons for prefering IOCP to the other models available on windows and they're available here on my blog <a href="http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html" rel="nofollow">here</a>. </p> <p>Often 'complexity' is cited as a reason to avoid IOCP, but, to be honest, if you're doing anything other than 'thread per connection' the code will be reasonably complex anyway. I have a <a href="http://www.serverframework.com/products---the-free-framework.html" rel="nofollow">free set of C++ code with example servers</a> that you could take a look at, it does all the IOCP work for you and the server examples are a good starting point for your own code. You can get it from <a href="http://www.serverframework.com/products---the-free-framework.html" rel="nofollow">here</a>.</p> <p>Alternatively I also have a free (for non commercial use) pluggable server platform which might interest you. With WASP you simply write a dll with some specific entry points and I do all of the networking stuff for you... See <a href="http://www.serverframework.com/products---wasp.html" rel="nofollow">here</a> for the download and <a href="http://www.serverframework.com/asynchronousevents/wasp-tutorial/" rel="nofollow">here</a> for the tutorial.</p> <p>Whichever model you decide on THE single most important thing, IMHO, is to start doing your performance and load testing from DAY 0. This way you KNOW how many concurrent connections you can support on your target hardware and you can quickly spot the inappropriate design decisions that cause this to drop. It's easy to squander the concurrency of your server. See <a href="http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html" rel="nofollow">here</a> for more info.</p> <p>Since Jay mentioned ENet... I've found that our IOCP based ENet server works well with the standard Enet client code. But remember, ENet is designed to be a peer to peer protocol and so there are some challenges when you start trying to use it on a server. With the standard ENet code you essentially have a single threaded network pump and that just can't compare to the scalability you get from IOCP. I ended up rewriting the ENet protocol handling code from scratch to work with async I/O and IOCP and that's a non trivial amount of work. I'm currently doing a new version of this code which uses the latest ENet protocol as a base and hopefully this will be available early in 2011 with complete perf comparisons to the standard ENet code used in large number of concurrent connection server situations.</p>