Which .NET technology would work as an improvement for this client/server application?

Question

I am helping a friend with his rewrite of his .NET application, currently using WinForms + sockets, which is a client/server program that currently has on average ~120 concurrent users (sending messages, using the chat). The client will grow and eventually must be able to handle a several thousand concurrent users.

A thread is created per user but this is not scalable due to hardware limitations (the server broke when stress-testing more users), not to mention the research I've done on the topic points to this being a bad practice.

Speaking of research, I've gathered the following possibilities for this rewrite:

1. Using asynchronous threads with a thread pool of 8 or so threads (will this be able to handle 8,000 users?) or

2. Using WCF (this seems like the more .NET approach and more intuitive with its callbacks instead of using loops)

I'm leaning more towards WCF right now. Before anyone asks, I have mentioned how this could be a web application instead, but he said no.

Edit (answers to questions):

The threads currently read from the socket (the packet) and parse it (simple string parsing) and depending on the type payload, executes another function. The functions executed are not very resource-intensive.

Answer 1

You can certanly go down the WCF Route.

However that would simply be a step sideways unless you decided to embrace Asynchronous Sockets.

Asynchronous is the way forward for high scalability

Essentially you should change your existing network code to be Asynchronous (if it isn't already).

Remove any blocking in your network code, accept more connections & messages and push off the parsing of your messages into a queue. Limit the number of threads processing your messages at any one time to stop your server from thrasing your CPU.

WCF has built in support for Asynchronous Networking.

• http://www.codeproject.com/Articles/234085/Fixing-WCF-to-build-highly-scalable-async-REST-API

However You don't need WCF to do Asynchronous Networking

Asynchronous C# sockets may be an easier refactor and may be a better fit for your specific project rather than refactoring your entire project and endpoints to use WCF.

• https://stackoverflow.com/questions/319732/tips-techniques-for-high-performance-c-sharp-server-sockets
• http://msdn.microsoft.com/en-us/library/bbx2eya8.aspx

WCF simply wraps the asynchronous sockets for you and you will end up with the same issues in your code that you had if you'd gone down the Asynchronous Sockets route.

So WCF is not going to be a silver bullet for your application. You'll need to do more to identify the bottlenecks and perhaps even shard your servers to push off processing into a more horizontally scalable solution.

i.e. Multiple Servers in a round-robin (or equivalent) solution for CPU intensive tasks.