Client Vs Server -Multiclient Networking

I created Server-Client Programs for LAN and they are working,but the problem is that the server accepts only one client at a time.If more than one clients approaches then it proceeds with only first one and do not responds to other.Is there any way out of this problem...
Last edited on
you need a thread per client
You can either make a thread for every client and have each thread block until it receives data from the client (the best way), or you can do it all in one thread -- Keep an array of all clients connected, and poll each client for data every loop. Less efficient, CPU hog, but it can be done. I'll look around to see if i can find some old code of mine where I did something similar and straight winsock (which is brutal as hell.)
@Thumper,I tried to do it all in a single Thread,but my problem is that when the server is busy with first client, it is not listening for the second one and hence I cannot make the array of incoming clients.Is there a way to make the program to listen as well as to perform task 4 1st client at a time.
If you're implementing a client-per-thread mechanism, you need to create a new thread and pass it the socket as soon as accept() returns a connection. The main thread then just accepts new connections and starts a new thread in a loop.

If you're implementing a client-per-process model, it's the same as above. You'd fork() instead of creating a thread, and you'd close the socket in the main add.

You can also multiplex. Use select() to wait for socket availability. Then when one is available, you process it and loop back to select(). The server socket must add the new client to the list of sockets. The client handler can read/write on the socket and removes its socket from the list when done.
but XP do not support fork(). and if I use multiplex as u told me,then, what will happen if the request comes when server is busy with a client.I think the request will be dropped.
fork() is a *nix system call. I believe on windows it's just CreateThread. You'll need to include windows.h
@OP
There are ways to avoid having the system being clogged up by one client, such as limiting the amount of data read at a time. I remember reading up to 500 characters for each client, then checking to see if a client connects, and repeat. It's a really messy way to do it, though.
You should look into multi threading.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx

As kbw said, as soon as accept() returns a connection, start a new thread and pass the socket too it, then continue to listen for more connections.
I linked the MSDN documentation of CreateThread above.
limiting the character wont do my job cuz I'm designing a virtual bank system where the person can take its own time to check his/her account and doing other jobs...well thank u all for the great help....
Last edited on
Haha, I've just written a small server / multi-client programming using Windows threading and WinSock.

It's all good when it works. Absolutely nightmare when it doesn't. Nothing more fun than chasing a multithreaded networking bug.
Last edited on
Protip: just use a library, please...save yourself the headcahe. Obviously for "fun" or "experience" you can try to do it yourself, but for the love of coding, just use something that does it already. Personally I use liblacewing for its (highly efficient) OO design, but you can use a lower-level library if you feel more comfortable with it (protip2: stick to your comfort zone for actual work, only leave it for recreational purposes)
Agree with L B. You could look into Boost libraries also. Boost is pretty good.
I looked at lacewing some time ago, but haven't used it in anything serious. It looks pretty good, and uses the most efficent methods on the platforms it supports (Windows, Linux, FreeBSD). If it works, it'll work very efficiently.

boost asio must have moved on from when I last looked at it (many years ago) because everyone're recomending it.

I've worked on high-speed critical long running networked systems that use sockets directly. Sockets are good enough, despite the plethora of improved solutions around.
Topic archived. No new replies allowed.