Re: [computer-go] How to play go with other programe?

[Dave Denholm <dave.denholm@xxxxxxxxxxx>]

Nick Wedd <nick@xxxxxxxxxxxxxxxxx> writes:

> In message <200408100010.08873.pogonyshev@xxxxxxxxxxxxxxxxx>, Paul Pogonyshev
> <pogonyshev@xxxxxxxxxxxxxxxxx> writes
>>This has been discussed with great heat a few months ago, but seems
>>like we'll have to repeat.
>
> I read that discussion, and put what I judged the most useful of the
> URLs at
> http://www.intelligentgo.org/en/computer-go/resources/specs.html.  One
> of them isn't working today.  I read the others, and rather got the
> impression that while people like the software part of GTP, they
> haven't got around to inventing the hardware part yet.
>


> I know what you need to make GMP work:  two systems with serial ports,
> two programs that support it, and a serial cable.  I have done it
> myself.
>
> I am still very vague about what you need to make GTP work - "use
> postal pigeons if you prefer" suggests that no-one actually knows how
> to do this bit.  I have no idea what a "controller" is.
>

I think a key difference between GMP and GTP is that GMP is designed
to be a symmetric protocol connecting go-playing peers. GTP is more
like a master/slave protocol, where the master could be the controller
or a GUI, and the slave is typically a go engine.

Also, GMP expects to be used directly over a lossy serial cable, so it
has error detection / timeouts built in. It can work over a pipe or a
socket, but then all the error detection and timeout code is wasted.

GTP is a simple protocol which runs over any reliable, bidirectional
stream connection - it can run over a serial cable, but requires to
layer over a reliable protocol such as SLIP or PPP. (There's no point
reinventing reliability over serial cables when you can just make use
of a standard lower-level protocol someone else has written and tested
earlier.) 



You cannot use GTP to directly connect two go-playing engines
(slaves) together. You need either one controller which can drive two
GTP slaves, or two controllers which act as proxies to some other protocol.

You could have a controller which acts as a GMP proxy - it implements
GMP over one connection (perhaps a serial cable) to a GMP peer, and
the GTP protocol over a different connection (perhaps a pipe) to a GTP
slave.

A different controller can interface to a go server in a similar way.

A controller could be a GTP/GTP proxy, ie it looks like a GTP slave on
one connection, but a GTP master one another connection. I can't
immediately think of a use for this, but maybe if someone were to
write a GTP master woth some propriety communications mechanism (eg a windows
named pipe), a proxy controller could connect to that pipe as a slave,
and forward the commands over a socket to the real slave.


While the need for a controller seems to make it harder to use than
GMP, the benefits include :

- a go engine only needs to implement the slave end of one simple
  master/slave protocol, and can ignore bootstrap issues about who
  starts the negotiation.

- Controllers are possibly a bit of a pain to write, but by separating
  them from the go engine, they can be shared and reused.


dd
-- 
Dave Denholm              <ddenholm@xxxxxxxxxxxxxxxxx>       http://www.esmertec.com
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/