CODEWITHSUNDEEP
c++multithreadingudp
Nostalgic
Nostalgic

Reputation: 310

Handling multiple clients simultaneously in C++ UDP server

I have developed a C++ UDP based server application and I am in the process of implementing code to handle multiple clients simultaneously . I have the following understanding regarding how to handle multiple clients and want to fill in the knowledge gaps

My step wise understanding is as mentioned below

  1. UDP server listens at a specific port(say xxxx)
  2. The server has a message queue .It can be array or linked list or Queue or anything for that matter
  3. As soon as a request arrives at the port xxxx, its placed in the message queue
  4. After putting it in the message queue a new thread(let us call it worked thread) is spawned and it picks up the queued message and the same is removed from the message queue
  5. The worked thread knows about the clients IP:port from the message header
  6. The worker thread processes the request and sends the response to the clients IP:port
  7. The clients gets the response and the worker thread terminates.

Steps 3 to 7 take care of multiple client being handled simultaneously. Is my understanding sufficient ? Where do I need improvement? Thanks in advance

Upvotes: 0

Views: 412

Answers (1)

ravenspoint
ravenspoint

Reputation: 20457

The clients gets the response and the worker thread terminates.

The worker thread should terminate when it completes processing. There is no practical way for it to wait for an acknowledgement from the client.

The worker thread processes the request and sends the response to the clients IP:port

I think it will be better to place the response on a queue. The main server thread can check the queue and send any responses found there. This prevents race conditions when two worker threads overlap in their attempts to send responses.

The server has a message queue .It can be array or linked list or Queue or anything for that matter

It pretty much has to be a queue. The interesting question is what queue priority. Initially FIFO would do. If your server becomes overloaded, then you need to consider alternatives. Perhaps it would be good to estimate the processing time required, and do the fast ones first. Or perhaps different clients deserve different priorities.

After putting it in the message queue a new thread(let us call it worked thread) is spawned

This is fine initially. However, you will want to do some time profiling and determine if a thread pool would be advantageous.

Deeper Discussion of threading issues

The job processing must be done in a separate worker thread, so that a long job will not block the server from accepting connections from other clients. However, you should consider carefully whether or not you want to use multiple worker threads. Since you are placing the job requests on a queue, a single worker thread can be used to process them one by one.

PRO single thread

  • Simpler, more reliable code. The processing code must be thread safe for context switches back to the main thread. However, there will not be any context switches between job processing code. This makes it easier to design and debug the processing code. For example, if the jobs are updating a database, then you do not require any extra code to ensure the database is always consistent - just that consistency is guaranteed at the end of each job process.

  • Faster response for short jobs. If there are many short jobs submitted at the same time, your CPU can spend more cycles switching between jobs than actually doing useful processing.

CON single thread

  • A big job will block other jobs until it completes.

Upvotes: 2

Related Questions