Paul wrote (on the computer-go list):
> About asynchronous move generation.
>
> I'd propose something like this. Add some form for asynchronous
> responses. E.g. '=[id] ...' means success, '?[id] ...' means error
> (this is as now) and '%[id] ...' means asynchronous response. Maybe
> for asynchronous commands it makes sense to make id mandatory.
> Responses must not be mixed, i.e. you cannot start a synchronous
> response inside asynchronous or vice versa (else they will be
> impossible to parse properly.)
This is in the same direction I've been thinking. To make it consistent
with GTP version 2 and fully backwards compatible it can be designed
like this:
* Asynchronous responses from the engine are encoded like Paul proposes
but with "!" as first character (there is precedence in a protocol GTP
was originally inspired by). Naturally one response must be complete
before starting on another, whether synchronous or asynchronous.
* Asynchronous messages may only be sent as responses to asynchronous
commands. Thus a GTP version 2 controller would never become confused
by asynchronous responses it knows nothing about since it would only
send synchronous commands.
* Asynchronous responses have the same id as the command initiating
them. The id may as usual be omitted by the controller if it is
confident that it don't need it.
* An asynchronous command must first be acknowledged by a synchronous
response (would usually be an empty response if there are no problems
and otherwise an error response).
* An asynchronous command may additionally have zero, one, or multiple
asynchronous responses, depending on the nature of the command and the
situation. For example an asynchronous genmove command would normally
have one asynchronous response, but zero if the command is aborted. A
command requesting debug output could produce any number of
asynchronous responses.
* Whether an engine is capable of doing asynchronous responses can as
usual be tested by known_command or list_commands to see whether it
supports specific (asynchronous) commands.
* The asynchronous genmove command would be named async_genmove. In
contrast to the normal genmove command it would only generate a move,
not actually play it. (To keep sanity and avoid undos when the
ordering of move generation and abort command depends on race
conditions.)
* To abort the asynchronous genmove, the controller should send the
(synchronous) command abort_async_genmove. If the engine has not
returned the asynchronous genmove response before responding to the
abort command, it is no longer allowed to return a move. I'm open for
discussion on the exact name and whether it should return an error if
the move had already been sent (I don't think it should).
Example 1: Asynchronous genmove with an intervening synchronous command.
Command 3 is sent after receiving the asynchronous move.
Controller:
1 async_genmove black
2 version
3 play black E5
Engine:
=1
=2 4.0
!1 E5
=3
Example 2: Asynchronous genmove, aborted. The controller plays an own
move instead.
Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3
Engine:
=1
=2
=3
Example 2b (BAD): Like example 2, but the engine makes an incorrect
response.
Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3
Engine:
=1
=2
!1 E5
=3
Example 3: Like example 2, but abort command comes too late.
Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3
Engine:
=1
!1 E5
=2
=3
Example 4: Asynchronous genmove sent to an engine not supporting it.
Controller:
1 async_genmove black
Engine:
?1 unknown command
/Gunnar
