Home Closet HTML5 and server events (updated)

HTML5 and server events (updated)

by admin

In addition to the already the bidirectional communication channel known as WebSocket , HTML5 also includes a server-push Server-Sent Events technology (SSE). While WebSocket is widely discussed, with many implementations of WebSocket servers available, the technology is already almost fully available in the Google Chrome browser, SSE, for the most part, remains in the shadows.
We are used to HTTP being limited to the request-response model, which means the client sends an HTTP request and waits for an HTTP response. Essentially, the server can’t tell the client anything until the client "asks" it. Even for something as trivial as a user’s online status, we have to resort to various tricks. You know – the tireless ingenuity of enthusiasts has generated a lot of such solutions, for which there is a collective name Comet. However, to quote the experts : "Comet is nothing more than a giant hack." It looks like HTML 5 is meant to enrich us with native features, replacing the now-used Comet. In the case of SSE, HTML5 provides an API to open a special HTTP connection to accept server-side notifications. Look at how simple the interface is :
var source = new EventSource('updates.php');
source.onmessage = function (event) {

On the server side, the script sends messages in the following format (MIME-type text/event-stream is expected):
data: Lorem ipsum dolor sit amet
data: consectetur adipiscing elit.
data: Vestibulum rutrum nisi in diam dapibus eget tempor mauris sollicitudin

What’s more, we don’t even need an infinite loop in the script. Once the connection is opened, it will be as if the script is being asked to execute automatically.
header("Content-Type: text/event-stream\n\n");
echo 'data: ' . time() . "\n";

So how does this work? The client opens the event stream by creating an EventSource that takes the address of the event source as a parameter. The onmessage event handler will be called every time new data is received from the source. As you can see, having AJAX we can asynchronously access from the client to the server and vice versa, via SEE access from the server to the client, again asynchronously.
Among other things, HTML5 describes such technology as WebWorker It allows you to run scripts in the background and independently of each other. So if you happen to exceed the permissible limit of open connections in the browser due to multiple open EventSource, no problem – it’s easily solved. In each case, you’re referring to the same WebWorker, which serves the EventSource connection.
So, is all of this really available for use? SSEs are implemented in the developer version of Google Chrome 6 , in Safari 5.0 and in Opera 9.x. The latter implementation, however, is not exactly what I showed in the examples above. Under Opera, you have to create a special element in the HTML, on which you will then "hang" the listener.
<event-source src="events.php" />

Moreover, events addressed to different listeners can come from the server side
addEventListener("server-time", function (event) {
}, false);

The controller looks like this :
header("Content-Type: application/x-dom-event-stream");
echo "Event: server-time\n";
echo "data: " . time() . "\n";

Next, I did example with which you can see how SSEs work in your browser This doesn’t use the console, so the messages coming from the server don’t have to look anywhere, you’ll see them on the page.

You may also like