Question

I’m doing an application in C#, with a server and some clients (not more than 60), and I would like to be able to deal with each client independently. The communication between server and client is simple but I have to wait for some ack’s and I don’t want to block any query.

So far, I’ve done two versions of the server side, one it’s based on this:

http://aviadezra.blogspot.com.es/2008/07/code-sample-net-sockets-multiple.html

and in the other one, I basically create a new thread for each client. Both versions work fine…but I would like to know pros and cons of the two methods.

Any programming pattern to follow in this sort of situation?

Answer 1

To answer your question it’s both. You have threads and classes running in those threads. Whether you use WCF, async, sockets, or whatever, you will be running some object in a thread (or shuffled around a threadpool like with async). With WCF you can configure the concurrency model, and if you have to wait for ack’s or other acknowledgement you’d be best to set it to multiple threads so you don’t block other requests.

In the example you linked to the author is using AsyncCallback as the mechanism for telling you that a socket has data. But, from the MSDN you can see:

Use an AsyncCallback delegate to process the results of an asynchronous operation in a separate thread

So it’s really no different for small scale apps. Using async like this can help you avoid allocating stack space for each thread, if you were to do a large application this would matter. But for a small app I think it just adds complexity. C# 4.5+ and F# do a cleaner job with async, so if you can use something like that then maybe go for it.

Doing it the way you have, you have a single thread that is responsible for socket management. It’ll sit and accept new connections. When it gets a request it hands that socket to a new dedicated thread that will then sit on that socket and read from it. This thread is your client connection. I like to encapsulate the socket client reading into a base class that can do the low level io required and then act as a router for requests. I.e. when I get request XYZ I’ll do request ABC. You can even have it dispatch events and subscribe to those events elsewhere (like in the async example). Now you’ve decoupled your client logic from your socket reading logic.

If you do things with WCF you don’t need sockets and all that extra handling, but you should still be aware that calls are multi-threaded and properly synchronize your application when applicable.

For 60 clients I think you should choose whatever works best for you. WCF is easy to set up and easy to work with, I’d use that, but sockets are fine too. If you are concerned about the number of threads running, don’t be. While it’s bad to have too many threads running, most of your threads will actually be blocked while they are waiting on IO. Threads that are in a wait state aren’t scheduled by the OS and don’t really matter. Not to mention the waiting is most likely is using io completion ports under the hood so the wait overhead is pretty much negligible for a small application like yours.

In the end, I’d go with whatever is easiest to write, maintain, and extend.