xboard protocol - a compromise that would work

[bob]

But what idiot would send 1/2-1/2 _AFTER_ the move, when there is a reasonable chance that is equivalent to "resign"? Because of the race condition.

There is no reasonable chance.

There is no known GUI that would make it equivalent to "resign" if you use it when you use it according to the specs.

Then explain how you solve this. My opponent makes 50 reversible moves. I make my 50th reversible move, by playing Qh7+. I then send 1/2-1/2 which is perfectly valid. But my opponent plays Kxh7 instantly and you read that before my draw claim. You send that move to me, and now see my draw claim and say "not valid, you lose."

How do you fix that? Because the _last_ time we had this discussion, that was _exactly_ the problem I had found and reported here and opened a discussion to get it fixed properly. If you have fixed it and said nothing, fine. That's what I wanted. But by saying nothing, what about the other GUIs that are unaware of the issue and have not fixed it. You have changed the semantics of the protocol if you have fixed it, and you have told no one so how can they be compatible?

Hardly any GUI would equate false claims to forfeits anyway, and those that do make sure they account for te race condition.

You worry for nothing. That is paranoia.

Have you been following this discussion? First, last time I tried a new version of xboard, it did _not_ fix this problem. 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.

The problem with ChessGUI only originates because you resort to illegal use of the 1/2-1/2 command. Do not use it for advance claims or false claims, and you will safe.

So it is your opinion that current versions of ChessGUI will properly deal with the 1/2-1/2 after a move, and not fall prey to the race condition, and decide that the draw claim is invalid and forfeit the engine? That is not what I have been reading in the author's comments...

It _is_ a problem. And it is a problem in xboard/winboard unless you have silently fixed this over the past year somewhere.

BTW, current XBoard will also forfeit you for illegal moves. Does that mean you must be an idiot to make a move, if there is a reasonable chance that it will be taken as equivalent to "resign"? Or do you have confidence that your engine will be abe to pick legal moves?

Perhaps one day you will get the point. If I can not safely send 1/2-1/2 _AFTER_ I make a move, to say "the game is over after my move" then I would be an idiot to send it ever. Crafty doesn't make illegal moves. So that is not an issue. 1/2-1/2 is not illegal or invalid after I make a move that satisifies a drawn game definition. But it is unreliable due to the race condition.

[hgm]

Which means the 1/2-1/2 is unusable, it would seem, because of the well-known race condition between the draw claim (1/2-1/2) and the opponent's move, either of which xboard could receive and process first.

This is not your problem, but that of the GUI author. Stick to the protocol, and trust that the GUI will make _sure_ that you are _never_ wronged.

No. I have used xboard for several years to test against other engines. I had found the "invalid result" problem many years ago where programs would screw up the 1-0 vs 0-1 when playing black.

Well, this is what I m saying, so I don't understand your "no". But this is an entirely unrelated problem. It has nothing to do with race conditions, and you cannot avoid it by abstaining from using 1/2-1/2. Because it is the opponent that will continue to make those mistakes, and stupid old GUIs that continue to fall for it.

My version of xboard will accept results from Crafty, but not from any opponent.

Well, nice for you, but not usable for a GUI. It mght be inconceivable for you, but some people want to play games where Crafty is _not_ one of the players.

My original referee did this and all worked perfectly. Until someone wanted to see me play a big round-robin which would mean Crafty would not participate in every game played. I then had to modify my referee to keep the game state and end the game on 50-move rule draws or repetitions, regardless of what the players did or did not claim. It's amazing to me how many existing programs are unaware of the 50 move rule, as one example.

Yes, indeed. And at 1300 Elo that is 100 times worse. This is why I added the options -checkMates, -testClaims, and -materialDraws to XBoard, so that you don't have to depend on any claim, if you don't want to.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose.

There is no known GUI that has this behavior.

If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

Yes. So don't do it.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

Nonsense.

[wgarvin]

