xboard protocol - a compromise that would work

[Uri Blass]

In that vein, why not stop asking a program to do something insane. How is a _human_ going to try to claim a draw by doing that? What human will first click "actions, then offer draw, then make move, then "claim draw" in a game they play.

I will certainly do something similiar

I will first offer a draw without making a move.
If my opponent does not accept the draw offer then I am going to write my next move and after writing it I am going to claim a draw.

computers have no way to write their next move without making them because the protocol does not give them this option.

I have no objection to extending the protocol to have an option to do it
but in this case you need to prevent misunderstanding between the engine and the interface and the only way is by using the new protocol only with engines that tell you that they support the new protocol.

Even if we extend the protocol we have to understand that some interfaces do not know about the extended protocol and the only way for you not to have problems in this case is to have the sequence
offer a draw,move,claim a draw unless the interface tell Crafty that it is using a new protocol so you can replace move,claim draw by one string that has both writing the move and claiming the draw after it.

Uri

[hgm]

First, I thought the same. And I lost a game when ChessGUI said "this claim is invalid, you lose."

Yes, ChessGUI is one of the few that verifies claims. But it solves the race condition by adjudicting all claimable draws, so no problem there. Just don't do any advance claiming.

Supposedly Arena is doing the same thing according to (I believe) Graham who said the same problem occurred there.

Well, I missed that, but I will investigate it by contacting Graham.

I've been using winboard/xboard since long before you could even spell it. I've always been perfectly happy with it. And some of the features you have added have been quite useful and well-done. But there is an ambiguity in the protocol that requires a god-awful kludge from the programmer to make it work correctly.

Well, the protocol is something different tha the GUI, and not a distinctive feature amongst GUIs, as they all have to follow the same protocol. It is also not how I would have designed a protocol.

So much of a kludge that most authors are unaware of the problem, much less the solution.

Well, engine authors should not be bothered with solving GUI problems. It should be eough for them to follow the protocol. If you mean GUI programmers here, that is a different matter. But GUIs are typically used very heavily, and if the make wrong calls, they would be very quickly found out. And then the GUI programmer will get a hands-on learning experience if he has to debug it.

I've made the necessary change to how crafty "claims" a draw, in version 23.1. I'll just "wait and see" to determine how well it works in the general case.

I am curious. But if there are problems with the new claim sequence, we should change the GUIs, not Crafty!

Anytime I lose a game that is should be drawn, it is definitely "my problem". I'm the one losing 1/2 point. Whether it is in an important event or not doesn't matter that much.

This is a completely wrong attitude. It is trivial for me to write a GUI that would forfeit Crafty for playing e2-e4 or d2-d4, with the message "illegal move by Crafty". Would you then delete these openings from Crafty's book, just to score better on that GUI? It seems wiser to simply say: "this GUI is obviously no good". By adapting to garbage GUIs, you will slowly but surely reduce your engine to garbage as well, which will then promote the origin of more garbage GUIs that will again adapt their command handling to garbage engines, etc.

Not quite true. When I write down the move and call the arbiter over, I now am _forced_ to play that move, unless it is illegal. The arbiter should come over to verify the claim, and when he examines the position after the move I write down, looking for a 3-fold rep, he should notice that that move checkmated my opponent and ended the game.

This cannot really happen on a 3-fold rep, or you would have been checkmated 2 times before! It can only happen on a 50-move claim. And then there s no need for the referee to play the move; on the contrry, he should go backwards in the game, to count reversible moves, and if there are 99, and your move was not a Pawn's or capture, he would in theory never have to perform it to judge if it was draw...

[bob]

First, I thought the same. And I lost a game when ChessGUI said "this claim is invalid, you lose."

Yes, ChessGUI is one of the few that verifies claims. But it solves the race condition by adjudicting all claimable draws, so no problem there. Just don't do any advance claiming.

Supposedly Arena is doing the same thing according to (I believe) Graham who said the same problem occurred there.

Well, I missed that, but I will investigate it by contacting Graham.

I've been using winboard/xboard since long before you could even spell it. I've always been perfectly happy with it. And some of the features you have added have been quite useful and well-done. But there is an ambiguity in the protocol that requires a god-awful kludge from the programmer to make it work correctly.

Well, the protocol is something different tha the GUI, and not a distinctive feature amongst GUIs, as they all have to follow the same protocol. It is also not how I would have designed a protocol.

So much of a kludge that most authors are unaware of the problem, much less the solution.

