# Web application interacts bi-directional with server program?

I want to write a web application to play chess against the engine Crafty. I'm not new to PHP and javascript, but must learn how to interact with a server process : how can a web application and/or (jQuery) ajax interact bi-directionally with a (linux) program running on the server?

At this moment i am developing on (Apache) local host. Crafty is installed on my Ubuntu PC. This well-known chess engine has no GUI, it runs in terminal by the command

\$ /usr/games/crafty


and so you can play chess against it and even see it's calculations. I can make Crafty run by PHP, using the functions proc_open() or exec(), and most documentation i found states that the output stream should be a file .. But i think i don't want such setup, because then the webpage should be constanty polling that file (eg. by ajax) to see if some new data was appended, right?

How can Crafty talk to the web page directly, saying "i have calculated another variation" or "i have decided a move" etc, then display this info on the web page and let the user give some counter move, just like in terminal. Isn't it possible to use some session / stream / listener?

I have no clue at all, can anybody point me in a right direction?

• I would probably use REST web services but i'm not sure that really applies. – Eric B Nov 27 '12 at 14:52

1) giving JS end-users direct access to your terminal is the scariest idea ever, in terms of security, and is 100% impossible without some interfacing server language/framework (php/perl/ruby/c#/python/java/c++/NodeJS), because it is so scary.

2) running exec() on user-input, directly, rather than building an interface in your server language is 100% as scary as giving them access to Apache itself.

3) what you want to do is build out a simple facade/proxy/whatever in your language, for playing the game. That proxy should take user-input and decide what the user wanted to do (what piece is moving where), and based on those parameters, feed Crafty hard-coded or php-generated parameters (and not the direct-input).

This allows safety, first, but also allows you to build your communication strings any way you want, as long as the php and client agree on format.

4) on compatible browsers, you can run websockets -- the standard is volatile right now, but there are some libraries out there which can swap between websocket, flash and old-school XMLHttpRequests ("AJAX").

For a 100% native, backwards-compatible experience, just use AJAX, and poll the server either on a user-move or asking for Crafty's update.

In fact, if the user goes first, every time, then you can just respond to their request with Crafty's next move.

Next -- cheating:

Don't update the game based on what the user sends you, take what the user sends you and validate that the unit at that position (according to the server) is allowed to move in that fashion, and if not, return an error or exception which the client machine then has to deal with (reverting the move, showing an error, and making the player move again)

I should probably add that if Crafty has a decent error-handling output (eg: it outputs what was moved where and why it's wrong, in a consistent format), then your PHP interface can lean on that to handle validation.
PHP would then figure out what the user meant to do, based on the input parameters, feed a prepared statement into Crafty, and read the result -- if the result succeeded, then get Crafty's turn and feed it back to the player's response, in the format you built for communicating between client and server. If it failed, then figure out why, and send that back to the client in an agreed-upon fashion (agreed via PHP and JS), so that your client-side app can handle the error and reset the player's turn.

Oh. Also, if you're looking to allow multiple users to play against the same instance of Crafty, or multiple instances of Crafty, or whatever, then I'd suggest a data-storage format, where you can store instances of the game-state by session-id, or by REST-based client-id, or whatever.
JSON could be seriously lightweight for that, in this case.

I won't tell you HOW to structure these things, but from a "don't hack my server and delete my c:/ drive" and a "don't move three times in a row, or teleport your queen to an insta-checkmate, or move any of MY pieces, instead of yours" standpoint, these are the key points you need to address.

with newer browsers you can use WebSockets, but since you probably don't want to build it all by yourself, checkout http://www.jmesnil.net/stomp-websocket/doc/

stomp is supported by php aswell, so its quite easy to push messages to the queue: http://php.net/manual/de/book.stomp.php