OS-independent Inter-program communication between Python and C

I have very little idea what I'm doing here, I've never done anything like this before, but a friend and I are writing competing chess programs and they need to be able to communicate to each other.

He'll be writing mainly in C, the bulk of mine will be in Python, and I 开发者_JAVA百科can see a few options:

• Alternately write to a temp file, or successive temp files. As the communication won't be in any way bulky this could work, but seems like an ugly work-around to me, the programs will have to keep checking for change/new files, it just seems ugly.
• Find some way of manipulating pipes i.e. mine.py| ./his . This seems like a bit of a dead end.
• Use sockets. But I don't know what I'd be doing, so could someone give me a pointer to some reading material? I'm not sure if there are OS-independent, language independent methods. Would there have to be some kind of supervisor server program to administrate?
• Use some kind of HTML protocol, which seems like overkill. I don't mind the programs having to run on the same machine.

What do people recommend, and where can I start reading?

If you want and need truly OS independent, language independent inter process communication, sockets are probably the best option.

This will allow the two programs to communicate across machines, as well (without code changes).

For reading material, here's a Python Socket Programming How To.

Two possibilities:

• Use IP sockets. There are some examples in the Python docs. (Really not that hard if you just use the basic read/write stuff.) On the other hand, sockets in C are generally not that simple to use.

• Create a third application. It launches both applications using subprocess and communicates with both applications through pipes. The chess applications must only be able to read/write to stdin/stdout.

  This has the additional benefit that this application could check if a move is legal. This helps you finding bugs and keeping the games fair.

You can use Protobuf as the inter-program protocol and read/write from a file each one turns.

You may read the intermediate file every n seconds.

Once you have this working, you may move to use sockets, where each program would start a server and wait for connections.

The change should be small, because the protocol would be protobuf already. So, the only place you have to change is where you either read from a socket or from a file.

In either case you'll need an interchange protocol.

edit

Ooops I misread and I thought it was C++.

Anyway, here's the C support for protobuf but is still work in progress work

http://code.google.com/p/protobuf-c/

I would say just write an xml file that contains moves for black and white. Mark in a separate file who's turn it is and make sure only the program who's turn it is will write to that file to commit their turn.

Here is a link to a proposed xml format for storing your moves that another group came up with http://www.xml.com/pub/a/2004/08/25/tourist.html

Sockets with a client/server model...

Basically, you and your friend are creating different implementations of the client.

The local client shows a visual representation of the game and stores the state of the pieces (position, killed/not-killed) and the rules about what the pieces can/can't do (which moves can be made with which pieces and whether the board's state is in check).

The remote server stores state about the players (whose turn it is, points earned, whether the game is won or not), and a listing of moves that have occurred.

When you make a move, your client validates the move against the rules of the game, then sends a message to the server that says, I've made this move, your turn.

The other client sees that a turn has been made, pulls the last move from the server, calculates whether where the movement took place, validates the move against the game rules, and replays the action locally. After that's all done, it's now allows the user to make the next move (or not if the game is over).

The most important part of client/server gaming communication is, send as little data to and store as little state as possible on the server. That way you can play it locally, or across the world with little or no latency. As long as your client is running under the same set of rules as your opponent's client everything should work.

If you want to ensure that no one can cheat by hacking their version of the client, you can make the position and rule calculations all be done on the server and just make the clients nothing but simple playback mechanisms.

The reason why sockets are the best communication medium are:

• the limitations on cross process communication are almost as difficult as cross node communication
• networking is widely supported on all systems
• there's little or no barrier-of-entry to using this remotely if you choose
• the networking is robust, flexible, and proven

That's part of the reason why many major systems like Databases uses sockets as a networking as-well-as local communication medium.

if both applications running on same computer, use socket and serialize your objects to jsun. otherwise, use web service and jsun or xml. You can find jsun and xml parser in both languages.