Well, engine authors should not be bothered with solving GUI problems. It should be eough for them to follow the protocol. If you mean GUI programmers here, that is a different matter. But GUIs are typically used very heavily, and if the make wrong calls, they would be very quickly found out. And then the GUI programmer will get a hands-on learning experience if he has to debug it.

I am talking about the "offer draw" issue to claim a 3-fold repetition after the move the "offer draw" precedes. That doesn't match the version of the protocol I have, which means we have two conflicting versions of the same protocol, yet we have been arguing whether it is OK to change a protocol or not. Looks like it has already happened and some will get it wrong if they implemented this a couple of years back.

I've made the necessary change to how crafty "claims" a draw, in version 23.1. I'll just "wait and see" to determine how well it works in the general case.

I am curious. But if there are problems with the new claim sequence, we should change the GUIs, not Crafty!

Anytime I lose a game that is should be drawn, it is definitely "my problem". I'm the one losing 1/2 point. Whether it is in an important event or not doesn't matter that much.

This is a completely wrong attitude. It is trivial for me to write a GUI that would forfeit Crafty for playing e2-e4 or d2-d4, with the message "illegal move by Crafty". Would you then delete these openings from Crafty's book, just to score better on that GUI? It seems wiser to simply say: "this GUI is obviously no good". By adapting to garbage GUIs, you will slowly but surely reduce your engine to garbage as well, which will then promote the origin of more garbage GUIs that will again adapt their command handling to garbage engines, etc.

Not quite true. When I write down the move and call the arbiter over, I now am _forced_ to play that move, unless it is illegal. The arbiter should come over to verify the claim, and when he examines the position after the move I write down, looking for a 3-fold rep, he should notice that that move checkmated my opponent and ended the game.

This cannot really happen on a 3-fold rep, or you would have been checkmated 2 times before! It can only happen on a 50-move claim. And then there s no need for the referee to play the move; on the contrry, he should go backwards in the game, to count reversible moves, and if there are 99, and your move was not a Pawn's or capture, he would in theory never have to perform it to judge if it was draw...

Actually it can happen on 3-fold reps, and has at least once. I watched a speed chess game at the US Open one year where this happened. I watched another where one side's queen was left hanging for 10+ moves and no one noticed until the game ended with that side winning.

But on a 50-move case what I gave above would be a distinct possibility in a time scramble...

[hgm]

I am talking about the "offer draw" issue to claim a 3-fold repetition after the move the "offer draw" precedes. That doesn't match the version of the protocol I have, which means we have two conflicting versions of the same protocol, yet we have been arguing whether it is OK to change a protocol or not. Looks like it has already happened and some will get it wrong if they implemented this a couple of years back.

The offer draw handling of current xboard is not really crucial to the handling of the race condition in local play. The problem would be fully solved by the handling of the 1/2-1/2 command. The original specs (likely the version you have) prescribe this command to be sent in the claimable position, so IMO the GUI _must_ grant a draw no matter who wins the race.

The offer draw is mainly in the sequence for the benifit of ICS play. Original specs say that it is to be used to offer draws, or accept draws in the face of a race condition. (The latter is hidden in the description of the GUI->engine draw command, and therfore often overlooked.) It can't be blamed on the GUI that the ICS requires a draw to be offered before the drawing move. One might argue that it is a protocol change, but it is really a change in the ICS protocol, not in the WB protocol.

So I don't feel that the definition of the commands has been changed: offer draw still sends "draw" to the ICS, 1/2-1/2 still should terminate the game with a draw claim. The problem is that these commands now have to be used in a way that was not explicitly defined in the original protocol specs, because the ICS requires this.

I still like the solution I originally proposed:

1/2-1/2 {3-fold repetition after Kh7+}

This would be atomic, backward compatible with old GUIs, which would simply treat the reason as a comment, and which could have been translated to "draw" + move towards the ICS. In the end I rejected that, because of your opposition to it, plus the fact that this would not autoomatically work on old GUIs. (Although they would not choke on it.) But now I realize that we could have required the mentioned move to e sent again:

1/2-1/2 {3-fold repetition after Kh7+}
Kh7+

This would then have worked on old and new GUIs in ICS play. In hindsight it seems a better solution. But it is too late for that now, as in the mean time we have spread GUIs that would not look at the REASON, and do flag advance 1/2-1/2 claims as false claims.

I've made the necessary change to how crafty "claims" a draw, in version 23.1. I'll just "wait and see" to determine how well it works in the general case.

I am curious. But if there are problems with the new claim sequence, we should change the GUIs, not Crafty!

