xboard protocol - a compromise that would work

[Matthias Gemuh]

Bob did not like that "time kludge".

Matthias.

Because it will not work. You can't cure race conditions by introducing a time delay. That is what causes the race condition in the first place. Try to write a parallel search with no locks, just delays to prevent two threads from overwriting the same variable, to get a feel for the scope of the problem.

You are right about about that, of course.
The offer-move-claim sequence by HGM does look and sound weird,
but maybe one can live with it because it needs to be programmed (and well commented) only once.

A new command "hit clock" would be neat and straightforward, with no moves to take back and no messy comparing of moves with previous and next ones. The messy method would serve only already existing engines.
If I were in charge of the WB protocol, "hit clock" would have no alternative. "hit clock" is neat too for time management inside GUI.

Matthias.

[bob]

It would seem to me the obvious answer is to alias "1/2-1/2" to "offer draw" in GUIs that are capable of arbitration.

Or to claim a draw. Which is what I had originally suggested the last time this discussion erupted. There is a problem, and the problem is not that obvious to some that are not experienced with the concept of race condition (see how many propose a short time "delay" as a solution, for example). If a user doesn't see the problem due to experience, then the solution is also not apparent. As a result, a protocol that is logical would make sense.

If I were directing a tournament (and this has happened to me a couple of times in the past) I can deal with a foreign person that can say "draw". I can look at the board, at the score sheet, and figure out what he wants to say but can't. Because I have context to go along with the single word "draw". That's what I am proposing here. I'd find it acceptable to drop "offer" which I'd bet hardly any one uses anyway since very few programs actually offer draws anyway.

[michiguel]

Bob did not like that "time kludge".

Matthias.

Because it will not work. You can't cure race conditions by introducing a time delay. That is what causes the race condition in the first place. Try to write a parallel search with no locks, just delays to prevent two threads from overwriting the same variable, to get a feel for the scope of the problem.

You are right about about that, of course.
The offer-move-claim sequence by HGM does look and sound weird,
but maybe one can live with it because it needs to be programmed (and well commented) only once.

A new command "hit clock" would be neat and straightforward, with no moves to take back and no messy comparing of moves with previous and next ones. The messy method would serve only already existing engines.
If I were in charge of the WB protocol, "hit clock" would have no alternative. "hit clock" is neat too for time management inside GUI.

Matthias.

What has been called "hit clock" in this thread, it is actually "execute" all the previous non atomic commands. For instance, when you claim a draw, you do not hit the clock, you stop it. I think Tony's idea will be a bit more flexible to be adapted in other similar hypothetical situations and bit less verbose. Ending each command with ';' will make it to be executed. A series of commands without ; will become atomic when one of the commands end with ;
In this context, ';' will be a synonym of hit clock.

Having said this, "hit clock" "execute" or ";" are not needed if the events that are supposed to be one entity are made into one single atomic command. For instance, "drawclaim move" it is one event in which the move and the claim goes together.

Miguel

[Matthias Gemuh]

You are right about about that, of course.
The offer-move-claim sequence by HGM does look and sound weird,
but maybe one can live with it because it needs to be programmed (and well commented) only once.

A new command "hit clock" would be neat and straightforward, with no moves to take back and no messy comparing of moves with previous and next ones. The messy method would serve only already existing engines.
If I were in charge of the WB protocol, "hit clock" would have no alternative. "hit clock" is neat too for time management inside GUI.

Matthias.

What has been called "hit clock" in this thread, it is actually "execute" all the previous non atomic commands. For instance, when you claim a draw, you do not hit the clock, you stop it. I think Tony's idea will be a bit more flexible to be adapted in other similar hypothetical situations and bit less verbose. Ending each command with ';' will make it to be executed. A series of commands without ; will become atomic when one of the commands end with ;
In this context, ';' will be a synonym of hit clock.

Having said this, "hit clock" "execute" or ";" are not needed if the events that are supposed to be one entity are made into one single atomic command. For instance, "drawclaim move" it is one event in which the move and the claim goes together.

Miguel

An "execute" is of course more intuitive and neater than possibly several atomic commands in a row. It mimmicks human behaviour best as it alone stops the clock and definitively hands over control.
"hitclock" is easier to associate with chess than "execute".

Matthias.

[Uri Blass]

<snipped>

I have explained this before. _no_ protocol will work if it depends on a time delay. How can you guarantee that immediately after you make your move, before you make the claim, that your process doesn't get suspended for a hundred milliseconds or two for a system task to run?

If I cannot be sure about it then I also cannot be sure not to lose games on time for similiar reason(my process can get suspended for some seconds to cause me to lose a game on time when it is my move to play).

If the game is important for me then it is better to care not to run non chess processes at the same time.

