CODEWITHSUNDEEP
c#.netsockets
Alex
Alex

Reputation: 11147

to multi-thread or not on a scalable client-server application

A few years ago I developed a server app (C#, .NET 4.0) that has multiple clients which connect to it. The way I did this was to create a thread for every single connection, and maintain a list of these connections. When I tested the app, it handled connections for 50 clients across my country. and it ran OK (from what I saw).

My questions are these:

  1. For a scalable solution, is multi-threading a viable solution for handling multiple connections to various clients, or should I handle all connections on the same thread?
  2. Are there limits to the number of threads and threading in general under .NET?
  3. Are there downsides for using threads in .NET?

I know this is sort of vague, but I have forgotten some more intricate details since I developed the project some time ago. I am interested in developing a scalable solution for a server app in .NET and would like to know from the start if there where areas of improvements in my approach before.

UPDATE 1

I didn't use a thread polling instantiated. I actually created a Thread for a method (lets call it method threadLife).

in threadLife i had a while(true) statement in which i awaited for messages from the client. In the while i would wait for the client so send a message (so the while was blocked until i received a message)

In my application, the connections were quite stable (i.e. the clients would stay connected for long periods of time) so the connections where kept alive till the client disconnected (didn't close the connection after every message, i would recieve very frequent messages that let me know the clients state)

Upvotes: 3

Views: 1122

Answers (3)

Larry
Larry

Reputation: 18041

One thread per connection would not be scalable.

I would suggest that a thread could handle a set of connected clients. If the amount of connected clients increases, the server application should be able to add as many thread needed to handle the ramp up. Then other server instances if things continues to grow.

Instead of having threads that do everything (as application instances are doing), have some dedicated threads that processes the same task separately and shares in-memory data a synchronized way.

This is more and less the way IIS is working. The number of working process, the amount of threads and thread pools is manageable through the control panel.

I remember the OpenSim project (a virtual world platform) ran this way : one thread per connected client. It has been refactored since the way explained above.

Apparently you are well started already with multithreading. Maybe this free ebook will help you to dig further.

When I started multithread, I had some trouble at first to understand it means several execution of the same code at the same time, primarily in the same instance.

Upvotes: 0

Dmitry Ledentsov
Dmitry Ledentsov

Reputation: 3660

one can use message queues, load balancing, dispatching, etc, etc. There is no single answer. Some solutions fit some problems well, some not.

Good places to start can be:

Upvotes: 0

Stephen Cleary
Stephen Cleary

Reputation: 457047

Thread-per-connection is not a scalable solution.

To scale well, you should use asynchronous socket methods exclusively. The question is whether to multiplex them all on a single thread or to use the thread pool. The thread pool would scale better than multiplexing, but it introduces multithreading complexities.

A lot of devs attempt to learn socket programming and multithreading at the same time, which is just too much.

Upvotes: 2

Related Questions