Anytime I lose a game that is should be drawn, it is definitely "my problem". I'm the one losing 1/2 point. Whether it is in an important event or not doesn't matter that much.

This is a completely wrong attitude. It is trivial for me to write a GUI that would forfeit Crafty for playing e2-e4 or d2-d4, with the message "illegal move by Crafty". Would you then delete these openings from Crafty's book, just to score better on that GUI? It seems wiser to simply say: "this GUI is obviously no good". By adapting to garbage GUIs, you will slowly but surely reduce your engine to garbage as well, which will then promote the origin of more garbage GUIs that will again adapt their command handling to garbage engines, etc.

Not quite true. When I write down the move and call the arbiter over, I now am _forced_ to play that move, unless it is illegal. The arbiter should come over to verify the claim, and when he examines the position after the move I write down, looking for a 3-fold rep, he should notice that that move checkmated my opponent and ended the game.

This cannot really happen on a 3-fold rep, or you would have been checkmated 2 times before! It can only happen on a 50-move claim. And then there s no need for the referee to play the move; on the contrry, he should go backwards in the game, to count reversible moves, and if there are 99, and your move was not a Pawn's or capture, he would in theory never have to perform it to judge if it was draw...

Actually it can happen on 3-fold reps, and has at least once. I watched a speed chess game at the US Open one year where this happened. I watched another where one side's queen was left hanging for 10+ moves and no one noticed until the game ended with that side winning.

But on a 50-move case what I gave above would be a distinct possibility in a time scramble...[/quote]

[Spock]

First, I thought the same. And I lost a game when ChessGUI said "this claim is invalid, you lose."

Yes, ChessGUI is one of the few that verifies claims. But it solves the race condition by adjudicting all claimable draws, so no problem there. Just don't do any advance claiming.

Supposedly Arena is doing the same thing according to (I believe) Graham who said the same problem occurred there.

Well, I missed that, but I will investigate it by contacting Graham.

That may have been me - and I remember now, it is not this issue at all but another Crafty issue that I observed under Arena. It was simply that I cannot stop Crafty resigning, despite having resign=0 in crafty.rc

So, sorry nothing to do with the topic here, and probably nothing to do with Arena either.

[Spock]

Just to confirm, this is the situation with Arena

This is an extract of Crafty's log file

splits=736 aborts=0 data=16/512 elap=0.39
terminating SMP processes.
White(99): Bc4
time used: 0.39

+---+---+---+---+---+---+---+---+
8 | | . | | . | | . | | . |
+---+---+---+---+---+---+---+---+
7 | . | | . | | . | | . | |
+---+---+---+---+---+---+---+---+
6 | | . | | . | |-K-| | . |
+---+---+---+---+---+---+---+---+
5 | . | | . | | . | | . | |
+---+---+---+---+---+---+---+---+
4 | | . |-B-| . | |<K>| |<P>|
+---+---+---+---+---+---+---+---+
3 | . | | . | | . | | . |-P-|
+---+---+---+---+---+---+---+---+
2 | | . | | . | | . | | . |
+---+---+---+---+---+---+---+---+
1 | . | | . | |<N>| | . | |
+---+---+---+---+---+---+---+---+
a b c d e f g h

Black(99): time 11173
time remaining: 1:51 (Crafty).
Black(99): otim 10668
time remaining: 1:46 (opponent).
Black(99): Nc2
time used: 6.13
time surplus 17.23 time limit 3.99 (+0.00) (37.24)
depth time score variation (1)
starting thread 1
starting thread 2
starting thread 3
59-> 0.07 0.01 100. Bd5
60 0.07 0.01 100. Bd5
60-> 0.16 0.01 100. Bd5
time=0.16 mat=0 n=1171006 fh=99% nps=7.3M
ext-> check=39K qcheck=127 reduce=874K/835K
predicted=0 evals=1K 50move=61 EGTBprobes=944 hits=944
SMP-> splits=514 aborts=1 data=17/512 elap=0.16
terminating SMP processes.
I claim a draw by 3-fold repetition after my move.
1/2-1/2 {Drawn by 3-fold repetition}
offer draw
White(100): Bd5
time used: 0.16

