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.

  • What do the threads do? Apr 8, 2013 at 15:15
  • If you give us some details of what the application does, we can probably help. Is timing critical? Does the app need robust communications etc?
    – Jamie
    Apr 8, 2013 at 15:17
  • 1
    I have updated my question with some more information. Timing is critical - when a client sends a command (done in chat with a specific string), he/she expects a response immediately. Apr 8, 2013 at 18:27
  • How immediate is 'immediate'? Within X milliseconds, within X seconds, without disturbing delay? What happens if the response is not 'immediate'? Apr 9, 2013 at 8:19
  • Immediately is within a tenth of a second. If the response is not immediate, the client will be sitting there waiting uncomfortably for the server's response to their command, possibly even attempting it again (which should be accounted for, though). Apr 9, 2013 at 17:28

1 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.

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.