The reason that I dislike solutions that are not about time delay is that they allow cheating as H.G.Muller explained earlier in some thread here.

The problem is that if you are allowed to claim a draw even one minute after you play a move then you can wait for your opponent's reply to decide if to claim a draw or not to do it and it is against the rules.

I think that in important games both the gui and the the engine should be able to respond faster than 0.01 seconds for simple tasks so there should be no problem with 0.02 seconds delay when it is possible to claim a draw.
(I say 0.02 seconds and not 0.01 seconds because I allow the interface also to have 0.01 seconds for noticing that the engine claimed a draw and 0.01+0.01=0.02)

Uri

[michiguel]

<snipped>

I have explained this before. _no_ protocol will work if it depends on a time delay. How can you guarantee that immediately after you make your move, before you make the claim, that your process doesn't get suspended for a hundred milliseconds or two for a system task to run?

If I cannot be sure about it then I also cannot be sure not to lose games on time for similiar reason(my process can get suspended for some seconds to cause me to lose a game on time when it is my move to play).

If the game is important for me then it is better to care not to run non chess processes at the same time.

The reason that I dislike solutions that are not about time delay is that they allow cheating as H.G.Muller explained earlier in some thread here.

The problem is that if you are allowed to claim a draw even one minute after you play a move then you can wait for your opponent's reply to decide if to claim a draw or not to do it and it is against the rules.

I think that in important games both the gui and the the engine should be able to respond faster than 0.01 seconds for simple tasks so there should be no problem with 0.02 seconds delay when it is possible to claim a draw.
(I say 0.02 seconds and not 0.01 seconds because I allow the interface also to have 0.01 seconds for noticing that the engine claimed a draw and 0.01+0.01=0.02)

Uri

No, the problem is that one event is separated in two non atomic commands. Your suggestion does not solve the problem, just make it less likely.

Miguel

[Matthias Gemuh]

I think that in important games both the gui and the the engine should be able to respond faster than 0.01 seconds for simple tasks so there should be no problem with 0.02 seconds delay when it is possible to claim a draw.
(I say 0.02 seconds and not 0.01 seconds because I allow the interface also to have 0.01 seconds for noticing that the engine claimed a draw and 0.01+0.01=0.02)

Uri

When the path from engine to GUI goes through the internet, you cannot be secure with this method.

Matthias.

[bob]

<snipped>

I have explained this before. _no_ protocol will work if it depends on a time delay. How can you guarantee that immediately after you make your move, before you make the claim, that your process doesn't get suspended for a hundred milliseconds or two for a system task to run?

If I cannot be sure about it then I also cannot be sure not to lose games on time for similiar reason(my process can get suspended for some seconds to cause me to lose a game on time when it is my move to play).

In very fast time controls this is a problem. In long time control games, you won't lose by missing a few milliseconds here and there. But the race condition happens in long, short and even in 24hour per move games.

If the game is important for me then it is better to care not to run non chess processes at the same time.

Run your windows task manager. How are you going to kill all those windows processes and still have a system the works? There is network traffic to respond to. DHCP leases that expire and have to be renewed. The list goes on and on and you can't prevent their executing whenever they please.

The reason that I dislike solutions that are not about time delay is that they allow cheating as H.G.Muller explained earlier in some thread here.

I see no way to cheat using my suggestion. Only an idiot GUI would forward a million draw offers to an opponent. An arbiter would declare the game lost. The GUI could do the same or only deal with one draw offer per move. I see no other method for "cheating".

The problem is that if you are allowed to claim a draw even one minute after you play a move then you can wait for your opponent's reply to decide if to claim a draw or not to do it and it is against the rules.

Read what I wrote. We are only trying to fix the case where I make a move and claim a draw, but the opponent moves too quickly for my claim to register first. CSTal used to try to let its opponent repeat a position twice to see if it would. If so, it knew the opponent thought it was worse and Chris would somehow factor that into his evaluation. If you are worried about such a case, it would be trivial to establish a window so that draw claims more than 10 seconds after your move are ignored if you choose. I've not seen a program that would wait to see the opponent's mvoe first, before claiming a draw. And I can't imagine any useful way to do that...

I think that in important games both the gui and the the engine should be able to respond faster than 0.01 seconds for simple tasks so there should be no problem with 0.02 seconds delay when it is possible to claim a draw.

The problem is you do not know how communication works between a GUI and a pair of processes. There is an implied order. Let's take xboard. It creates a pair of pipes and starts the first program and uses one of those to send to it, and one to receive from it. Let's say descriptor 4 is used to read from program 1. It then creates another pair of pipes for the second program. Let's say descriptor 6 is used here. Since the GUI does not know which program will send it input next, in Unix is uses select() which says to wait until I have data on either descriptor. When data on either (or both) is available select terminates and passes me a bit mask telling me which of the two (or both) I should read. You will generally read descriptor 4 first. And after that, descriptor 6, if both have input.

