What is the simplest method for Interprocess Communication - across any O/S & language

For a programming competition (code war) I want to set it up where I pass the game state to an A.I. as an xml file and that A.I. replies with it's turn in an xml file it returns to my app. Every team in the competition can then implement their A.I. using the language & O/S they are most comfortable with.

Performance is not critical. It is two small xml files (I say file but it will probably only exist in memory) that get passed开发者_如何学运维 over and back. But simplicity is important so that it's quick and easy to implement the client (A.I.) side in any language.

I am thinking that on the server I open a TCP socket, send the state xml file, then go into receive mode waiting for the turn xml file. And I would also have a time-out on the wait so that if I received no answer in a second, I put in a default turn for them.

And on the client side it waits for a TCP socket connection, reads the xml file in, determine its turn, and writes the xml file back out.

Is this the best way to have something where a client can be quickly and easily written in most any language?

Update: This will have each player on a different machine. Have to allow this as some prefer Windows and some Linux. And it makes the process easier.

thanks - dave

If your client and server are running on the same machine, it might be even easier to use stdin/stdout for the IPC. The server would execute the AI process, write an XML document to the AI stdin, then wait for a response on the AI stdout.

If your AI needs to be long-running (to maintain a lot of persistent state, for example), then you could split the AI into two parts, one that is "resident" and the other that is an interface component that is run for each turn by the game process. The interface component could communicate with the resident part by whatever mechanism is most suitable for the language (REST, shared memory, message passing, whatever).

You will need an XML package in whatever languages you are using.

You might use an HTTP over TCP/IP package too - it need not be using port 80, of course. That might well be the combination with the best support available as 'standard' or 'near standard' for different languages.