Hello H.G.Muller : upgrading the protocol

[hgm]

Code: Select all

Here's a suggestion (from Bob):

...

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

...

I agree with Bob's suggestions.
Now tell us your opinion.

Some time ago I proposed a protocol extension for sending move + draw claim in an atomic way that had better backward compatibility than this new suggestion:

1/2-1/2 {3-fold repetiton after Rh7+}

Bob, however, was against this, and convinced me that it woud be better to overload the offer draw command for this purpose, because it reflects the way that an ICS handles it, and it would be undesirable to require the behavior of an engine to be different in ICS play than in local play.

So the protocol for handling this sitution now is to send

offer draw
move Rh7+

on which the GUI should terminate the game as a draw if a draw condition (50-move or 3-fold rep) exists after Rh7+.

If the draw condition already exists before the move, the GUI could also interpret the offer draw as a claim, although it would be perfectly valid for the engine to terminate the game by itself through

1/2-1/2 {3-fold rep}

without sending any move, in that case.

If there is no draw condition either before or after the move, the offer draw is relayed to the opponent just before the move, in perfect agreement with the FIDE rules, which stipulate that a draw claim is also a draw offer.

I think this completely solves eveything, and see no need for a protocol extension.

Note that WinBoard 4.3 gives some leeway to engines making 'false' draw claims because they use the alternative way of claiming (1/2-1/2 after having sent their move) that is unsafe w.r.t. the race condition: if a 1/2-1/2 command gets in after the opponent has moved, WinBoard judges the validity of the claim not only based on the position after this move, but also on the one before it. Ths because it is conceivable the opponent has just sneeked in a move between the claiming engine's move and the claim. Although this in principle can be exploited by cheating engines (delaying their claim until after the opponent has moved, and only stake it when the move is good), I figured that if the penalty is forfeit, it is better to let the cheaters get away than to unjustly forfeit faithful engines that happen to be unlucky because of a communication delay. (The fact that I do not know a singe engine that cheats tis way, and that I consider it extremely unikely one will ever e built, made this an easy decision... ) But an ICS might not be so forgiving, so it is recommended to use the offer draw mechanism in stead.

[Matthias Gemuh]

If there is no draw condition either before or after the move, the offer draw is relayed to the opponent just before the move, in perfect agreement with the FIDE rules, which stipulate that a drw claim is also a draw offer.

I think this completely solves eveything, and see no need for a protocol extension.

Summarizing:
- GUI receives draw claim/offer
- if the claim/offer is 3-fold-rep or 50-move rule, and draw condition OTB, terminate game or if not, relay claim/offer to opponent immediately, ignoring the "hit clock" stuff.
- if the claim/offer is 3-fold-rep or 50-move rule, and no draw condition OTB, wait for move, ignoring the "hit clock" stuff. When move arrives and fulfills draw condition, terminate game or if not, relay claim/offer and move to opponent. If move does not fulfill draw condition, ignore the claim/offer and relay only move to opponent.
- if the offer is neither 3-fold-rep nor 50-move rule, relay immediately, expecting a move from one side or draw agreement from other side.

right ?

Matthias.

[Matthias Gemuh]

BTW, ChessGUI must ignore all this draw stuff if the opponent is an UCI engine. WB engines should note that.

Matthias.

[hgm]

WinBoard 4.3 holds up all draw offers untill the offerer also gives a move. I don't want it to be possible for the opponent's thinking to be disturbed by draw offers; this could be abused. I think this is also not allowed in Human play: you have to make the offer in your own time, usually done just before pressing your clock. (It would be stupid to allow him to consider the offer in your time.)

So:

1) When an engine sends "offer draw", if there is a draw condition on the board(*), or a pending draw offer of the opponent, the GUI grants a draw. If not, it logs it as a pending draw offer, valid for 2 ply.
2) When a move comes in, the GUI checks if it brings a draw condition on the board before relaying that move to the opponent. If it does, and there is a draw offer pending, it grants a draw. The move is sent to the opponent in force mode before sending the result command. (This sending of the move is new in 4.3.16, for the benefit of engines that learn.) This also happens if there was no pending offer (=claim), but the GUI is under instruction to adjudicate on draw conditions. If there is no draw condition brought about by the move, the draw offer is sent to the opponent just before time and move are sent.

Currently WinBoard does not check for the draw conditions marked with (*), because it assumes the engine would use the 1/2-1/2 command to end the game here (as it is te opponent who apparently brought about the repetition, or we would have claimed it earlier). But it would probaby be more logical if it would.

[Matthias Gemuh]

WinBoard 4.3 holds up all draw offers untill the offerer also gives a move. I don't want it to be possible for the opponent's thinking to be disturbed by draw offers; this could be abused. I think this is also not allowed in Human play: you have to make the offer in your own time, usually done just before pressing your clock. (It would be stupid to allow him to consider the offer in your time.)

So:

