HTML5 and server events (updated)

In addition to the bi-directional communication channel I already mentioned, known as WebSocket , HTML5 also includes Server-Sent Events (SSE) server push technology . While WebSocket is widely discussed, many implementations of WebSocket servers are available, the technology is already almost fully available in the Google Chrome browser, SSE, for the most part they remain in the shade.

We are used to the fact that HTTP is limited by the request-response model, which means: the client sends an HTTP request and expects an HTTP response to it. In fact, the server cannot tell the client anything until the client “asks for it”. Even for such a trivial thing as online user status, we need to resort to various tricks. Well, you know - the restless ingenuity of enthusiasts has generated many such decisions, for which there is a collective name Comet. However, quoting experts: "Comet is nothing more than a giant hack . " It seems that HTML 5 is intended to enrich us with the native capabilities that are replacing the currently used Comet. In the SSE case, HTML5 provides an API for opening a special HTTP connection for receiving server-side notifications. Take a look at what a simple interface:

var source = new EventSource('updates.php');
source.onmessage = function (event) {
alert(event.data);
};


On the server side, the script sends messages in the following format (expected MIME type text / event-stream): Moreover, we do not even need an infinite loop in the script. After opening the connection, it will be as if the script is being requested for execution automatically. So how does it work? The client opens the stream of events through the creation of an EventSource that takes the address of the event source in the parameter. The onmessage event handler will be called every time new data arrives from the source. As you can see, with AJAX we can access the server asynchronously from the client and, conversely, access the client from the server via SEE, again asynchronously. Among other things, HTML5 describes a technology such as WebWorker
data: TROLOLOLOLOLOLOLOLOLOLO
data: Lorem ipsum dolor sit amet
data: consectetur adipiscing elit.
data: Vestibulum rutrum nisi in diam dapibus eget tempor mauris sollicitudin



header("Content-Type: text/event-stream\n\n");
echo 'data: ' . time() . "\n";
?>




. It allows you to run scripts for execution in the background and independently of each other. So, if you happen to exceed the allowable limit on open connections in the browser due to the many open EventSource, it does not matter - this is easily solved. In each case, you refer to the same WebWorker that serves the EventSource connection.
And what, is all this really available for use? SSEs are implemented in the development version of Google Chrome 6 , in Safari 5.0 and in Opera 9.x. However, the last implementation is not quite what I showed in the examples above. Under the Opera, you must create a special element in HTML, which then "hang" the listener (listener).




Moreover, events addressed to different listeners can come from the server side

document.getElementsByTagName("event-source")[0]
.addEventListener("server-time", function (event) {
alert(event.data);
}, false);


The controller looks something like this: Next, I made an example with which you can see how SSE works in your browser . So the console is not used, so the messages coming from the server do not need to be looked for anywhere, you will see them on the page.

header("Content-Type: application/x-dom-event-stream");
echo "Event: server-time\n";
echo "data: " . time() . "\n";
flush();
?>