Is threading the best way to handle 40 Clients at

Question

I am working on a UDP server/client application.

I want my server to be able to handle 40 clients at a time. I have thought of creating 40 threads at server side, each thread handling one client. Clients are distinguished on the basis of IP addresses and there is one thread for each unique IP address.

Whenever a client sends some data to a server, the main thread extracts the IP address of the client and decides which thread will process this specific client. Is there a better way to achieve this functionality?

Answer 1

Take a look at this project, I think it is very helpful to start with: http://www.codeproject.com/Articles/16935/A-Chat-Application-Using-Asynchronous-UDP-sockets

With IPAddress.Any, we specify that the server should accept client requests coming on any interface. To use any particular interface, we can use IPAddress.Parse (“192.168.1.1”) instead of IPAddress.Any. The Bind function then bounds the serverSocket to this IP address. The epSender identifies the clients from where the data is coming.

With BeginReceiveFrom, we start receiving the data that will be sent by the client. Note that we pass epSender as the last parameter of BeginReceiveFrom, the AsyncCallback OnReceive gets this object via the AsyncState property of IAsyncResult, and it then processes the client requests (login, logout, and send message to the users). Please see the code attached to understand the implementation of OnReceive.

Answer 2

There are different approaches for scale able server application, one thread per client seems good if no of clients are not many, another most efficient approach to accomplish this task is to use thread pool. These threads are work as task base when ever you have any new task assign this task to free worker thread.

Answer 3

A better way would be to use the Proactor pattern (take a look at Boost.Asio library), instead of creating thread per client. With such an approach your application would have much better scalability and performace (especially on platforms that have native async i/o)

Besides, with this technique the threading would be de-coupled from the concurrency, meaning that you don't necessarily have to mess with multi-threading with all its complications.