I am especially grateful for comments on the windows part, since I have never done any windows programming.
Peter Strempel wrote:
Arend Bayer wrote:
- Windows.
There are several options for the communication stream under Windows.
a) Stdin/Stdout. It is not very widely known that Windows GUI programs can use console stdin and stdout, too. See
This Q&A set makes no sense to me. I am absolutely no capable Win32 API programmer, but with my mere knowledge I did know that you can grab stdin/out to a processes on Windows just like you can do on Unix. A Win32 guru who has never programmed on Unix would rather ask "How can I do it on Unix?" Your writing suggests Unix is the norm and Windows is something special. I'd suggest to keep that sort of stuff out of a GTP FAQ.
First there is a misunderstanding here: I was talking about the engine side implementation. My understanding is that a windows program cannot just use fprinft(stdout, ...).
Anyway, there needs to be section about setting up the communication stream under windows, since that seems to have cause the most misunderstandings about GTP (judging from the computer-go list). Many people seem to assume that only a program running in DOS mode has stdin/stdout.
Below is my next try.
Arend
1. Why should I implement GTP in my go program?
Because it is easy, and because it saves you doing many other tasks. Once you have implemented it, you have a big choice of GUIs with which you can use your program. You can have your program play on any of NNGS, IGS, KGS by using one of the existing client. You can use existing test suites. Or you can use the existing tools (as, for example, distributed with GNU Go) with your own test suite. You can easily play matches against other GTP engines.
You can also use GoGui and its GTP-to-GMP bridge to take part in tournaments that require the GMP protocol.
2. Why should I implement GTP in my graphical go client?
GTP is a convenient way to connect to go programs, and it is superior to the older GMP: For example, GMP lacks good support to resume games. There are many other ways to use GTP; for example, it is very easy to write an automatic scoring mode by connecting to a GTP engine.
3. I heard GTP is hard to implement. Is that right?
No.
"qGo only supports GTP, not GMP. GTP looks much better and was very easy to implement." Peter Strempel, author of qgo, gGo, glGo.
"Implementing it was trivial and simple." "...it was easy to get it right." Don Dailey, author of several go programs.
"Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected." William Shubert, programmer of KGS and kgsGtp.
4. In what setups can GTP be used?
While other setups are possible, here are the commonly used ones. You can find links to programs implementing the controller side of each setup from the GTP home page.
For a game computer vs human: GUI ------> GTP engine
To have a go program play on a server: GTP engine <------ Server client ------> Go Server
Matches between GTP engines: GTP engine <------ Controller script --------> GTP engine
To run a test suite: Controller script ------> GTP engine
5. How to set up the communication stream between controller and engine? (engine side implementation)
GTP does intentionally not specify this, as it depends on the setup you want to use. The only requirement is a bidirectional stream to communicate text messages.
a) Unix environment Here this is naturally done by the engine using stdin/stdout. All existing controllers can start the engine and grab its stdin/stdout to set up the stream.
b) Windows
There are several natural options for the communication stream under Windows.
- Stdin/Stdout of the engine. It is not very widely known that Windows GUI programs can use stdin and stdout, too. See http://dslweb.nwnexus.com/~ast/dload/guicon.htm.
- Named pipes. See e.g. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw98bk/htm...
- TCP/IP. You can have your program listen and reply on a TCP/IP port. You can use netgtp(1) as a wrapper in case the controller needs the GTP stream via stdin/stdout.
http://computer-go.org/pipermail/computer-go/2004-March/000463.html (example with code) http://computer-go.org/pipermail/computer-go/2004-March/000470.html http://computer-go.org/pipermail/computer-go/2004-August/000837.html
6. How can I play matches between different programs with GTP?
On a Unix platform with both engines accepting GTP via stdin/stdout, you can use one of the twogtp scripts coming with GNU Go. (In fact, you can use them on any platform provided you have Pike, Python or Perl installed, respectively.) GoGui comes with java scripts to do the same.
7. Can I play GTP matches between programs on different computers?
Yes. Assuming that the computers are connected with a network, you can do the following (assuming you have Java and GoGui):
- Have both engines listen on a TCP/IP port; if an engine accepts GTP via stdin/stdout, use gtpserver(1) to redirect the input/output to the port.
- Run GoGui on the controller machine, and use twogtp(1) and netgtp(1) to connect to the engines.
In this:http://computer-go.org/pipermail/computer-go/2004-March/000499.html post to the computer go mailing list, Gunnar Farneback describes a slightly different setup in a Unix environment using tcplisten and mkfifo.
Another way is to use "ssh -c ..." on the controller machine to connect to another computer and start the GTP engine there.
(1) These programs are all part of GoGui.