1) When an engine sends "offer draw", if there is a draw condition on the board(*), or a pending draw offer of the opponent, the GUI grants a draw. If not, it logs it as a pending draw offer, valid for 2 ply.
2) When a move comes in, the GUI checks if it brings a draw condition on the board before relaying that move to the opponent. If it does, and there is a draw offer pending, it grants a draw. The move is sent to the opponent in force mode before sending the result command. (This sending of the move is new in 4.3.16, for the benefit of engines that learn.) This also happens if there was no pending offer (=claim), but the GUI is under instruction to adjudicate on draw conditions. If there is no draw condition brought about by the move, the draw offer is sent to the opponent just before time and move are sent.

Currently WinBoard does not check for the draw conditions marked with (*), because it assumes the engine would use the 1/2-1/2 command to end the game here (as it is te opponent who apparently brought about the repetition, or we would have claimed it earlier). But it would probaby be more logical if it would.

You are truely the Winboard man

Matthias.

[bob]

Code: Select all

Here's a suggestion (from Bob):

...

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

...

I agree with Bob's suggestions.
Now tell us your opinion.

Some time ago I proposed a protocol extension for sending move + draw claim in an atomic way that had better backward compatibility than this new suggestion:

1/2-1/2 {3-fold repetiton after Rh7+}

Bob, however, was against this, and convinced me that it woud be better to overload the offer draw command for this purpose, because it reflects the way that an ICS handles it, and it would be undesirable to require the behavior of an engine to be different in ICS play than in local play.

So the protocol for handling this sitution now is to send

offer draw
move Rh7+

on which the GUI should terminate the game as a draw if a draw condition (50-move or 3-fold rep) exists after Rh7+.

If the draw condition already exists before the move, the GUI could also interpret the offer draw as a claim, although it would be perfectly valid for the engine to terminate the game by itself through

1/2-1/2 {3-fold rep}

without sending any move, in that case.

If there is no draw condition either before or after the move, the offer draw is relayed to the opponent just before the move, in perfect agreement with the FIDE rules, which stipulate that a draw claim is also a draw offer.

I think this completely solves eveything, and see no need for a protocol extension.

Note that WinBoard 4.3 gives some leeway to engines making 'false' draw claims because they use the alternative way of claiming (1/2-1/2 after having sent their move) that is unsafe w.r.t. the race condition: if a 1/2-1/2 command gets in after the opponent has moved, WinBoard judges the validity of the claim not only based on the position after this move, but also on the one before it. Ths because it is conceivable the opponent has just sneeked in a move between the claiming engine's move and the claim. Although this in principle can be exploited by cheating engines (delaying their claim until after the opponent has moved, and only stake it when the move is good), I figured that if the penalty is forfeit, it is better to let the cheaters get away than to unjustly forfeit faithful engines that happen to be unlucky because of a communication delay. (The fact that I do not know a singe engine that cheats tis way, and that I consider it extremely unikely one will ever e built, made this an easy decision... ) But an ICS might not be so forgiving, so it is recommended to use the offer draw mechanism in stead.

I am not anti-new-commands. My point in the previous discussion was that I can not tell whether I am playing another engine in a local match, or playing on ICS. And we at least need consistent behavior for both cases. A new command that works with local opponents and with the chess server is probably a good idea. Crafty is essentially a finite-state machine, which makes compliance with any sort of options pretty straightforward in this regard. I think the present scheme works, but I can see problems for new authors since they have likely not been playing on ICC for almost 15 years and have not seen the race conditions that are problematic.

But in any case, I am agreeable to use whatever the majority propose, in order to make the protocol less ambiguous / less unclear.

[bob]

WinBoard 4.3 holds up all draw offers untill the offerer also gives a move. I don't want it to be possible for the opponent's thinking to be disturbed by draw offers; this could be abused. I think this is also not allowed in Human play: you have to make the offer in your own time, usually done just before pressing your clock. (It would be stupid to allow him to consider the offer in your time.)

So:

1) When an engine sends "offer draw", if there is a draw condition on the board(*), or a pending draw offer of the opponent, the GUI grants a draw. If not, it logs it as a pending draw offer, valid for 2 ply.
2) When a move comes in, the GUI checks if it brings a draw condition on the board before relaying that move to the opponent. If it does, and there is a draw offer pending, it grants a draw. The move is sent to the opponent in force mode before sending the result command. (This sending of the move is new in 4.3.16, for the benefit of engines that learn.) This also happens if there was no pending offer (=claim), but the GUI is under instruction to adjudicate on draw conditions. If there is no draw condition brought about by the move, the draw offer is sent to the opponent just before time and move are sent.

Currently WinBoard does not check for the draw conditions marked with (*), because it assumes the engine would use the 1/2-1/2 command to end the game here (as it is te opponent who apparently brought about the repetition, or we would have claimed it earlier). But it would probaby be more logical if it would.