Anyone can bury their head in the sand. I have identified a significant problem in the protocol, and have explained it as clearly as I know how. If they are not willing to fix it, then I would not care if they survive or not. We don't keep an old protocol with a bug, rather than fixing the bug, simply because some are not willing to support it. We have a bug _either_ way. At least as GUIs adopt the new command or new semantics, whichever is changed, the race condition slowly goes away. Right now it is there, and I'd bet a bunch that most have no idea it is there prior to this discussion. And games have been lost when they should have been drawn as a result. And nobody knows.

Makes no sense to ignore that.

Unfortunately, the software using protover 2 is written by dozens or even hundreds of different people. Some of them will have abandoned maintenance of their engines and GUIs and will be unwilling to change them. Even for the ones that were updated, old versions would still exist and would be in users hands. This is what hgm was getting at, and so I apologize for belaboring the point here.

The very definition of "backward compatibility" is that new stuff continues to work with old stuff. If we change the protocol and start making new engines and GUIs that work with it, they still need to be able to talk to many of the old GUIs and engines that are out there. Using the "feature" command, the engine and the GUI can negotiate about what behaviour to use. But old GUIs will not recognize a new "feature", so even new engines will need to be able to work with the OLD behaviour of the GUIs. Even if you want to write a new engine that refuses to run with old GUIs, you need something (such as a "rejected" feedback about the new feature) to help you identify the old GUIs.

All of this is saying, that we can't unconditionally add "draw" to the protocol without breaking backward compatibility. We could however add "draw" to the protocol along with a "feature draw" which the old GUIs would reject, the new GUIs would accept, the new engines would only send if the GUI accepted the feature, and the new GUIs would only require if the engine requested the feature. The new GUIs would still have to support the old behaviour (e.g. detecting draws in positions before AND after the move, and allowing the claim for either one) for old engines, although they could switch that behaviour off if the engine was a new engine that somehow promised not to rely on it (such as by sending "feature draw"). But new engines would still need to be able to send the old "offer draw", "move ...", "1/2-1/2 {...}" sequence if their feature was not accepted---in other words, when talking to an old GUI.

Perhaps one day you will get the point. If I can not safely send 1/2-1/2 _AFTER_ I make a move, to say "the game is over after my move" then I would be an idiot to send it ever. Crafty doesn't make illegal moves. So that is not an issue. 1/2-1/2 is not illegal or invalid after I make a move that satisifies a drawn game definition. But it is unreliable due to the race condition.

I think sending 1/2-1/2 (yes, after your drawing move) is the only way to tell "dumb" GUIs, such as the really old xboard, that the game is definitely over now. So you should include that after your drawing move, in addition to sending "offer draw" before that move. If you claim that the game has ended, "dumb" GUIs will believe you. If you don't send that result string, then they might simply relay "offer draw" to your opponent, who might also be unable or unwilling to accept.

[Edit: actually... if "dumb" GUIs believe you unconditionally, then you should not have a problem with the race condition there. I guess the race condition is only a problem with GUIs that try to validate a draw claim in some fashion.]

But as far as ICS or modern "smart" GUIs are concerned, they should already have ended the game by then because of "offer draw" followed by your move which produced the position in which the draw could be claimed. Since Crafty doesn't make incorrect draw claims, and there is no race condition with the smart GUIs if the "offer draw" was sent before the move... it should be impossible for Crafty to be penalized for sending 1/2-1/2 unless there is a bad bug in the GUI.

[hgm]

What part of the concept "protocol" don't you understand? No part is optional to the GUI. We do allow programs to select bits and pieces of the protocol via the "feature" commands. But the GUI must handle them all or it is non-compliant.

The part that says v2? That said "backward compatibility"?

OK, so all GUIs will be non-compliant, after you wave your magic wand. So now what are you going to do against that? One driver going opposit the trafic in the wrong lane? You will see thousands!

If we fix a way to claim a draw that works logically and reliably, I will be happy. The last time we had this same discussion I suggested fixing 1/2-1/2. So that it could be properly interpreted without worrying/caring about the potential race condition with my opponent's next move. That went nowhere. Your statement was that the result will end the game. Let's go with that. But make it work correctly so that 1/2-1/2 will never turn into 1-0/0-1 just because my opponent's move beat my draw claim to the GUI.

