Recently I started implementing a GMP to GTP adapter. This is tricky, since GMP is asynchronous. For example, I implemented the "genmove" GTP command so, that if no GMP command has arrived, the adapter waits until a move arrives. However, if the other side sends no move, the adapter would wait forever or at least a long time, since a timeout would have to be set to a very high value, because you don't really know how long the opponent could take for a move. So there again is a big need to make genmove interruptible.
After trying to implement the "abort" command (as suggested in earlier postings on this list) on a server as well as a client side, I am more convinced than before, that my first idea is better.
The abort command is inherently asynchronous (potentially overlapping with another command), whereas the regular GTP command stream is synchronous. So it is not very convenient to see abort as a regular command.
If you do so, things become unnessesarily complicated on the server side. The read thread needs to remember all abort commands received while a regular command was processed to be able to answer them correctly after printing the answer of the regular command.
Same on the client side, e.g. a graphical user interface which sends an abort command if the use presses a stop button needs to remember that, to be able to collect the responses. This makes conventional serialization technics with a read thread and event based GUIs not work and the code becomes really messy.
Also, what should the program do with a failure response? The response to it will be received after the response to the regular command anyway?
So IMO an abort command should not be seen as a regular command and should *not* need a response.
It is not very important whether the abort command is a word or a character. The only advantage of a character is, that if you take a control character not used by GTP, you could make interruption an optional extension to GTP that is simply ignored by clients that don't know it (from the GTP specs: clients must discard control characters not used by GTP).
- Markus
The abort command is inherently asynchronous (potentially overlapping with another command), whereas the regular GTP command stream is synchronous. So it is not very convenient to see abort as a regular command.
It seems to me that the fact that the gtp stream allows command id numbers which are mirrored by the response is a feature that implies the possibility of asyncronous response.
The gmp seems to lack a few things such as a mechanism for passing komi or resign moves. Moreover the document defining the protocol is quite old. Since the gmp is still the standard for tournaments this circumstance seems unfortunate.
Dan
On Monday 24 February 2003 16:11, Daniel Bump wrote:
It seems to me that the fact that the gtp stream allows command id numbers which are mirrored by the response is a feature that implies the possibility of asyncronous response.
no, according to the standard the order of responses is sequential. The IDs are only for convenience.
I don't want to make GTP asynchronous, I think most of the simplicity of GTP comes from the fact that it is synchronous and has clear server client roles.
It's only that I need interruption of commands for several reasons and I want to tweak it in without complicating GTP.
I would really prefer using an INT signal for that purpose, but that's not a good solution, because - signals are not implemented in some languages (like Java) - they are not portable - thay won't work over network GTP streams
- Markus
-
Daniel Bump -
Markus Enzenberger