I'm not exactly sure what your question is asking, but it sounds like you are wrestling with the fact that you need a loop to listen for client connections with select on your server but you also need to do useful work. Likewise, in your client, you might need to listen for user input but at the same time wait for responses from the server.
I don't know what language you are using, but I've done this in PHP which puts a thin wrapper around the socket-related system calls so they are pretty similar. You generally need to decide whether to make a select() call blocking or not. if it's not blocking, you might be spinning in your main loop, repeatedly calling select() with no result and yet still chewing up lots of CPU time.
You might decide on a timeout where select() blocks for 100 milliseconds or sobefore deciding that there's no data and continuing to execute other code. This tends to undermine the performance of your application because there might be things you should be going while your app is sleeping.
If that's what your question is about, you might want to check into making your application multi-threaded (or multiprocessing). This concept would apply to both server and client. You can keep your main thread working away on request and delegate I/O to a separate thread and let the operating system take care of all the scheduling. The I/O thread will queue up all the I/O requests and the main thread will dutifully service them, handing them back to the I/O thread when they are complete. Sadly, I am still looking into threading myself so I can't be of much further assistance. It can get a bit hairy when you deal with multithreading or multiprocessing because you have to watch out for things like
race conditions,
deadlock, and a host of other concurrency-related problems.
handling incoming messages