Hello

I'm stumped. I'm new to sockets and I'm trying to write a server program that will accept connections & data from clients while at the same time send data to them when I call a function at any given time from another program.

The problem is that when you select() to watch for incoming connections, it pauses your process so you can't do anything else. I don't want to make it time out because this will create a load on the CPU.

Do you fork() off and pass a copy of the socket to the fork and write to that??

Thanks in advance
Daryl

You can do that. You can create a child process for each connected socket and make the core program just select() for new connections.

But you can set the timeout value for select() to 0 and it won't pause at all. It will just quickly check to see if there are any clients waiting to connect, update the fd_sets, and return.

I still don't quite get it.
I know I don't want the select() command to time out because that would just create an unneccessary load on the server, going round and round in the while (true) loop.

But then I'm stumped. Because then the main core is sleeping and even if you do have active processes that are handling the new connections, how do you communicate with those processes at a later stage, because the core is still sleeping....

Ah. Thank goodness its Friday.

What kind of communications do you require, and why do you think that you need to go through your "core" code in order to talk with tasks running in parallel? I suggest that you design your algorithms to take advantage of multi-processing. In that type of design, each task runs as an independent entity or object. Each object is responsible for its own data I/O and need to synchronize resource usage when overlapping tasks vie for the same resource.

An example: Your "core" thread/task does the select and wakes up to accept a connection request from one of your client programs. Once the "core" accepts the connection, it spawns/forks/etc a sub-task that is solely responsible for providing support to the client it is connected with. The main "core" is then allowed to loop back to the select statement and wait for more connections while the sub-tasks are allowed to serve their clients. Depending on what your sub-tasks need to perform, they may even spawn/fork/etc sub-tasks of their own to handle finer granularity actions, etc, etc. Each sub-task needs to run to completion of its assigned functionality and then terminate.

BTW: I pre-apologize if I sound like I am trying to lecture you. There are multiple techniques for accomplishing what you are asking and I am simply trying to have you think in terms of true multi-tasking (in 30 seconds or less) Please take a look at pthreads, if you are not currently familiar with them, as they make multi-threaded programming very easy.

If you don't want to fork at all, you can still usually solve the problem; queue up any data that needs to be written to each client, and wait in a select() loop for *anything* to become readable or for one of the clients to whom you are waiting to write to become writeable. Do the reading and writing and then block on select() again. You get to figure out how to arrange all the data structures you'll need. The solution hinges on the fact that select() can at once wait for readers and writers.

This is called multiplexing.

If your "core" process needs to talk to child processes while it's blocked on select, you can have it talk to children via pipes, and put those in the select() fd_set. Alternatively, you could have the children signal the "core"; that will wake it up from the select() with an EINTR error. Be very careful about race conditions if you use signals though.