Author: Russell Reagan
Date: 02:43:18 03/15/05
Go up one level in this thread
On March 14, 2005 at 21:03:29, Michael Yee wrote: >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... One advantage I can think of is that, like a good email protocol, the current state is always available. You don't have to worry about synchronization. The client engine boots and finds out what is going on (what's the current game state? am I playing in this game, or just a spectator? is it my turn to move? how much time is left? approximately how much memory am I allowed to use? should I use my own book? and so on). Then it takes appropriate action. One thing that is nice about IMAP is that you don't have to download the entire message. You can just download the headers and then download the messages that you want to read. Downloading the entire message is similar to what UCI does. I don't see it as a huge problem, but you could try to create an equivalent to just downloading message headers instead of the entire message. Maybe send a broadcast to the appropriate engines that new "messages" are available, and they can get the messages they need. Maybe an engine only wants the last move made (like Winboard). Maybe the engine wants to update the entire state (like UCI). You could easily create adapters to support Winboard and UCI engines using this kind of protocol. I think this would also allow for uses other than playing a chess game between two chess engines. You could create a program to view a live match, or watch a GM give analysis, or spit out random positions as the "current state", or any other thing you could think of. Basically, the server/database/gui just keeps track of some state, and clients can "connect" and get the current state and use it for any purpose they desire. You could do this using an actual database connection or simple text commands (I like text commands myself). I think it would be more extensible than any protocol like Winboard or UCI. You could establish some standard things that engines could query for (i.e. the things required to play a game of chess), and have virtually unlimited optional bits of data (opponent name, rating, human/computer/other, country, and so on). If there is no information about the opponent's country, then you get some response indicating nothing (maybe a query ID/tag with no message). This could be a good middle ground protocol. UCI fans like the stateless approach, while Winboard fans dislike the GUI having so much control. This approach would be completely asynchronous, with the same stateless advantages of UCI, but the GUI isn't "controlling" anything or saying, "ponder now, and ponder this move". I'm kind of thinking about this in terms of a web server or email server, and a client-server relationship with different client permissions (ex. some clients can be players, while others are spectators. spectators obviously shouldn't be able to play a move or take any other actions. they get "read only" status). I think it is important to make it easy for people implementing clients, which will primarily be chess engine authors. Therefore, I personally prefer the text commands through standard input and standard output. >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.