So, we start a game, I am program 2. I send "move xyz". Before I can do another thing, the GUI wakes up and reads the move and sends it to my opponent. Now the race is on. I send the draw claim, my opponent sends an instant reply to my move (say Qxh7 which makes the draw claim invalid). The GUI is once again sitting on the select() waiting for input. The select() call returns. I first try descriptor 4 (lowest sequential number) and read the move and send it to program 2. Then I read descriptor 6 from program 2, see the draw claim, and record this as a loss because it is not a draw.

There is absolutely no way you can prevent that from happening. You have two things to read, you can only read one at a time. That's where the race condition comes from.

(I say 0.02 seconds and not 0.01 seconds because I allow the interface also to have 0.01 seconds for noticing that the engine claimed a draw and 0.01+0.01=0.02)

Uri

Unfortunately your assumptions are completely wrong for how this is working. When the GUI blocks on the select() it is non-trivial to unblock it. And the length of time between input arriving on one of the descriptors, and that descriptor being read by the GUI can be significant. It's the way this stuff works.

[bob]

I think that in important games both the gui and the the engine should be able to respond faster than 0.01 seconds for simple tasks so there should be no problem with 0.02 seconds delay when it is possible to claim a draw.
(I say 0.02 seconds and not 0.01 seconds because I allow the interface also to have 0.01 seconds for noticing that the engine claimed a draw and 0.01+0.01=0.02)

Uri

When the path from engine to GUI goes through the internet, you cannot be secure with this method.

Matthias.

When the path from engine to GUI goes thru a pipe on a single machine you can not be secure with this method. The internet is a whole new can of worms that affects this issue, but it is still a problem if you run on a single multi-core box.

[hgm]

I agree with Bob that the "time kludge" does not work.

(1) I gave a simple way to correctly deal with offering draws, and claiming draws, which suffer from no race condition at all. Ever.

Well, I know zillions of ways that would work if I had the freedom to design a protocol from scratch. The challenge is to find ways that work that can be used by new engines without breaking them on old GUIs, and that don't break the GUIs using the new way with old engines. If you have done that, I must have missed it in the noise you are making. The only solution I have seen you propose so far is the way it already works, except that you want to rename some of the commands. And I consider the wording of the commands a completely unrelated subject, orthogonal to what we are discussing (namely solving the race condition).

(2) I gave a simple alias to "offer draw" so that a program can use "offer draw" to offer a draw, and "draw" to claim a draw, which is more natural to a chess program. It would be possible to interchange the two commands without having any effect on the GUI since the two commands are identical.

Yes, and it did not seem to work to me. Perhaps you did not describe it completely. Suppose youre engine runs on a GUI thathas sent you protover 2 in the beginning. What will Crafty be sending to that GUI when it wants to claim a draw after its next move?

All the GUI has to do to handle a "draw/offer-draw" command is the following. Since it can not determine whether the draw claim should be applied after the last move by this player, or before the current move by this player, due to the already explained race condition, the GUI just asks itself two questions.

(1) If I back up to right after the last move played by the side claiming a draw, is this a drawn position, by rule? If so, end the game. If I wait until we reach the point where it is this player's move again, meaning after the opponent's move, is this a drawn position, by rule? If so, end the game. If neither is true, send a draw offer to the opponent and forget about it. This works in every possible case. It lets me claim a draw before I make a move, or even without making a move, and it lets me claim a draw _after_ I make a move that meets rule requirements.

Well, so far this is exactly how the 1/2-1/2 command is implemented. And I don't see a good reason to offer an alias for the 1/2-1/2 command. (Or in fact for any command.)

Another problem is that it does not work in ICS play. The ICS would not compare my "draw" command to the previous position when the opponent won the race. So in ICS play the GUI would have to send the "draw" to the ICS before the move. It cannot do that if you claim it after the move.

It does let me offer a draw in an inopportune time, but that is OK and the GUI should be able to prevent me from offering millions of draws in succession to interfere with my opponent's search.

Indeed, and in fact current XBoard does prevent that. It has a very tight interpretation of the FIDE rule that you should not distract your opponent by spurious draw climing, namely that even a single on in the opponents time is too many. Some engines are very easily distracted.

In a normal OTB game, I make a move, tell my opponent "I offer a draw" and press the clock. The program author follows that same guideline when writing an engine, and it will work every time, without fail. It won't break old engines. It won't break old GUIs any more than they are already broken. It won't cause any problems. And it solves at least one big one, plus a couple of minor understandability issues for those that play tournament chess themselves.

Current XBoard sends draw offers together with the move, whenever it relays a draw offer. So that seems OK.