Author: Stefan Meyer-Kahlen
Date: 23:46:20 11/28/00
Go up one level in this thread
On November 28, 2000 at 13:33:06, Robert Hyatt wrote: >On November 28, 2000 at 09:15:30, Stefan Meyer-Kahlen wrote: > > > >There are a couple of _really_ ugly things in this. Ugly because they are >diametrically opposed to other GUIs like xboard/winboard/robofics/etc. > >1. The search vs ponder stuff. I don't see why the GUI has to tell the >engine to begin to ponder. This makes no sense to me, from either a GUI >point of view, or an engine point of view. But the main problem is it is >so different from xboard that the code is going to be very messy. And for >no gain that I can see. We think that it is absolutely necessary to tell the engine to ponder to keep control of what the engine is doing, otherwise the GUI is never sure weather the engine is pondering or waiting or doing whatever. Also for some commands (e.g. searching in a database) the GUI has to be sure that the engine is not wasting cpu cycles in the background. >2. sending too much control info to the engine. The engine ought to be able >to manage itself, sending moves to the GUI and reading moves from the GUI. >Having a protocol to alter other things like selectivity and so forth is fine, >as is having a protocol that allows the engine to tell the GUI certain things >like offer a draw or whatever. Why can't the engine manage itself in this protocol? Draw offers are handled by the GUI right now, but it is certainly possible to extent the protocol. Which control info is not necessary in your opinion? >3. The main thing you have really addressed is "race conditions". One thing >the winboard/xboard protocol is sorely missing is some sort of ack/nak facility >(it has a sort of nak facility if you send an error message) to eliminate the >race conditions that occur. IE the interface says "start a new game" and >immediately assumes this has been done. If you don't check for input quickly >enough, you miss the new game indicator for a bit, and if you send a move, >that move can be sent to the server with an immediate "illegal move" response >since your move came from a game that has ended. > >I don't personally like to ack/nak every message, as that does nothing more >than ramp up traffic. But for critical events (ie new game) an ack would be >nice so that xboard would wait for you to say "ok" before it would proceed to >start a new game, etc. There is no new game command in this interface. We also were aware of this problem and also didn't like the ack/nack mess, so we only introduced it in the "ready/readyok" and "uci/uciok" commands. If desired one can always simulate the ack/nak with ready/readyok, but this is not necessary as we always keep control over the engine. Implicit sync is done as there always have to be a "bestmove" command from the engine for every "go" command from the GUI and that the engine must not start searching or pondering without being told so. That was introduced to avoid the ack/nak thing and don't having "race conditions". > >Before this goes too far, it would seem reasonable to design an interface >once and for all, that everybody will use. Hey, that's what we wanted to do with this thing :-) > That means we need Tim Mann (or >someone familiar with xboard/winboard that is willing to make the needed >changes), someone familiar with ROBOFICS, so that we can have one common >protocol. This has been discussed for years now and there has been many attempts to start a discussion about a new interface, but after a few days those discussions faded aways. Tim Mann did a great job "inventing" winboard but I guess that he is too busy working out a new interface. It is quite a lot of work to design a new interface so if somebody else had done done Rudolf and I could have saved much time, but this did not and probably won't happen. Rudolf and I are familiar with winboard as we have written engines and user interfaces for it, so we know of its problems. The UCI interface is certainly not perfect, but it's pretty good :-) and there are already engines and GUIs supporting it. If we all are waiting for the perfect interface we will still use winboard in 10 years. > Right now, what you are using is so different from the >xboard/winboard protocol, it will make some things very messy to keep >compatibility with both. Is it really that different to winboard? I don't think so. >I don't like the idea of dictating what the engine can and can't do without >permission from the GUI. What is missing? What should or can the engine do? > I think the engine should be free to do anything it wants. See above. If you let the engine do what it wants to you get syncronization problems and need your ack/nak stuff. > Otherwise the GUI might assume the engine is idle and not using CPU >time and be wrong. This can't happen in our interface as it is designed in a way that the GUI always knows what the engine is doing. The opposite is true: If you let the engine do what it wants to this will happen. > Specifying the comm protocol is fine. Specifying a time >limit for responses to commands is fine. But don't specify what the engine can >and can't do while waiting for another command... ie why can't it "ponder" >all the time? see above. > Why does it have to keep searching after it has found the >shortest possible mate? etc... That last point might be important as it >wastes compute cycles. There are smarter ways to wait. This is done for synchronization, see above. Also this is only forbidden while pondering. Thanks for your comments Stefan
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.