Server-side interrupt-driven client refresh.

[BramVandenbon]

Scenario
I'm developing a 2 player turnbased PHP game.

Each turn can take 1 second to 10 minutes.
When player1 has made his move, then the webserver will store his move in a database. After that the 2nd player (who visits the same website but from another computer, and another useraccount) has to make his turn. Both players leave the playboard open in their webbrowser while they are playing.

The problem is: how does the browser of player 2 know when to refresh.
Usually in automation there are 2 possible solutions for this problem.
1) Polling
2) a Trigger/Interrupt

Solution 1: (the polling) is easy, I can indeed write a little ajax script that calls a php page in the background, when the php page finally returns a certain text "REFRESH-OK" then I call a javascript refresh function. So, that's indeed an easy solution.

Interrupts
But is there also something possible like interrupts?
I'm not sure but maybe this is what the HTTP-keep-alive is made for?

I think the advantages of an interrupt system are obvious.
- less data traffic
- realtime response
- less dependent of javascript

Thank you in advance

[kows]

PHP does not continually execute; the webserver tells PHP to parse a file, and once PHP is finished with that it sends it back to the webserver, which then sends that to the client. if you want something continually polling the server for new information, you're going to have to use javascript. no server-side scripting language (as far as I know) is capable of true "real-time response."

[SambaNeko]

I'm not sure but maybe this is what the HTTP-keep-alive is made for?

Nope:

In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response. ... [With Keep-Alive] the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection.

[penagate]

Because the server cannot open a HTTP connection to the client you have to use a kludge method which you alluded to under "Solution 1". Once the page has loaded, use a XMLHttpRequest object to open a connection to a server-side script which returns once there is new data.

You might find that you need to flush the connection every 20-30 seconds even if there is no data. This is because the client will eventually time-out and the server will also kill the script once it reaches the maximum execution time.

There is no real disadvantage to this method other than being slightly inelegant. The only resources consumed are on the server side during the process of polling for new data (perhaps executing a simple SQL query once every second or two). There is no actual data transferred between client and server until either a response is returned or the connection drops out.