Sockets and Client-Server Communication

Imagine a server that handles one connection at a time. It finishes each client completely before it even looks at the next incoming request. If the first client is slow to read its data, every other client waits in line behind it. The server is correct, but it is only as fast as its slowest client.

A threaded server is a different design. Whenever a connection request arrives, the server gives that connection to a separate thread and immediately returns to listening for more requests. The part of the program that waits for new connections stays free to do its job, while each connection is handled elsewhere. This article follows one concrete program, DateServerWithThreads, to show how that handoff is written and where to look when something goes wrong.

Before reading any explanation, look at the core of the program. The program has two parts that matter most. The main loop is the part that runs forever, waiting for clients. The ConnectionHandler class is the part that does the actual work for one client. Your first task when reading a threaded server is to find these two pieces and separate them in your mind.

Within that code, two statements matter. One creates the handler object, and the other starts it. Also notice which method contains the logic that talks to the client. The source identifies that method as run(), and the rest of this article traces how control moves between the main loop and run().

Walk through a single connection step by step. A client attempts to connect to the listening port. The accept() call in the main thread returns a Socket that represents that one client. The main thread wraps that socket in a new ConnectionHandler object and calls start() on it. Calling start() is what causes the handler's run() method to execute in its own thread. Once start() has returned, the main thread has no further involvement with that client. It simply loops back to accept() and waits for the next one.

The figure shows the handoff as a path of data. The socket is produced by the main thread, passed to the handler object, and then used inside run() to send the reply. The main thread appears on this path only up to the point where the handler is started. After that, the connection's data path runs through the handler thread, while the main thread's path returns to waiting for the next client.

The run() method takes over the job that a single-connection program would do directly. Its body is copied from the original single-threaded date program, which is why the handler looks so familiar. Everything that talks to one client lives here, and it runs in the connection's own thread.

Notice that the socket is the thread's resource. The main thread created it and handed it over, and run() is the code that uses it to send the reply and then closes it. Every other step in the list is a task performed on behalf of that one client, so the whole list belongs to a single connection thread.

The main thread must stay free to call accept(). If it became stuck while setting up one connection, the server would be unable to accept new clients promptly. The source explains the reason in a specific way. Creating the handler object and starting it takes very little time. The constructor of the connection thread only stores the socket it was given. Constructors run in the main thread, so any slow work placed in a constructor would delay the main loop.

This is why the program keeps all the reading and writing inside run(). That method runs in the new thread, so slow client-facing work happens off the main thread. The main thread's only jobs during a handoff are to create the handler, store the socket, and call start().

The sequence shows the timing. The main thread hands off the first connection and returns to accept() without waiting for the handler to finish. Because it is already listening again, it can receive the second client while the first handler is still working. The second client is then served through its own handler, so neither client waits in line behind the other.

When a connection fails in this design, you do not look at the main loop first. The most useful places to look are the flush and close path inside run(), and the error message printed by the catch block. The flush and close steps are where the bytes actually leave the handler, and the catch block is where the failure is reported. Because run() is the code that talks to the client, a failure during that talk is most likely to surface in the connection thread.