[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] finishing game on KGS



Ruhai wrote:
> When GoWind plays in IGS or NNGS, any command can be
> added,  issued and get responses from the server just
> like a human. But using GTP, only passive responses
> are allowed. So how good is using GTP comparing with
> IGS server?

You may as well ask how good KGS is compared to IGS or NNGS, although
that's not a particularly meaningful comparison in this context
either. Let me try to explain how these things relate. (If the
diagrams come out garbled, try to switch to a fixed-width font.)

The setup when you play with GoWind on KGS is like this:

            secret
-------    protocol    ----------      GTP      ----------
| KGS |  <---------->  | kgsGtp |  <--------->  | GoWind |
-------                ----------               ----------

and when playing on IGS, presumably, like this:

             open
-------    protocol    ----------
| IGS |  <---------->  | GoWind |
-------                ----------

In the first case the KGS server communicates with the kgsGtp program
using a protocol which supposedly can do anything that is possible on
the server but which Bill Shubert for various reasons has chosen to
keep secret. Then kgsGtp in turn talks to the go program using GTP.

In the second case the go program directly talks to the IGS server,
using the IGS protocol, which is messy but basically open and powerful
in the sense that it can access all functionality of IGS.

Both setups have their strengths and weaknesses. The main advantages
of the KGS setup are:
* The go program only needs to implement a simple protocol, GTP, and
  doesn't have to deal with a vastly more complex, and in the KGS case
  secret, server protocol.
* The go program can easily be replaced with another one in the setup.

The main advantage of the IGS setup is:
* The go program has full access to the IGS functionality, if it
  chooses to do the implementation work.

Personally I prefer the following setup, which gives me the best of
both worlds (the difference between IGS and NNGS is not conceptually
important here):

              open
--------    protocol    ---------------      GTP      ----------
| NNGS |  <---------->  | gnugoclient |  <--------->  | GNU Go |
--------                ---------------               ----------

Since I have written gnugoclient myself I can get it to do anything I
want on the server, just like in the "IGS setup" above, without having
to burden the GNU Go codebase with the parsing of the NNGS protocol.
It also lets me write gnugoclient in a language which is better suited
to text processing than C (which GNU Go is written in). Like in the
"KGS setup" above I can trivially replace GNU Go with another program.

(The gnugoclient 2.0 version which can be found on the internet uses
GTP version 1 and can no longer be recommended. I haven't come around
to making a release of a more current version but it is available "as
is" through anonymous CVS if someone wants to try it.)

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/