Re: [computer-go] GTP and Tourney in SmartGo 1.4

[dave.denholm@xxxxxxxxxxx]

elvire.scheibling@xxxxxxxxxxxxxxxxx (Elvire Scheibling) writes:

> William Shubert has asked me to post his answer to the list:
>
>
> On Sun, Mar 14, 2004 at 09:51:10PM -0800, David Fotland wrote:
>
>> You say that I might want to implement GTP to communicate with other
>> programs, and you say that GTP is just a protocol, and says nothing
>> about the communication channel that carries it.  But don't existing
>> programs that implement GTP use pipes?  If I implement for  example, a
>> TCP/IP version, I don't think it will talk with Gnugo.  That's where I
>> got the impression about pipes.
>
> Most engines using GTP right now just use stdin/stdout (for C
> programmers, that means just using "scanf()" or "getchar()" to read GTP
> commands, and "printf()" to write the responses back). I'm not sure if
> this is what you meant by "pipes" or not, stdin/stdout are usually pipes
> but could also be FIFOs or network sockets or whatever. In any case,
> this mechanism makes things incredibly easy for the engine author. Then
> the GTP server writer has to do the work of making sure that
> printf/scanf gets to the server properly.
>


I think that's the probem : on unix, it's trivially easy for a wrapper
script to open pipes / create sockets / etc and bind them to stdin/stdout,
then exec the engine. The engine just reads/writes to these file descriptors
and everything works transparently.

While windows has all these IPC mechanisms, it doesn't treat them all
as files, as unix does, so you can't mix/match your function calls. You
have to know what sort of connection it is you are dealing with. You
have to use send()/recv() for sockets, but different calls for pipes.
(Maybe ReadFile/WriteFile works for pipes too - I don't know details.)

It's a long time since I've had to write on windows, but back then,
winsock was not fully integrated, and you could not treat sockets and
pipes the same.


You could certainly set up a layer (people probably already have) which
wrap IPC endpoints in a generic framework so you can use the same
fns to read/write on all different IPC types.


Another approach to this problem on windows could be to define a
DLL interface for a GTP comms module. Then engines can load one of
several DLLs to implement GTP over various IPC types.


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