It has been working like that for ages. Wake up.

If you can make that work, and everyone else does as well because the protocol definition is modified to make this perfectly clear as to how the 1/2-1/2 is treated, all will be well.

Instead of nagging like a child, name me a single GUI were you were forfeited for using 1/2-1/2 _after_ the drawing move. You seem totally out of touch with reality.

Anyone can bury their head in the sand. I have identified a significant problem in the protocol, and have explained it as clearly as I know how.

You have identified a problem that only exists in your mind, as it was removed from the protocol long ago.

If they are not willing to fix it, then I would not care if they survive or not.

Why would they fix something that is not broken, except in your nightmares?

We don't keep an old protocol with a bug, rather than fixing the bug, simply because some are not willing to support it. We have a bug _either_ way. At least as GUIs adopt the new command or new semantics, whichever is changed, the race condition slowly goes away. Right now it is there,

It is only there because they are very slow to adapt the "new semantics", which isn't even really new. But there is nothing we can do about that. There are things we can do to encourage them to be slow, though. And _you_ are doing them...

and I'd bet a bunch that most have no idea it is there prior to this discussion. And games have been lost when they should have been drawn as a result. And nobody knows.

Indeed. As it is most likely not true. I will make it really easy for you. Show us one such game.

Makes no sense to ignore that.

[hgm]

Then explain how you solve this. My opponent makes 50 reversible moves. I make my 50th reversible move, by playing Qh7+. I then send 1/2-1/2 which is perfectly valid. But my opponent plays Kxh7 instantly and you read that before my draw claim. You send that move to me, and now see my draw claim and say "not valid, you lose."

How do you fix that? Because the _last_ time we had this discussion, that was _exactly_ the problem I had found and reported here and opened a discussion to get it fixed properly. If you have fixed it and said nothing, fine. That's what I wanted. But by saying nothing, what about the other GUIs that are unaware of the issue and have not fixed it. You have changed the semantics of the protocol if you have fixed it, and you have told no one so how can they be compatible?

Do you ever read what I write? You keep asking the very same question, no matter how many times I have already answered it. Normally, answering it once hould be enough.

Read back and find the answer. I described exactly how XBoard treats the 1/2-1/2 command. (Five times.... )

Hardly any GUI would equate false claims to forfeits anyway, and those that do make sure they account for te race condition.

You worry for nothing. That is paranoia.

Have you been following this discussion? First, last time I tried a new version of xboard, it did _not_ fix this problem.

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

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.

So it is your opinion that current versions of ChessGUI will properly deal with the 1/2-1/2 after a move, and not fall prey to the race condition, and decide that the draw claim is invalid and forfeit the engine? That is not what I have been reading in the author's comments...

The way I understood his comments, he said there was not even a race condition, as ChessGUI declares draws automatically, even in the absense of claims. And I tend to believe him more than I believe you, for most what you initially said about it turned out to be completely false (factual things, like what Crafty sends, what is in the protocol description, you name it).

It _is_ a problem. And it is a problem in xboard/winboard unless you have silently fixed this over the past year somewhere.

To the deaf, silence is omnipresent...

Perhaps one day you will get the point. If I can not safely send 1/2-1/2 _AFTER_ I make a move, to say "the game is over after my move" then I would be an idiot to send it ever. Crafty doesn't make illegal moves. So that is not an issue. 1/2-1/2 is not illegal or invalid after I make a move that satisifies a drawn game definition.

So it will never be penalized. We only penalize illegal moves and provably false claims. But I don't even dare to hope that perhaps one day you wil get _that_ point...

But it is unreliable due to the race condition.

[bob]

Which means the 1/2-1/2 is unusable, it would seem, because of the well-known race condition between the draw claim (1/2-1/2) and the opponent's move, either of which xboard could receive and process first.

