Implementing UCI Protocol

Code, algorithms, languages, construction...
Kolarik
Posts: 7
Joined: Tue Dec 21, 2010 12:22 am

Implementing UCI Protocol

Post by Kolarik » Tue Dec 21, 2010 1:42 am

Hello All,

My friend and I are currently working on coding an engine from scratch. We have almost complete a very simplistic version but we are currently having trouble with implementing the UCI protocol. We have no idea how to create the PV and dump it to the GUI. Also, we have no idea how to make the engine accept the "stop" command from the GUI during the search. We have tried a few things but the search would get paused until the GUI sent a command which is not what we want.

Now before you say "look at an open source engine", we have already looked at a couple examples, TSCP and Gerbil, but we can't find what we are looking for.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Implementing UCI Protocol

Post by BB+ » Tue Dec 21, 2010 9:30 am

We have no idea how to create the PV and dump it to the GUI.
I'm not sure this is really UCI-specific, but seems more pertinent to the engine. Does the engine have an array of moves/strings that represent the PV?
Also, we have no idea how to make the engine accept the "stop" command from the GUI during the search.
Essentially you need to do some sort of non-blocking I/O. This should be in various open-source engines, though I agree it can be rather tricky (and OS dependent). I think Crafty, Fruit, IvanHoe, Stockfish, and others all have examples. See posix.cpp of Fruit, and the input_available() function.

Kolarik
Posts: 7
Joined: Tue Dec 21, 2010 12:22 am

Re: Implementing UCI Protocol

Post by Kolarik » Thu Dec 23, 2010 9:37 am

Essentially you need to do some sort of non-blocking I/O. This should be in various open-source engines, though I agree it can be rather tricky (and OS dependent). I think Crafty, Fruit, IvanHoe, Stockfish, and others all have examples. See posix.cpp of Fruit, and the input_available() function.
Thank you very much. I believe that we figured out how to do this.

However, this success seems short lived. When we tried to install the engine to Arena, Arena would begin to start up engine but after a short while it would shut the engine down and try to restart it. Our I/O looks the exact same as other engines. Is there another else that would force GUI's to shut down an engine?

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Implementing UCI Protocol

Post by BB+ » Thu Dec 23, 2010 10:41 pm

One possibility is that the GUI sends "isready" or "uci", and expects a response within a certain time limit.

Kolarik
Posts: 7
Joined: Tue Dec 21, 2010 12:22 am

Re: Implementing UCI Protocol

Post by Kolarik » Fri Dec 24, 2010 3:59 am

The engine sends its response instantly. Unless there is some command that I am missing? As far as I can tell the engine only needs to receive the engine name author name then send "uciok" and "readyok". Here is a link to download the a compile of the engine if you want to take a closer look. http://www.megaupload.com/?d=66LBEHTU

Thank you once again BB+. You are a very helpful individual.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Implementing UCI Protocol

Post by BB+ » Sun Dec 26, 2010 11:07 pm

The only other thing I can think of is maybe you are not flushing the output?

Kolarik
Posts: 7
Joined: Tue Dec 21, 2010 12:22 am

Re: Implementing UCI Protocol

Post by Kolarik » Tue Dec 28, 2010 9:25 pm

What do you mean by "flushing the output"?

From what we found, "Forcing all buffered output to actually be printed is known as "flushing" the stream." Is that not the same as the engine using the printf or cout commands to print text in the command line?

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Implementing UCI Protocol

Post by BB+ » Tue Dec 28, 2010 9:28 pm

Yes, printf only writes to a buffer. You need to do fflush(stdout); to flush the contents of this buffer, as else it will just sit there, and will not communicate to the GUI. This is a major difference between using a "console" (when the output appears anyway), and with inter-process communication via pipes. My recollection of how cout works in C++ is not that great, but it might be similar. EDIT: See http://support.microsoft.com/kb/94227 for C++ and cout. Note that endl flushes in C++, but a "\n" character does not in C.

Kolarik
Posts: 7
Joined: Tue Dec 21, 2010 12:22 am

Re: Implementing UCI Protocol

Post by Kolarik » Thu Dec 30, 2010 12:19 am

Ah. That was exactly the problem. I never realized that GUI would be unable to read directly from the command line.

However there is still a problem. Arena keeps saying that the engine is making an illegal move.
In the command line the text seems something like this.

User enters "go"

Engine sends depth, score, nodes

Engine completes search and sends "bestmove e2e4"

Also, how does the GUI communicate the moves that the other engine made is it a simple e2e4 command or does it send another position?

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Implementing UCI Protocol

Post by BB+ » Thu Dec 30, 2010 12:31 am

Under UCI, it always sends "position fen BLAH" -- in a game, many just do: "position startpos moves LIST". UCI is almost by definition "state-less", so it cannot assume that you know the previous position. So you would likely receive "position startpos moves e2e4 e7e6" and then "go wtime 65000 winc 3333 btime 54321 binc 3333" or something.

Flushing a pipe has stumped other GUI makers too: http://www.open-chess.org/viewtopic.php?f=5&t=597

Post Reply