Client and Server Applications
A chat protocol
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.