HTML and CSS Reference
In-Depth Information
Server sent events
The first problem we will deal with is the server sending unsolicited notifications to the cli-
ent. This is a very common problem in web applications, for instance, consider the Gmail
application. This needs to alert users to the fact that a new email has been received.
It is not possible for the server to open a connection to a client to send it notifications. In
order to achieve this, the client would need to act as a server, and open a port for the server
to connect to. This would open up the client to major security vulnerabilities, and would be
prohibited by firewalls.
Instead, the functionality can be achieved with polling. In the Gmail scenario, the client
could send a message to the server every few seconds to ask if any new emails have arrived.
There are two main problems with polling:
1. It is very wasteful on network resources, since most of the time there will be no new
emails. If we envisage a user receiving 2 emails an hour, polling ever 5 seconds would mean
359 requests informing the user there are no new emails for each 1 informing them there is
a new email.
2. It involves latency, since it will take on average half the polling interval to notify the user
of a new email. For instance, if we increased the polling period to every 10 seconds, it will
take on average 5 seconds to inform the user a new email has arrived (excluding network
latency).
Software engineers have attempted to solve these problems using a technique (or rather a set
of techniques) referred to as COMET.
COMET is usually implemented by having the client poll the server with a standard HTTP
request. If the server has a notification for the client it will return it immediately. If the serv-
er does not have a notification for the client it will block the connection on the server until a
notification is available, at which point an HTTP response will be returned. This technique
is also sometimes referred to as “long-polling”.
There are problems with this approach that make it unattractive for most sites:
1. Due to the way most web servers implement connection management, while the request is
blocked on the server it is represented by an open operating system thread. This significantly
reduces the number of clients that can be supported by a single server, since there are limits
to the number of active threads.
2. Many clients sit behind firewalls, and firewalls are often suspicious of connections that
remain open for significant periods of time. In order to circumvent this COMET implement-
ations usually only leave the request open for a limited period (perhaps 20 seconds). After
