Author: Vasik Rajlich
Date: 03:06:18 03/15/05
Go up one level in this thread
On March 15, 2005 at 05:43:18, Russell Reagan wrote: >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. Yes, this is an important issue - how easy will the migration be. Recently, I wrote my own GUI in .NET, and the communication with a UCI engine was _extremely_ easy to set up. You just start the process and sign up for input/output events. All the code to handle this took <1 day. I doubt at the moment that replacing text I/O is worth the trouble. Vas > > >>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.