The main purpose of our protocol update will be to specify that clients must be able to accept all messages that are sent to them, whenever they are sent.

In theory, one solution for this would be for our client itself to set up a listening socket, so that the server can connect to it whenever it has a new message to deliver. In the real world, this solution will rarely be applicable. Clients are almost always protected by some kind of firewall, which prevents any new inbound connections from connecting to the client. In order for our server to make a connection to a port on our client, we would need to ensure that any intervening firewalls are configured to allow our server to connect. This requirement would make our software much less appealing to most users since there are already chat solutions which don't require this.

If we can't assume that the server can connect to the client, then we need to meet our requirement by only using the client-initiated connection to the server. There are two ways in which we can do this. First, we can have our clients run in a disconnected state by default, then have them periodically connect to the server, download any waiting messages, and then disconnect again. Alternatively, we can have our clients connect to the server and then leave the connection open. They can then continuously listen on the connection and handle new messages sent by the server in one thread, while accepting user input and sending messages over the same connection in another thread.

You may recognize these scenarios as the pull and push options that are available in some e-mail clients. They are called pull and push because of how the operations appear to the client. The client either pulls data from the server, or the server pushes data to the client.

There are pros and cons to using either of the two approaches, and the decision depends on an application's needs. Pull results in a lower load on the server, but higher latency for the client in receiving messages. While this is fine for many applications, such as e-mail, in a chat server we usually expect immediate updates. While we could poll very frequently, this imposes unneeded load on the client, server, and network as the connections are repeatedly set up and torn down.

Push is better suited for a chat server. As the connection remains open continuously the amount of network traffic is limited to the initial connection setup, and the messages themselves. Also, the client gets new messages from the server almost immediately.

So, we'll use a push approach, and we will now write our chat protocol as follows: