Server-sent events and php - what triggers events on the server?

Question

All,

HTML5 Rocks has a nice beginner tutorial on Server-sent Events (SSE):

http://www.html5rocks.com/en/tutorials/eventsource/basics/

But, I don't understand an important concept - what triggers the event on the server that causes a message to be sent?

In other words - in the HTML5 example - the server simply sends a timestamp once:

<?php header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); // recommended to prevent caching of event data. function sendMsg($id, $msg) {   echo "id: $id" . PHP_EOL;   echo "data: $msg" . PHP_EOL;   echo PHP_EOL;   ob_flush();   flush(); } $serverTime = time(); sendMsg($serverTime, 'server time: ' . date("h:i:s", time())); 

If I were building a practical example - e.g., a Facebook-style "wall" or a stock-ticker, in which the server would "push" a new message to the client every time some piece of data changes, how does that work?

In other words... Does the PHP script have a loop that runs continuously, checking for a change in the data, then sending a message every time it finds one? If so - how do you know when to end that process?

Or - does the PHP script simply send the message, then end (as appears to be the case in the HTML5Rocks example)? If so - how do you get continuous updates? Is the browser simply polling the PHP page at regular intervals? If so - how is that a "server-sent event"? How is this different from writing a setInterval function in JavaScript that uses AJAX to call a PHP page at a regular interval?

Sorry - this is probably an incredibly naive question. But none of the examples I've been able to find make this clear.

[UPDATE]

I think my question was poorly worded, so here's some clarification.

Let's say I have a web page that should display the most recent price of Apple's stock.

When the user first opens the page, the page creates an EventSource with the URL of my "stream."

var source = new EventSource('stream.php'); 

My question is this - how should "stream.php" work?

Like this? (pseudo-code):

<?php     header('Content-Type: text/event-stream');     header('Cache-Control: no-cache'); // recommended to prevent caching of event data.     function sendMsg($msg) {         echo "data: $msg" . PHP_EOL;         echo PHP_EOL;         flush();     }      while (some condition) {         // check whether Apple's stock price has changed         // e.g., by querying a database, or calling a web service         // if it HAS changed, sendMsg with new price to client         // otherwise, do nothing (until next loop)         sleep (n) // wait n seconds until checking again     } ?> 

In other words - does "stream.php" stay open as long as the client is "connected" to it?

If so - does that mean that you have as many threads running stream.php as you have concurrent users? If so - is that remotely feasible, or an appropriate way to build an application? And how do you know when you can END an instance of stream.php?

My naive impression is that, if this is the case, PHP isn't a suitable technology for this kind of server. But all of the demos I've seen so far imply that PHP is just fine for this, which is why I'm so confused...

Answer 1

Server-sent events are for realtime update from the server-side to the client-side. In the first example, the connection from the server isn't kept and the client tries to connect again every 3 seconds and makes server-sent events no difference to ajax polling.

So, to make the connection persist, you need to wrap your code in a loop and check for updates constantly.

PHP is thread-based and more connected users will make the server run out of resources. This can be solved by controlling the script execution time and end the script when it exceed an amount of time (i.e. 10mins). The EventSource API will automatically connect again so the delay is in a acceptable range.

Also, check out my PHP library for Server-sent events, you can understand more about how to do server-sent events in PHP and make it easier to code.

Answer 2

"...does "stream.php" stay open as long as the client is "connected" to it?"

Yes, and your pseudo-code is a reasonable approach.

"And how do you know when you can END an instance of stream.php?"

In the most typical case, this happens when the user leaves your site. (Apache recognizes the closed socket, and kills the PHP instance.) The main time you might close the socket from the server-side is if you know there is going to be no data for a while; the last message you send the client is to tell them to come back at a certain time. E.g. in your stock-streaming case, you could close the connection at 8pm, and tell clients to come back in 8 hours (assuming NASDAQ is open for quotes from 4am to 8pm). Friday evening you tell them to come back Monday morning. (I have an upcoming book on SSE, and dedicate a couple of sections on this subject.)

"...if this is the case, PHP isn't a suitable technology for this kind of server. But all of the demos I've seen so far imply that PHP is just fine for this, which is why I'm so confused..."

Well, people argue that PHP isn't a suitable technology for normal web sites, and they are right: you could do it with far less memory and CPU cycles if you replaced your whole LAMP stack with C++. However, despite this, PHP powers most of the sites out there just fine. It is a very productive language for web work, due to a combination of a familiar C-like syntax and so many libraries, and a comforting one for managers as plenty of PHP programmers to hire, plenty of books and other resources, and some large use-cases (e.g. Facebook and Wikipedia). Those are basically the same reasons you might choose PHP as your streaming technology.

The typical setup is not going to be one connection to NASDAQ per PHP-instance. Instead you are going to have another process with a single connection to the NASDAQ, or perhaps a single connection from each machine in your cluster to the NASDAQ. That then pushes the prices into either a SQL/NoSQL server, or into shared memory. Then PHP just polls that shared memory (or database), and pushes the data out. Or, have a data-gathering server, and each PHP instance opens a socket connection to that server. The data-gathering server pushes out updates to each of its PHP clients, as it receives them, and they in turn push out that data to their client.

The main scalability issue with using Apache+PHP for streaming is the memory for each Apache process. When you reach the memory limit of the hardware, make the business decision to add another machine to the cluster, or cut Apache out of the loop, and write a dedicated HTTP server. The latter can be done in PHP so all your existing knowledge and code can be re-used, or you can rewrite the whole application in another language. The pure developer in me would write a dedicated, streamlined HTTP server in C++. The manager in me would add another box.