New Protocol?

[alunharford]

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

[sje]

There's a strong argument to be made that communication of structured data between disparate platforms should use some existing exchange standard like XML. The idea is that there are already free and portable libraries to help; also, with XML it's fairly easy to expand an exchange standard while retaining backward compatibility.

My thought is that the existing ICS communication protocol is fundamentally broken and needs a complete overhaul. The same goes for the basic ICS software.

[Pradu]

protocol without having to worry about threading and race conditions.

Pondering was the most difficult thing to implement with my threaded program structure. I had a lot of problems with race conditions with this. Here's the pondering method:

Code: Select all

I just made a move.
Set an end time for searching.
I start pondering an expected move and wait for opponent's move.
If opponent's move is the same as the expected move keep pondering.
If opponent's move is not the same as the expected move then stop the search thread, re-allot time and start thinking.
After opponent has made his move, the search thread must stop and make a move if the end time < the current time.

It got really hairy implementing this and I had to use Intel's Thread Checker and Valgrind to get rid of all the race conditions. How will your protocol make it easy to implement pondering for a threaded program structure (<input thread> + <search threads that don't poll input>)

[hgm]

Well, with 2 protocols already existing, it seems a bad idea to add a third.

The native protocol of all my engines is even more staeless, as the engine does not have to know if it is white ot black. You just enter moves for the stm, or you give it the command to produce a move itself. No nonsense like 'force mode', 'white', 'black', 'go' is needed that way.

A severe shortcoming of Winboard protocol is that, although it transmits the time left on the clocks before every move, it does not tell how many moves have to be done in that time. So in addition you need the ill-defined and not versatile enough level commands. The protocol does not require the GUI to send the times.

It would be much better if the protocol contained an explicit command to set the engine searching, that mandatory supplies the time on its clock, the number of moves still to be done in this time, the increment it can expect after each of these moves, and if any time that it does not use will be added to the next time interval.

[Aleks Peshkov]

What's wrong with UCI and many existing GUI and engines?
IMHO all the need is an ICC adapter written as UCI-engine.