Feature Request: play <multiple moves> and undo <count>

[bvandenbon]

I would like to add / propose a feature, which is a (minor) extension on the GTP spec.

Motivation:
If you run leela-zero on a remote server and you try to communicate to it using SSH, then you may experience a lot of delay in the communication. Effectively, when you navigate using a tree (e.g. lizzie, zbaduk, ...), and jump from one end of the game record to the other, that means executing a lot of play or undo commands to get there.

play b a1 
= 
play w a2 
=
play b a3 
=
play w a19
=

And to move to the front.

undo
=
undo
=
undo
=
undo
=

I have recently been measuring the response time of SSH communication, and often it is about ~10ms per executed command (waiting for the = ack). So, jumping 100 moves, effectively takes a full second.

Exceptionally I have seen delays of over 3 seconds in our server log files.

Proposal:
I would like to propose a single command to execute multiple play/undo commands.

i.e.

play b a1 w a2 b a3 w a19
=

and

undo 4
=

Looking forward to your feedback.
Kind regards.

[lightvector]

Re-posting here roughly the same thoughts as in the referenced issue:

I think that it should simply be sufficient to send a sequence of "play" and "undo" commands without waiting for the response. The engine should then simply handle all the commands in order and send back responses consecutively.

This is already part of the GTP spec, section 2.8 (and sections 2.5 through 2.7 allow a way to tag commands with an "id" so the controller can know which response or error corresponded to which command).
https://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html#SECTION00035000000000000000

If Lizzie and ZBaduk do not do so, then rather than adding a GTP extension and modifying Lizzie and ZBaduk to support it seems that Lizzie and ZBaduk should simply modify to make use of the existing GTP protocol in a very similar way to how they would use the extended commands - sending just a sequence of regular commands in place of the proposed extensions, and a little bit of logic on how to handle the expected sequence of responses. Then, instead of forcing all other engines to also implement these additional extensions or else have their engine work suboptimally with these tools, we would automatically benefit all the engines too.

bvandenbon:

I used to do that with leelaz, but for some reason it would skip some moves
and get out of sync.

If this is indeed true of leelaz, then it seems like a bug, and in my opinion the right fix is to just fix the bug in leelaz so that it properly conforms to GTP rather than to work around a bug by modifying the protocol itself.

[kaorahi]

Lizzie sends a sequence of undo commands without waiting for the response (second commit in featurecat/lizzie#289). You can confirm it on GTP console of Lizzie by replacing leelaz with something like this.

#!/bin/sh
ruby -pe "STDOUT.sync = true; sleep 1" | leelaz -g -w network.gz

I rather doubt outputStream.flush(); after every undo command in sendCommandToLeelaz() in Leelaz.java. Is it harmful for SSH? If so, how about https://github.com/kaorahi/lizzie/tree/buffering ? (Please change DELAY_FLUSH_MILLIS as you like.)

[bvandenbon]

Well, all I can say is, it seems to work fine.
So, in all honesty, I think we can close this.