This is not your problem, but that of the GUI author. Stick to the protocol, and trust that the GUI will make _sure_ that you are _never_ wronged.

No. I have used xboard for several years to test against other engines. I had found the "invalid result" problem many years ago where programs would screw up the 1-0 vs 0-1 when playing black.

Well, this is what I m saying, so I don't understand your "no". But this is an entirely unrelated problem. It has nothing to do with race conditions, and you cannot avoid it by abstaining from using 1/2-1/2. Because it is the opponent that will continue to make those mistakes, and stupid old GUIs that continue to fall for it.

My version of xboard will accept results from Crafty, but not from any opponent.

Well, nice for you, but not usable for a GUI. It mght be inconceivable for you, but some people want to play games where Crafty is _not_ one of the players.

I realize that. But _I_ want to play games where I get results that help me, not random results caused by bogus result messages.

My original referee did this and all worked perfectly. Until someone wanted to see me play a big round-robin which would mean Crafty would not participate in every game played. I then had to modify my referee to keep the game state and end the game on 50-move rule draws or repetitions, regardless of what the players did or did not claim. It's amazing to me how many existing programs are unaware of the 50 move rule, as one example.

Yes, indeed. And at 1300 Elo that is 100 times worse. This is why I added the options -checkMates, -testClaims, and -materialDraws to XBoard, so that you don't have to depend on any claim, if you don't want to.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose.

There is no known GUI that has this behavior.

If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

Yes. So don't do it.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

Nonsense.

[bob]

Then explain how you solve this. My opponent makes 50 reversible moves. I make my 50th reversible move, by playing Qh7+. I then send 1/2-1/2 which is perfectly valid. But my opponent plays Kxh7 instantly and you read that before my draw claim. You send that move to me, and now see my draw claim and say "not valid, you lose."

How do you fix that? Because the _last_ time we had this discussion, that was _exactly_ the problem I had found and reported here and opened a discussion to get it fixed properly. If you have fixed it and said nothing, fine. That's what I wanted. But by saying nothing, what about the other GUIs that are unaware of the issue and have not fixed it. You have changed the semantics of the protocol if you have fixed it, and you have told no one so how can they be compatible?

Do you ever read what I write? You keep asking the very same question, no matter how many times I have already answered it. Normally, answering it once hould be enough.

Read back and find the answer. I described exactly how XBoard treats the 1/2-1/2 command. (Five times.... )

Read back to last year where you said "I am not changing the way the result command is handled..."

Apparently you silently decided to do just that. 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...

Hardly any GUI would equate false claims to forfeits anyway, and those that do make sure they account for te race condition.

You worry for nothing. That is paranoia.

Have you been following this discussion? First, last time I tried a new version of xboard, it did _not_ fix this problem.

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

The version I am currently using, before modification.

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.

So it is your opinion that current versions of ChessGUI will properly deal with the 1/2-1/2 after a move, and not fall prey to the race condition, and decide that the draw claim is invalid and forfeit the engine? That is not what I have been reading in the author's comments...

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.

The way I understood his comments, he said there was not even a race condition, as ChessGUI declares draws automatically, even in the absense of claims. And I tend to believe him more than I believe you, for most what you initially said about it turned out to be completely false (factual things, like what Crafty sends, what is in the protocol description, you name it).

It _is_ a problem. And it is a problem in xboard/winboard unless you have silently fixed this over the past year somewhere.

To the deaf, silence is omnipresent...

Perhaps one day you will get the point. If I can not safely send 1/2-1/2 _AFTER_ I make a move, to say "the game is over after my move" then I would be an idiot to send it ever. Crafty doesn't make illegal moves. So that is not an issue. 1/2-1/2 is not illegal or invalid after I make a move that satisifies a drawn game definition.

So it will never be penalized. We only penalize illegal moves and provably false claims. But I don't even dare to hope that perhaps one day you wil get _that_ point...

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. If not, what?

But it is unreliable due to the race condition.

[Matthias Gemuh]

Yes, and then, by magic, all old GUIs disappear from the surface of the Earth. Get real!

