With the official release of WinBoard 4.4.0, the extensions to WinBoard protocol, which upto now carried the qualification "Discussion Proposal", have also become final and official. The new protocol specs accompany the WinBoard 4.4.0 release, and can also be viewed on WinBoard forum.
The new engine->GUI commands are all in the form of feature commands, to make them fully compatible with GUIs not implementing the extensions (which will simply reject a feature xxx=... they do not know through a rejected xxx reply). New features are:
feature debug=0
feature nps=0
feature memory=0
feature smp=0
feature egt=""
feature option=""
The first one controls the possibility for the engine to send debug messages for inclusion in the winboard.debug file. The next four features, when set, enable the new GUI->engine commands nps R, memory M, cores N and egtpath TYPE PATH commands, where R is a rate in knps, M is the maximum memory usage in MB, N is the maximum number of CPUs that can be used by an SMP engine, TYPE is the name of an end-game-table type (e.g. Nalimov or Scorpio) and PATH is the pathname where the tables of that type are to be found. E.g. when the engine sends
feature egt="Nalimov,Scorpio,Edwards"
the GUI might at some point send to the engine
egtpath Nalimov D:/tablebases
egtpath Scorpio H:/bitbases
i.e. one separate command for every format the engine supports and wich can be found on the current system. The TYPE names are not part of the protocol, and can be anything. It is up to the providers of the format to define a name that engines should use for referring to that format.
The option fetuare is special, in the sense that there can be more than one, and the GUI accumulates them, rather than overwriting them. They are used to let the engine define options, and the description of the option will be contained in the string. E.g.
feature option="Resign -check 0"
would define a checkbox option called Resign, that currently has value 0 (unchecked). The GUI could alter the setting of this option by sending
option Resign=1
to the engine. Names of options are also not part of the protocol, nd can be arbitrary strings. The GUI will not know what the string means, and only would send a command to alter the value when the user tels it to do so.
So in summary, the new GUI->engine commands are:
nps R
memory M
cores N
egtpath TYPE PATH
option NAME=VALUE
For the details on what option types exist, refer to the specs.
WB protocol extensions
Moderator: Ras
-
- Posts: 28394
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 397
- Joined: Sun Oct 29, 2006 4:38 am
- Location: Schenectady, NY
Re: WB protocol extensions
Hi HG,
You might want to update the section entitled:
WinBoard requires Win32 engines
It seems to imply that Winboard does not support 64-bit engines.
Perhaps a better title would be:
Winboard does not support DOS engines
or,
Winboard does not support 16-bit engines or engines using 32-bit DOS Extenders
Ron
You might want to update the section entitled:
WinBoard requires Win32 engines
It seems to imply that Winboard does not support 64-bit engines.
Perhaps a better title would be:
Winboard does not support DOS engines
or,
Winboard does not support 16-bit engines or engines using 32-bit DOS Extenders
Ron
-
- Posts: 28394
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: WB protocol extensions
Ah, you are right. This is confusing in the modern context. I never noticed that paragraph, just added the new stuff to the existing document.
I guess it would be better to redo the protocol-specs document entirely. It is currently a strange mix of protocol specs and a description of implementation quirks of particular WinBoard versions. The mentioned paragraph has no business being in any protocol specs at all. WB protocol works exactly the same on 16-bit machines and 8-bit machines and 60-bit machines as it does on i386 and x64, even if WinBoard doesn't. Only architectures that do not support lower-case characters in plain text would present a problem.
Stuff like this should go in the "bugs and limitations" section of the WinBoard help file, as it has absolutely nothing to do with WinBoard protocol.
Thanks for the feedback. Let me return the favor: On the horizonchess.com website you seem to have some wrong links. The one to the engines-FAQ is broken, and the one that is supposed to point to the WinBoard FAQ in fact points to the engines-FAQ.
I guess it would be better to redo the protocol-specs document entirely. It is currently a strange mix of protocol specs and a description of implementation quirks of particular WinBoard versions. The mentioned paragraph has no business being in any protocol specs at all. WB protocol works exactly the same on 16-bit machines and 8-bit machines and 60-bit machines as it does on i386 and x64, even if WinBoard doesn't. Only architectures that do not support lower-case characters in plain text would present a problem.
Stuff like this should go in the "bugs and limitations" section of the WinBoard help file, as it has absolutely nothing to do with WinBoard protocol.
Thanks for the feedback. Let me return the favor: On the horizonchess.com website you seem to have some wrong links. The one to the engines-FAQ is broken, and the one that is supposed to point to the WinBoard FAQ in fact points to the engines-FAQ.
-
- Posts: 858
- Joined: Wed Mar 08, 2006 9:24 pm
- Location: Germany
- Full name: Daniel Mehrmann
Re: WB protocol extensions
Hello,
i dislike the way of the new winboard protocol at all. If i'm looking back to the start of wbp ((w)in(b)board-(p)rotocol) it was designed with a concept.
The idea of the concept was that the engine should run as a autarkic object. All importend settings and other stuff should be controled by the engine.
This idea created advantages that accrued freedooms for the programmers.
Of course, this is a hard way and still some situations are unclear for both sides (GUI, engine), if i'm looking to definitions inside the protocol. But you can say this a concept based weakness and accepted.
However, this is the "soul" of this protocol and that was always my reasons why i never expand it like HG does right now. Maybe only a few people knew that i and Tim was working on wb3. But it stopped some years ago.
The "commercial" view needs another concept of implementation. UCI was created. Here we have a clear "master/slave" concept. The GUI is the master and the engine is the slave. The master has the control over all and without a command the engine isn't allow to do anything.
So, two protocols and both have good and bad "sides". It's just a matter of taste which do you prefer.
Today:
The wbp just starts to go the way like UCI does. So, if i use hard words, i could say the wbp is now useless for (standard)chess! I just ignore the 1% users for other variants of chess.
Sooner or later wbp und UCI will be the same stuff (concept based) and the programmer might will vote for UCI. (I would do that)
Well, at this point i could write some more thoughts, but i think i don't wanna disturb the new winboard-working-group.
I don't wanna start a discussion at all and i'll not answer to any response in this case (thread).
So called, just my 2 cent
Best,
Daniel
i dislike the way of the new winboard protocol at all. If i'm looking back to the start of wbp ((w)in(b)board-(p)rotocol) it was designed with a concept.
The idea of the concept was that the engine should run as a autarkic object. All importend settings and other stuff should be controled by the engine.
This idea created advantages that accrued freedooms for the programmers.
Of course, this is a hard way and still some situations are unclear for both sides (GUI, engine), if i'm looking to definitions inside the protocol. But you can say this a concept based weakness and accepted.
However, this is the "soul" of this protocol and that was always my reasons why i never expand it like HG does right now. Maybe only a few people knew that i and Tim was working on wb3. But it stopped some years ago.
The "commercial" view needs another concept of implementation. UCI was created. Here we have a clear "master/slave" concept. The GUI is the master and the engine is the slave. The master has the control over all and without a command the engine isn't allow to do anything.
So, two protocols and both have good and bad "sides". It's just a matter of taste which do you prefer.

