Basically, you need to create two threads on server side: one listening to new connections, another one communicating with all the clients.
You need to support a list/queue of all clients and talk to them in a round-robin order. What exactly you send and receive depends on your application-level protocol. As you need to lock out the access to the list of clients from the two threads. Use Mutex (Critical Section on Windows) or, better yet, a multiple-readers, single-writer lock.
When a client is disconnected, you need to catch an exception and schedule the client's remote socket for removal. To make it possible, you need to keep each communication cycle in try-catch block and repeat communication in cycle after the exception is handled. You can handle the situations when, for example, a client computer looses power or is shut down be any reason. You cannot handle the situation with disconnected cable. For this purpose, a timeout can work. This is my opinion about "graceful" disconnection: it is redundant. As non-graceful disconnection is always possible and should be properly handles anyway, there is no sense in bothering about graceful disconnection protocols.
See also my past answers:
Exception handling in C++:
Unhandled Exception : Access Violation[
^];
Networking with multiple clients (the answer is about .NET, but many ideas are similar):
Multple clients from same port Number[
^].
Worst thing you could do is dedicating a separate thread to each client. Actually, this is a well-known architectural mistake. It makes the system very unstable, as nobody knows how many clients will try to connect during run-time. Number of threads should be predictable and better be constant.
—SA