Or they simply fix their GUI to match the protocol.

The problem is that some old GUIs won't/can't upgrade.

Matthias.

[bob]

Which means the 1/2-1/2 is unusable, it would seem, because of the well-known race condition between the draw claim (1/2-1/2) and the opponent's move, either of which xboard could receive and process first.

This is not your problem, but that of the GUI author. Stick to the protocol, and trust that the GUI will make _sure_ that you are _never_ wronged.

No. I have used xboard for several years to test against other engines. I had found the "invalid result" problem many years ago where programs would screw up the 1-0 vs 0-1 when playing black.

Well, this is what I m saying, so I don't understand your "no". But this is an entirely unrelated problem. It has nothing to do with race conditions, and you cannot avoid it by abstaining from using 1/2-1/2. Because it is the opponent that will continue to make those mistakes, and stupid old GUIs that continue to fall for it.

My version of xboard will accept results from Crafty, but not from any opponent.

Well, nice for you, but not usable for a GUI. It mght be inconceivable for you, but some people want to play games where Crafty is _not_ one of the players.

My original referee did this and all worked perfectly. Until someone wanted to see me play a big round-robin which would mean Crafty would not participate in every game played. I then had to modify my referee to keep the game state and end the game on 50-move rule draws or repetitions, regardless of what the players did or did not claim. It's amazing to me how many existing programs are unaware of the 50 move rule, as one example.

Yes, indeed. And at 1300 Elo that is 100 times worse. This is why I added the options -checkMates, -testClaims, and -materialDraws to XBoard, so that you don't have to depend on any claim, if you don't want to.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose.

There is no known GUI that has this behavior.

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. 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.

If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

Yes. So don't do it.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

Nonsense.

[Uri Blass]

Which means the 1/2-1/2 is unusable, it would seem, because of the well-known race condition between the draw claim (1/2-1/2) and the opponent's move, either of which xboard could receive and process first.

This is not your problem, but that of the GUI author. Stick to the protocol, and trust that the GUI will make _sure_ that you are _never_ wronged.

No. I have used xboard for several years to test against other engines. I had found the "invalid result" problem many years ago where programs would screw up the 1-0 vs 0-1 when playing black.

Well, this is what I m saying, so I don't understand your "no". But this is an entirely unrelated problem. It has nothing to do with race conditions, and you cannot avoid it by abstaining from using 1/2-1/2. Because it is the opponent that will continue to make those mistakes, and stupid old GUIs that continue to fall for it.

My version of xboard will accept results from Crafty, but not from any opponent.

Well, nice for you, but not usable for a GUI. It mght be inconceivable for you, but some people want to play games where Crafty is _not_ one of the players.

My original referee did this and all worked perfectly. Until someone wanted to see me play a big round-robin which would mean Crafty would not participate in every game played. I then had to modify my referee to keep the game state and end the game on 50-move rule draws or repetitions, regardless of what the players did or did not claim. It's amazing to me how many existing programs are unaware of the 50 move rule, as one example.

Yes, indeed. And at 1300 Elo that is 100 times worse. This is why I added the options -checkMates, -testClaims, and -materialDraws to XBoard, so that you don't have to depend on any claim, if you don't want to.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose.

There is no known GUI that has this behavior.

So you are saying that _no_ GUI will reject a 1/2-1/2, even if it thinks it is incorrect?

No
I understand that
H.G.M is saying that no existing gui is going to reject a draw claim after making a move that leads to draw by repetition or the fifty move rule.

The only funny exception(mentioned originally by H.G.Muller) that is not what you meant may be if the move mates the opponent and also leads to 100 plies with no conversion and unlike human play this is a case to care about because computers may claim a draw by the 50 move rule because of a bug even when they mate the opponent and it is not clear if the gui should give a draw or a win for the engine.

I understood that in computer games the only case of rejecting 1/2-1/2 because the opponent made a move is in ICS and
I see no problem even with ICS if you simply add offer a draw before making the move when you simply claim a draw after it.

Uri