New Protocol?
Posted: Tue May 29, 2007 4:13 am
Introduction
I've been programming an interface to use on internet chess servers (I'm starting with ICC, but I might add support for more servers later). Part of this project involves integration of chess engines with the Winboard and UCI protocols. I've played with making chess engines in the past (although nothing serious enough to release). As a result, I've had the chance to see the protocols used from both 'sides' (programming the UI, and programming the engine).
Many engines go through a stage of implementing their own text interface, and sometimes their own GUI, before they add support for the Winboard protocol. Because of how the Winboard came about, and what it initially was intended to do, it's pretty tricky to implement.
I think it would be good to design another protocol. I have a vague design in mind. The idea is to make something easy to parse and generate, and allows engines to implement the protocol without having to worry about threading and race conditions. My basic idea is as follows:
The Protocol
Communication between the engine and the interface is always via standard I/O (as with the Winboard protocol).
All 'commands' sent between the interface and the engine begin with an integer, which identifies the command (the 'command number'). The interface will only send a command after it has received a response to its previous command. Except as discussed later, the engine should never send anything to the interface except as a reply to the interface's 'command'.
The interface starts the engine, and sends:
1 <someIDstring> <supportsThreads>\n
The engine replies:
1 <someIDstring> <supportsThreads>\n
When the engine's opponent makes a move (or the position is adjusted) the interface sends:
2 <SmithMove> <WhiteTimeInMilliseconds> <BlackTimeInMilliseconds> <FEN>\n
The interface always sends legal moves. The engine decides on its move and replies with:
2 <SmithMove>\n
The engine replies to any other message from the interface that has a command number of less than 1000:
0\n
That's all that's needed for a basic engine.
This allows the engine to be totally stateless, it doesn't have to work out whether the supplied move is legal, and the protocol is *very* simple.
Additional commands can easily be added to provide all the features of other protocols without adding any extra work for people making simple engines. When the engine wants to send additional information to the interface - for example, send chat messages to an ICS, or the opponent, or send analysis information (assuming the engine and interface both indicate that they support such a feature by sending supportsThreads=1 in the initial handshake) command numbers > 1000 are used so that the basic commands can be easily separated. Commands with a command number >1000 are just consumed and no reply is sent.
Is this a sensible idea? Or do you think another protocol would only complicate matters?
And do you have any suggestions or insight on the topic?
Alun Harford
I've been programming an interface to use on internet chess servers (I'm starting with ICC, but I might add support for more servers later). Part of this project involves integration of chess engines with the Winboard and UCI protocols. I've played with making chess engines in the past (although nothing serious enough to release). As a result, I've had the chance to see the protocols used from both 'sides' (programming the UI, and programming the engine).
Many engines go through a stage of implementing their own text interface, and sometimes their own GUI, before they add support for the Winboard protocol. Because of how the Winboard came about, and what it initially was intended to do, it's pretty tricky to implement.
I think it would be good to design another protocol. I have a vague design in mind. The idea is to make something easy to parse and generate, and allows engines to implement the protocol without having to worry about threading and race conditions. My basic idea is as follows:
The Protocol
Communication between the engine and the interface is always via standard I/O (as with the Winboard protocol).
All 'commands' sent between the interface and the engine begin with an integer, which identifies the command (the 'command number'). The interface will only send a command after it has received a response to its previous command. Except as discussed later, the engine should never send anything to the interface except as a reply to the interface's 'command'.
The interface starts the engine, and sends:
1 <someIDstring> <supportsThreads>\n
The engine replies:
1 <someIDstring> <supportsThreads>\n
When the engine's opponent makes a move (or the position is adjusted) the interface sends:
2 <SmithMove> <WhiteTimeInMilliseconds> <BlackTimeInMilliseconds> <FEN>\n
The interface always sends legal moves. The engine decides on its move and replies with:
2 <SmithMove>\n
The engine replies to any other message from the interface that has a command number of less than 1000:
0\n
That's all that's needed for a basic engine.
This allows the engine to be totally stateless, it doesn't have to work out whether the supplied move is legal, and the protocol is *very* simple.
Additional commands can easily be added to provide all the features of other protocols without adding any extra work for people making simple engines. When the engine wants to send additional information to the interface - for example, send chat messages to an ICS, or the opponent, or send analysis information (assuming the engine and interface both indicate that they support such a feature by sending supportsThreads=1 in the initial handshake) command numbers > 1000 are used so that the basic commands can be easily separated. Commands with a command number >1000 are just consumed and no reply is sent.
Is this a sensible idea? Or do you think another protocol would only complicate matters?
And do you have any suggestions or insight on the topic?
Alun Harford