Author: Michael Yee
Date: 18:03:29 03/14/05
Go up one level in this thread
On March 14, 2005 at 14:21:20, Russell Reagan wrote: >On March 14, 2005 at 12:45:22, Michael Yee wrote: > >>The protocol proposal has been updated to reflect several good >>comments/suggestions. >> >>(1) There is now a table of what commands are valid in each state. This makes >>the protocol clearer and even look simpler than it did before (at least to me >>:). Thanks to Harald for this suggestion. >> >>(2) New commands from GUI to engine : getstartpos, getmovelist, getresult >> >>This enables the protocol to be truly extensible since variants that aren't >>officially supported by the GUI can still be supported by letting one engine be >>the "referee" or "arbiter". This interesting idea came from Reinhard (also the >>source of the move and position formats for officially supported variants >>FRC/CRC). >> >>(3) New command from engine to GUI : error >> >>------ >> >>Even if people are dead set against introducing a new protocol into the mix, I'm >>curious what UCI fans think about some of the extensions. Specifically, >> >>- describing what options mean, >>- custom thinking output, and even >>- getstartpos, getmovelist, getresult >> >>could be added without too much fuss (while maintaining the core philosophy of a >>stateless engine)... >> >>Thanks, >>Michael > >Your protocol is starting to sound more like Dann's database idea where the >engine can get the information it needs using database queries. Your idea just >sends text commands through standard pipes instead of using database queries. >Here are some ideas. Maybe the GUI could maintain a database of relevant game >info: start position, move list, opponent name, opponent rating, opponent type >(human, computer, etc), clock left, and so on. The GUI could send a broadcast to >the participating engines that there is new information (and possibly specify >which information is new, so it doesn't have to get all new information). If you >tagged each command from the GUI (ex. numerically), the engine could request >"all updates since command N", where N is some tag number. All transactions >could be done using text commands, like email protocols. > >http://www.catb.org/~esr/writings/taoup/html/ch05s03.html Sorry for being slow, but I don't really understand the benefits of the database approach for managing the actual game itself. Is the appeal that the information just resides in one central location instead of being sent to multiple sources (e.g., each engine in the XCI proposal would receive the same "move abcd" command after one of the engines moved)? Would the engine need to deduce from the new updates in the database that it was now it's turn to think and start acting on its own? This sounds less clear to me than just sending a direct command to start thinking... However, thanks for providing that interesting link. It reminded me of another issue. It seems like there are 2 main approaches to synchronization: (1) have ping/pong (WB), isready/readyok (UCI), or numbered/labeled requests (IMAP) so that multiple commands can be sent in a bunch before checking if the engine's finished processing them (2) Require a status/result after each operation (SMTP?) Either looks fine, but I wonder which would be easiest for gui/engine programmers? Michael
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.