HTML5 and server events (updated)

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

We are used to the fact that HTTP is limited to the request-response model, which means: the client sends an HTTP request and expects an HTTP response to it. In fact, the server cannot communicate anything to the client 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 spawned many such decisions, to 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 native capabilities, to replace the currently used Comet. In the case of SSE, HTML5 provides an API for opening a special HTTP connection for accepting notifications from the server. 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 (MIME type text / event-stream is expected):
data: TROLOLOLOLOLOLOLOLOLOLO
data: Lorem ipsum dolor sit amet
data: consectetur adipiscing elit.
data: Vestibulum rutrum nisi in diam dapibus eget tempor mauris sollicitudin


Moreover, we do not even need an infinite loop in the script. After opening the connection it will be as if the script is automatically requested for execution.
<?php
header("Content-Type: text/event-stream\n\n");
echo 'data: ' . time() . "\n";
?>


So how does it work? The client opens the event stream by creating an EventSource that takes in the parameter the address of the event source. The onmessage event handler will be called each time new data is received from the source. As you can see, with AJAX we can asynchronously access the server from the client and, conversely, through the SEE contact the server to the client, again asynchronously.

Among other things, HTML5 describes such a technology as WebWorker . 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 for open connections in the browser due to the many open EventSource, it does not matter - it is easily solved. In each case, you refer to the same WebWorker that serves the EventSource connection.
And what, is all of this really available for use? SSE is implemented in the developer version of Google Chrome 6 , in Safari 5.0 and in Opera 9.x. However, the latest implementation is not exactly what I showed in the examples above. Under Opera, you must create a special element in HTML, which you then “hang” on the listener.

<event-source src="events.php" />


Moreover, from the server side, events can be sent to different listeners.

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


The controller looks like this:

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


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 should not be searched anywhere, you will see them on the page.