The Qchat server is the heart of the system, connecting the clients to each other, and providing information to the web server through files. The main class used to implement the server is the undocumented NetworkServer class provided by Sun. This class is included in the Java Devloper's Kit, but is not mentioned in the standard documentation. The NetworkServer class provides an easy way to write multithreaded servers. Every connection to the server is given its own thread. This allows many connections to be handled simultaneously. The use of a new thread for every connection also simplifies the programming process. One block of code can be written that is reused for each client connection. To keep track of clients, each thread is assigned a unique number when it is started. This number is owned by the thread until it terminates. To coordinate resources and variables between threads all variables that need to be shared between threads are kept in an internal table as part of the main server thread. The table is indexed by thread number. Unlike some programming languages, where the programmer must worry about shared variables, Java handles this problem internally. This ability speeds up the programming process. A good way to examine the programming methods used in the server is to walk through a client connection. After the server is started and has initialized its variables and network port, it waits for client connections.

When a Qchat client connects to the server, the first action is the client sends the server the username and channel it is using. The client is then assigned a unique number within the Qchat server. The server then sends startup information to the client, including other users that are on the same channel and the channel list. A text message is then sent to the client to tell the user that the connection is ready. Once the startup phase is complete, the user is free to access any of the functions of the Qchat client. Text messages sent from the client are forwarded to the users that are on the same channel as the user sending the message. When the user adds a channel, the user is moved to that channel, all other clients are informed of the change, and all clients are informed about the new channel. Going to a channel is similar, however a new channel does not have to be created. Filtering a user adds the filtered user to a list contained on the server. When messages are sent from a filtered user to the current user, they are checked against the filter in the server. These messages are simply not forwarded to the current client, saving network traffic. Unfiltering removes a filtered user from the filter list. The status button sends a message to the server asking for the current status, this includes number of users, number of available connections, and the user's current channel. The clear text button is the only one that does not call the server.

All commands except text messages get a response from the server. These responses are interpreted by the client to modify its display. The server also has an internal 'display'. This 'display' is the table containing the user and channel information. Any function, such as add channel, that changes the information in this table, causes the update function to run. This function provides garbage collection functionality to the server. When the update function is called it first checks the table for empty, nonpermanent channels. Messages are then sent to the clients to remove these channels from their lists, and the empty channels are removed from the internal list. Channel update messages are also sent out containing the current number of users in each channel. Finally the current information on users and channels is written to the files used by the CGI applications. When a user leaves Qchat, the server sends messages to all other clients that the user has left, and updates its internal table.

Another important feature of Qchat is the ability to support server to server links. The method used to implement multiple servers is to have one server connect to another as a special client. This provides the ability to create a tree-like architecture. A server that is connected as a client receives all text messages, and passes any messages it receives from its clients onto the server. This allows for a very flexible server collection architecture. The messages that are passed also include user information. The user tables are maintained by every server independently, allowing one remote server to go down while local users can continue chatting. However, there is no reconnection ability once a parent server goes down without restarting the child server. The ability to provide multiple servers allows individuals to link their servers together and create a larger chat network, taking advantage of faster connection speeds for local users.

The Qchat server has been structured to take advantage of multithreading in its support of multiple users and multiple channels. Each client connection thread handles all of the requests for that client, and forwards messages to other clients based on information contained in the main server thread. Multiple threads are not created for each channel, instead the client connection thread decides where messages are to be forwarded based on the channel of the sender and receiver. This is an efficient way to handle multiple users and channels, that should be scaleable to a larger chat system.