Today:
The wbp just starts to go the way like UCI does. So, if i use hard words, i could say the wbp is now useless for (standard)chess! I just ignore the 1% users for other variants of chess.
Sooner or later wbp und UCI will be the same stuff (concept based) and the programmer might will vote for UCI. (I would do that)
Well, at this point i could write some more thoughts, but i think i don't wanna disturb the new winboard-working-group.

I don't wanna start a discussion at all and i'll not answer to any response in this case (thread).
So called, just my 2 cent

Best,
Daniel
-
- Posts: 28394
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: WB protocol extensions
I do not reognize the protocol extensions in any of this criticism. The new commands do nothing to give the GUI larger control over the engines, so I don't see how it would detract from their "autarkicness".
The memory and cores commands just notify the engine of system limitations. Limitations are a necessary evil in the real world, and saying to an engine: "well, you are autarkic, grab any amount of memory you like", so that it leaves nothing for the opponent, or for the other two tourneys you want to run on the computer, just doesn't work. One always has had to set hash-table size on every WinBoard engine since hash tables were invented. The only difference is that now the engines get an opportunity to request this information directly and automatically from the GUI in a standardized way. And engines don't even have to do that if they don't want that (but rather annoy the user with settings files or command-line arguments, to eventually identical effect).
Similar for the location of shared resources, like tablebases. I can't imagine you want to propose that WB engines should only be allowed to use tablebases if they bring their own set of Nalimove tablebases, that has to be separately installed and must not be shared with other engines. And even it that is what you meant, not having the egtpath command has not stopped any WinBoard engine from using shared Nalimov tablebases so far.
The option feature does not give the GUI any control over the engine at all. The GUI does not even know what the options mean, and cannot use them to alleviate any engine tasks whatsoever. If engines want to have user-adjustable settings (and many native WB engines already do), what difference does it make to the independence of the engine if the user has to edit some obscure config file to set them, or that he can do it from a luxurious dialog window?
The task of a GUI is to allow the user access to the engine in a user-friendly way. The task of a protocol is to make that possible. To force the user to do the things that need to be done, and that everyone wants done, in a cumbersome way, by not supporting the necessary commands to make them possible has nothing to do with protocol philosophy of engine independence. It only means the protocol is lousy.
I am pretty sure WB protocol would have had memory and cores commands from the very beginning if it would have been conceived in an epoch where hash tables and SMP were common amongst engines (so that GNU Chess would have had those commands). That they were missing is only due to the fact that the protocol has not been developed and modernized by really a decade. A decade that completely changed the world of computing and Chess-engine design. So that to all intents and purposes it had become like a stone-age tool. Not meeting the demands of modern times, not because of some deep ideology, but simply because the world changed, and it failed to adapt out of inertia.
The memory and cores commands just notify the engine of system limitations. Limitations are a necessary evil in the real world, and saying to an engine: "well, you are autarkic, grab any amount of memory you like", so that it leaves nothing for the opponent, or for the other two tourneys you want to run on the computer, just doesn't work. One always has had to set hash-table size on every WinBoard engine since hash tables were invented. The only difference is that now the engines get an opportunity to request this information directly and automatically from the GUI in a standardized way. And engines don't even have to do that if they don't want that (but rather annoy the user with settings files or command-line arguments, to eventually identical effect).
Similar for the location of shared resources, like tablebases. I can't imagine you want to propose that WB engines should only be allowed to use tablebases if they bring their own set of Nalimove tablebases, that has to be separately installed and must not be shared with other engines. And even it that is what you meant, not having the egtpath command has not stopped any WinBoard engine from using shared Nalimov tablebases so far.
The option feature does not give the GUI any control over the engine at all. The GUI does not even know what the options mean, and cannot use them to alleviate any engine tasks whatsoever. If engines want to have user-adjustable settings (and many native WB engines already do), what difference does it make to the independence of the engine if the user has to edit some obscure config file to set them, or that he can do it from a luxurious dialog window?
The task of a GUI is to allow the user access to the engine in a user-friendly way. The task of a protocol is to make that possible. To force the user to do the things that need to be done, and that everyone wants done, in a cumbersome way, by not supporting the necessary commands to make them possible has nothing to do with protocol philosophy of engine independence. It only means the protocol is lousy.
I am pretty sure WB protocol would have had memory and cores commands from the very beginning if it would have been conceived in an epoch where hash tables and SMP were common amongst engines (so that GNU Chess would have had those commands). That they were missing is only due to the fact that the protocol has not been developed and modernized by really a decade. A decade that completely changed the world of computing and Chess-engine design. So that to all intents and purposes it had become like a stone-age tool. Not meeting the demands of modern times, not because of some deep ideology, but simply because the world changed, and it failed to adapt out of inertia.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: WB protocol extensions
Can you explain the intent of the "nps" option? Since that is universally "nodes per second" everywhere, why/how would/could the GUI send that to the engine, rather than vice-versa? If it really is nps as commonly used, why would the GUI send that rather than the engine computing it as it searches???
-
- Posts: 28394
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: WB protocol extensions
The nps command request the engine to translate all times to a number of nodes _as if_ it was playing with the given number of nodes per second. So after receiving an nps 50 command (usually at the beginning of the game), when the GUI tells it that it has still 10 sec on the clock (time 1000) for the next move, it should search at most 500,000 nodes (10 sec x 50 knps).
This is the generalization of playing a fixed (maximum) number of nodes to other time-control types. If someone wants to play an engine at 1M nodes per move, he can send st 10 (10 sec per move) and nps 100 (100 knps). But you would have all the disadvantages of the st time-control type: it would severely restrict the engine in allocating extra time to moves where it really matters.
The way the nps command is implemented allows you to avoid this: you could set a TC of 40 moves per 400 sec, (level 40 6:40 0), and nps 100. The nps command would force translation of the 400 sec to 40M nodes. So the engine would have a budget of 40M nodes for 40 moves, but it would be free to allocate it on individual moves at it saw fit (e.g. giving extra time on fail lows, etc., according to its normal time management algorithm), as long as it does not exceed the total.
It is very easy to implement the nps command in an engine: just keep a node counter, and let the routine that returns the time return nodeCount/NPS in stead. (Where NPS is the value you received with the nps command.)
In the mode where you play by node count rather than wall-clock time, the GUI will decrement the clocks based on the node count reported in the Thinking Output, using the same calculation nodeCount/NPS, so that the engine will forfeit "on time" if and only if it has used more nodes than it was allowed for the session. (And before you ask: yes, it is possible for engines to cheat, but this is a feature meant for testing, not competition.)
It doesn't really matter if the NPS value given is realistic. The only effect of an unrealistic value would be that the total time for the game starts to deviate very much from the TC that was really set. E.g. if I would set Crafty with nps 1 to 1 (virtual) knps, while on that hardware it would in reality do 1 Mnps, and let it play a 40/40 game, it would in fact do 40 moves in 2.4 sec, rather than 40 min (=2400 sec).
This is the generalization of playing a fixed (maximum) number of nodes to other time-control types. If someone wants to play an engine at 1M nodes per move, he can send st 10 (10 sec per move) and nps 100 (100 knps). But you would have all the disadvantages of the st time-control type: it would severely restrict the engine in allocating extra time to moves where it really matters.
The way the nps command is implemented allows you to avoid this: you could set a TC of 40 moves per 400 sec, (level 40 6:40 0), and nps 100. The nps command would force translation of the 400 sec to 40M nodes. So the engine would have a budget of 40M nodes for 40 moves, but it would be free to allocate it on individual moves at it saw fit (e.g. giving extra time on fail lows, etc., according to its normal time management algorithm), as long as it does not exceed the total.
It is very easy to implement the nps command in an engine: just keep a node counter, and let the routine that returns the time return nodeCount/NPS in stead. (Where NPS is the value you received with the nps command.)
In the mode where you play by node count rather than wall-clock time, the GUI will decrement the clocks based on the node count reported in the Thinking Output, using the same calculation nodeCount/NPS, so that the engine will forfeit "on time" if and only if it has used more nodes than it was allowed for the session. (And before you ask: yes, it is possible for engines to cheat, but this is a feature meant for testing, not competition.)
It doesn't really matter if the NPS value given is realistic. The only effect of an unrealistic value would be that the total time for the game starts to deviate very much from the TC that was really set. E.g. if I would set Crafty with nps 1 to 1 (virtual) knps, while on that hardware it would in reality do 1 Mnps, and let it play a 40/40 game, it would in fact do 40 moves in 2.4 sec, rather than 40 min (=2400 sec).
-
- Posts: 929
- Joined: Sun Nov 19, 2006 9:16 pm
- Location: Russia
- Full name: Aleks Peshkov
Re: WB protocol extensions
UCI-protocol have "nodes" limit, if you want similar why name it "nps", especially if you mean "knps". Why not "nodes"?
-
- Posts: 28394
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: WB protocol extensions
Because it is a nodes-per-second conversion factor, not a number of nodes.
-
- Posts: 397
- Joined: Sun Oct 29, 2006 4:38 am
- Location: Schenectady, NY
Re: WB protocol extensions
I fixed the link. I also altered the Winboard link -- instead of the old Tim Mann site it now points to your version.hgm wrote:On the horizonchess.com website you seem to have some wrong links. The one to the engines-FAQ is broken, and the one that is supposed to point to the WinBoard FAQ in fact points to the engines-FAQ.
Thanks.