Click here to Skip to main content
13,052,956 members (62,792 online)
Rate this:
Please Sign up or sign in to vote.
I am working on udp server/client application. I want my single server to handle 40 clients at a time. For this, I want to create 40 dedicated threads, each dedicated for one single client. Since there are 40 threads one for each client, I want to create 40 dedicated sockets as well. But the problem that I don't know what will be the 40 IP addresses to which I shall bind() my sockets. (since as far as I now, I have to bind() to my Server\s IP address.) Normally I bind() to "INADDR_ANY" when there is only single socket. But what should be the IP addresses at which I should bind() each of my 40 sockets? Please help me. Any comment/ help is appreciated.
Posted 12-Apr-13 0:43am
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

You're trying this the wrong way round. The server should have one socket (IP-adress and port) on which it accepts connections and then it will spawn a separate thread for each client that connects. If you were to do it your way you'd need either 40 IP adresses and listening on one designated port or use one IP adress listening on 40 different ports. The former is a waste of IP adress space and the latter a pain in the arse configuration management wise as each client would have to be configured with a different port to connect to the server.
Since I cannot imagine this being a requirement I suggest you look at the ample samples available on the internet to see how a server using sockets is implemented and go by that route.

Socket server sample:[^]

Threading C Windows:
Multithreading with C and Win32 [^]


— Manfred
ayesha hassan 12-Apr-13 7:16am
Thank you so much. Your answer is really helpful, but the problem is that I am working on UDP and UDP does not listen(). listen() is avialable only in TCP as far as I know :(
Manfred R. Bihy 12-Apr-13 7:36am
You can still do something analogous. Have the server receiving UDP datapackets as they come in. UDP can only be used for rather smallish data sizes so length should not be any concern. Once a data packet is received you spawn your thread to do the processing and sending of the response. Since UDP is connectionless the client will have to do the checking if a response is received and eventually retry after a certain timeout while the server will have to make sure it is not processing duplicate requests. The answer of the server may have been lost on the way so that the client might be prompted to repeat the previous request.
Going connectionless puts the responsibilities into the hands of the implementor. :)
Espen Harlinn 12-Apr-13 7:46am
Good reply, Manfred :-D
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

If you want a multi client server (who wouldn't?) you shouldn't need to listen on 40 different sockets, but rather a single socket. On recieving a connection, spawn a thread to handle the connection... or a process if you want to go old school :)

In fact here's a good example Beginning Winsock Programming - Multithreaded TCP server with client[^]
ayesha hassan 12-Apr-13 7:10am
If there is only a single thread and all of the 40 clients send data simultaneously on this single socket, there are chances that data of each client may get dropped.
Due to this reason, I shifted towards creating dedicated sockets for each client.
Manfred R. Bihy 12-Apr-13 7:14am
They can't send data simultaneously as they have to connect first. After the connection is made there already exists a separate thread for each client, so no worries. The backlog for simultaneous connections is something like 5, but that really only matters if way more than 40 clients would try to connect at the same time and if the code spawning a new thread would do some lengthy calculations (which it shouldn't BTW).
jsolutions_uk 12-Apr-13 7:20am
You state that you are using UDP? UDP does not provide a guarantee of deliver, so if you are worried about that, perhaps use TCP which provides a greater level of reliability. 40 clients sending data simultaneously should not be a problem as IP packets should effectively be queued by the server OS, if I understand correctly.
Manfred R. Bihy 12-Apr-13 7:10am
Exactly! 5+
ayesha hassan 12-Apr-13 7:18am
but there is no connect() or listen() in UDP :(
ayesha hassan 12-Apr-13 7:24am
@jsolutions_uk : Thanks for sharing about receive queue. But upto what limit will the data be queued in such a buffer? There must be a limit after which the queue is full and moreincoming data will be discarded, if I'm not worng in understanding the concept.
jsolutions_uk 12-Apr-13 7:27am
I believe there is a limit, there are also some other parameters relating to recieving packets. I suspect they are OS dependent, probably configurable.... but much more than that I would be in google territory :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web01 | 2.8.170713.1 | Last Updated 12 Apr 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100