I'm not quite sure I understand that last statement. In my referee program, I keep up with 3-fold repetitions, and 50 move draws, and insufficient material draws, and can either enforce them on the spot and end the game, or I can just notice they have happened and when a program sends a draw offer while a valid draw condition exists, I end the game there. I don't really want to use the "result 1/2-1/2" from the program, because I have found way too many programs that make a false claim which can screw up a match without anyone knowing. I wanted my GUI to manage the game to make sure that a draw claim (actually an offer) is valid before ending the game, without ending the game automagically whenever the referee detects that the game could be ended if someone wants.

In short, I've learned to not trust the programs to make valid result claims and I ignore them completely. A program can resign, or checkmate its opponent (which my referee will determine without being prompted, and end the game), or stalemate its opponent, or whatever. But it can't tell me a result that differs from what my referee sees on the board. In fact, it can't tell me a result at all, it can simply claim a draw by offering a draw, if the position is a recognizable draw. Otherwise, with my referee, the game goes on.

An engine should really not be able to end the game by some sort of claim, without the referee verifying the claim, and ignoring it if it is improper. No need to resign for the program. If it won't play on, it will lose on time anyway. If it will play on after a false claim, let it do so.

[bob]

BTW, ChessGUI must ignore all this draw stuff if the opponent is an UCI engine. WB engines should note that.

Matthias.

Not sure what you mean? You can't offer a draw to a UCI engine???

[F. Bluemers]

BTW, ChessGUI must ignore all this draw stuff if the opponent is an UCI engine. WB engines should note that.

Matthias.

Not sure what you mean? You can't offer a draw to a UCI engine???

and it won't offer a draw either .

[michiguel]

Code: Select all

Here's a suggestion (from Bob):

...

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

...

I agree with Bob's suggestions.
Now tell us your opinion.

Some time ago I proposed a protocol extension for sending move + draw claim in an atomic way that had better backward compatibility than this new suggestion:

1/2-1/2 {3-fold repetiton after Rh7+}

Bob, however, was against this, and convinced me that it woud be better to overload the offer draw command for this purpose, because it reflects the way that an ICS handles it, and it would be undesirable to require the behavior of an engine to be different in ICS play than in local play.

So the protocol for handling this sitution now is to send

offer draw
move Rh7+

on which the GUI should terminate the game as a draw if a draw condition (50-move or 3-fold rep) exists after Rh7+.

If the draw condition already exists before the move, the GUI could also interpret the offer draw as a claim, although it would be perfectly valid for the engine to terminate the game by itself through

1/2-1/2 {3-fold rep}

without sending any move, in that case.

If there is no draw condition either before or after the move, the offer draw is relayed to the opponent just before the move, in perfect agreement with the FIDE rules, which stipulate that a draw claim is also a draw offer.

I think this completely solves eveything, and see no need for a protocol extension.

Note that WinBoard 4.3 gives some leeway to engines making 'false' draw claims because they use the alternative way of claiming (1/2-1/2 after having sent their move) that is unsafe w.r.t. the race condition: if a 1/2-1/2 command gets in after the opponent has moved, WinBoard judges the validity of the claim not only based on the position after this move, but also on the one before it. Ths because it is conceivable the opponent has just sneeked in a move between the claiming engine's move and the claim. Although this in principle can be exploited by cheating engines (delaying their claim until after the opponent has moved, and only stake it when the move is good), I figured that if the penalty is forfeit, it is better to let the cheaters get away than to unjustly forfeit faithful engines that happen to be unlucky because of a communication delay. (The fact that I do not know a singe engine that cheats tis way, and that I consider it extremely unikely one will ever e built, made this an easy decision... ) But an ICS might not be so forgiving, so it is recommended to use the offer draw mechanism in stead.

I completely missed this in the modified protocol because of a stupid reason (see below). My apologies.

The way is worded seems to be ok and it should work. If I am not mistaken, it is conceptually (almost) identical to what Bob or I proposed.

However, I have a little concern with compatibility with other GUIs that did not update this. For instance, how does my engine know whether it is facing Xboard (with an updated "behavior") or any other, in which it will understand offer draw but it won't behave as xboard?

Would it be possible to know this through a feature command?
feature offerdrawmaybeaclaim=1
(the name is akward, I know , I am not feeling creative now)

And Xboard will reply accepted "offerdrawmaybeaclaim"

So the engine will know what to expect. If I receive rejected, I can assume I am not dealing with xboard or a GUI that still uses an ambigous interpretation and I may decided to do something else.

I want to be absolutely sure that when I reach 50 moves, I send "offer draw" and I will not loose a game because the 50th move allow a capture and the opponent declines the offer (and the GUI behaved in an old fashion and a race condition triggered the problem).

Miguel
PS: The modifications to the protocol are in green and itlooks too similar to black in my stupid old monitor (I am an idiot).
PS2: That made me think that color blind people could miss this too (red and green will look the same). Maybe you want to consider to change the color from green to something like magenta etc. This sounds silly but the number of color blind (Green/Red) people in the population is huge.
I think this article is worth reading:
http://jfly.iam.u-tokyo.ac.jp/color/