+---+---+---+---+---+---+---+---+
8 | | . | | . | | . | | . |
+---+---+---+---+---+---+---+---+
7 | . | | . | | . | | . | |
+---+---+---+---+---+---+---+---+
6 | | . | | . | |-K-| | . |
+---+---+---+---+---+---+---+---+
5 | . | | . |-B-| . | | . | |
+---+---+---+---+---+---+---+---+
4 | | . | | . | |<K>| |<P>|
+---+---+---+---+---+---+---+---+
3 | . | | . | | . | | . |-P-|
+---+---+---+---+---+---+---+---+
2 | | . |<N>| . | | . | | . |
+---+---+---+---+---+---+---+---+
1 | . | | . | | . | | . | |
+---+---+---+---+---+---+---+---+
a b c d e f g h

Black(100): ?
Black(100): result 1/2-1/2
Black(100): ?
Black(100): force
Black(100): quit

the end of the Arena pgn

100. Bd5 {+0.01/60 0 3-fold repetition} 1/2-1/2

[bob]

First, I thought the same. And I lost a game when ChessGUI said "this claim is invalid, you lose."

Yes, ChessGUI is one of the few that verifies claims. But it solves the race condition by adjudicting all claimable draws, so no problem there. Just don't do any advance claiming.

Supposedly Arena is doing the same thing according to (I believe) Graham who said the same problem occurred there.

Well, I missed that, but I will investigate it by contacting Graham.

That may have been me - and I remember now, it is not this issue at all but another Crafty issue that I observed under Arena. It was simply that I cannot stop Crafty resigning, despite having resign=0 in crafty.rc

So, sorry nothing to do with the topic here, and probably nothing to do with Arena either.

I use resign=0 all the time. What specific problem are you seeing? It might be that arena has other settings it uses, but the "resign=0" must work in Crafty.

If you look at "resign.c" you will notice that if the variable "resign" is set to zero previously, the "resign counter" is never incremented and the "resign" message is never displayed. If you look at option.c for the "resign" command, you will find that it sets "resign" to the value you pass as an argument.

I play online with resign=0 regularly and it works for me...

You could test your version by setting up a position with KQ vs K, you have the Q, and make several moves without trying to mate Crafty, It should resign pretty quickly (after 5 moves I believer). Now set it up again, but before starting, type "resign=0" and see if it resigns after 5 moves this time. Mine does not.

[Uri Blass]

I understand that Bob does not like the fact that he cannot claim a draw before making a move and offering a draw is not claiming the draw.

I hope that the following will make Bob happy:

from the winboard protocol from
9. Commands from the engine to xboard

tellall MESSAGE
This command lets the engine give a message to its opponent and other people watching the game, independent of whether the opponent is a user on the local machine or a remote ICS user (Zippy mode). MESSAGE consists of any characters, including whitespace, to the end of the line. When the engine is playing against a user on the local machine, xboard pops up an information dialog containing the message. When the engine is playing against an opponent on the ICS (Zippy mode), xboard sends "kibitz MESSAGE\n" to the ICS.


I think that it is possible to add before making the move in tellall MESSAGE:

"I claim a draw by 3-fold repetition after my next move"

It means that the order is going to be as follow for Crafty

1)offer a draw(to prevent problems with ICS that may not accept the draw otherwise)
2)tellall:"my next move is XXX and I claim a draw by 3-fold repetition after it"
3)make XXX
4)claim a draw

3 and 4 are needed only because interfaces today do not understand 2 and it is possible to have a new protocol when 3 and 4 are not needed but the engine cannot assume it unless the interface tell it protover 3 in the beginning(assuming protover 3 means it).

Uri

[hgm]

OK, I have the last version of the engine.intf document Tim released. Please tell me where in that protocol it explains that I need to send the following:

offer draw
move xyz
1/2-1/2

when I intend to _claim_ a draw by repetition after my move. Here is what my engine.intf states:

offer draw
If your engine wants to offer a draw by agreement (as opposed to claiming a draw by rule), it can send the command "offer draw". xboard relays the offer to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. In Machine White, Machine Black, or Two Machines mode, the offer is considered valid until your engine has made two more moves.

It says it relays the draw offer to the ICS, doesn't it? And this is what you want to acheive, send "draw" to the ICS _before_ your move. It is not my fault that the ICS wants to receive a draw offer before the move to grant a claim after it.

That I changed the handling of draw offers in local play, to have the GUI automatically grant a claimable draw when one of the players has already expressed it wants a draw, is not realy a matter of the protocol. It is just a more logical and convenient handling of handling draw claims in general.

Also note that this is not the entire description of the offer draw command in the Tim Mann document: another part of the description you can find under the draw command. The document fails to give a cross reference here.

Now do you claim your "offer draw" kludge meets the winboard specification? I claim it does not. In fact, it explicitly states above "offer a draw as opposed to claiming a draw by rule". This is the problem I was addressing.

Specs say, and always have been saying, that the engine _must_ send a RESULT command when it detects that the games is _definitely_ over. When you stick to that, it is my job to make sure that engines that stick to that acheive the intended effect, and I can do whatever it takes to make that happen, without informing you.

No argument. But the specs have never said that I must send "offer draw" before the move I want to claim a draw after.

Effects of violating the protocol are not strictly defined in the specs. (It would be stupid to do that, as it would make extension of the protocol in a backward compatible way impossible.) This means you cannot rely on protocol-violating behavior having the same effect in future implementations. But if my new implementation chances the behavior of protocol violations that I discover to be in common use, I have the courtesy to warn people aganst it.

Which suits me just fine. When I have time I will try the just modified version of Crafty and play a million almost instant games to see if there is any remaining issue...

Great. Don't forget to safe the GUI debug files for games where you encounter a GUI bug, so it can be sent to the respective GUI author, and they can fix it. Just coming with the statement "it did not work" after a million games is not helpful.

Rest assured: GUIs do contain bugs, and wil probably always contain bugs. Even the other day one was reported in the WinBoard forum, where a forfeit on time was incorrectly "corrected' to a draw, because the forfeiting side was facing a bare King (while in fact it was facing KRP). This was likely caused by setting up the board for the new position, and incrementing the move number in the wrong order, so that the GameEnd() routine invoked by the clock interrupt was testing an incomplete board. An extremely rare occurrence, but in a million game you might pobably see a few.

Oh yeah? And which version was that? From before you wrote Cray Blitz?

The version I am currently using, before modification.

They have numbers, you know. Look in the "Help -> About" menu. "I am currently using" and "before modifiction" are totally meaningless descriptions. Of course you are using the version that you are currently using. And it is being modified ever since version 0.0.0...

as I mentioned, 4.2.6

1/2-1/2 after a move was problematic because of the race condition. That's why I brought this up the _last_ time this discussion was held.

Currently in ChessGUI, it appears that 1/2-1/2 is irrelevant. As is 1-0 and 0-1, because ChessGUI declares the game over without the program's knowledge, which is fine for normal testing, but not so fine for tuning before playing in a human event.

So apparently, some where in xboard/winboard, when you get the 1/2-1/2, you notice that my opponent has made a move that invalidated the claim, and you then quickly back up to the position prior to his move to see if the 1/2-1/2 is valid? And if so, you end the game.

Exactly. Like I have written about five times before in the two current discussions. Let's hope it sinks in this time.

If not, what?

If not, the game is terminated for reasons of a "false claim", if the user has ticked this option and it is a comp-comp game. Otherwise (of the user prefers it or the opponent is a Human) the old behavior of accepting the claim anyway occurs (and I don't even bother to backup the move and check). This stil terminates the game, but with a draw result for whatever (false) reason the engine gave. If the opponent is an ICS, the old behavior of relaying the 1/2-1/2 as an ICS "draw" command to the ICS occurs.

So you are saying that _no_ GUI will reject a 1/2-1/2, even if it thinks it is incorrect? All I can do here is offer my congratulations for knowing what every gui out there does.

You miss the nuance. _Known_ GUI. Known to me...

"known" generally applies to _everyone_ in that kind of statement.

We at least know that ChessGUI will turn an incorrect draw claim into a loss. It only avoids this problem by ending the game itself before the race condition shows up. But do you _really_ know that the other many GUIs out there, of which there are a bunch, do not check the correctness of a claim to end the game before doing so? I know of one that does. I use it every day on my cluster. I just don't turn bogus claims into losses, I ignore them. But if anybody checks the correctness, and is not aware of the race condition (which it appears most have no idea that such a problem exists) then they are going to have this problem. And the current protocol description does not explicitly tell them what to do to solve the problem, as it doesn't even mention the problem.

The protocol specs are not intended as a "one-page course to GUI programming". But I am not against attaching a small warning for GUI programmers to the description of the RESULT command. How about this:

Note to GUI programmers: RESULT commands that the engine sends immediately after its move might be detected by the GUI only after the opponent has moved, because of communication and scheduling delays, no matter how fast the engine sent it. Any judgement of the validity of RESULT claims based on te "current" board position will have to account for this uncertainty.

Actually a protocol _must_ be a "one page course to GUI programming with respect to the protocol usage." Otherwise one could never write a TCP/IP program that worked. Or a POSIX thread application.