Re: computer-go: Re: IGS client server protocol.

[Tim Casey <tim@xxxxxxxxxxxxxxxx>]

At 01:48 PM 10/13/99 +0200, Jean-loup Gailly wrote:
>> I seek pointers to the specification for the IGS client server protocol

I or tweet hand out the closest thing we have to a spec, a header file.

>As others have already pointed out, there is unfortunately no
>official specification of the protocol.

The header file has comments collected from past client writers,
with my input.

> The protocol is also changed
>from time to time without warning to the client writers.

I specifically try to not change the interface over time.  I do add
to the interface.

> There is
>a mailing list of client writers clients@xxxxxxxxxxxxxxxxx managed
>by the IGS administrator Tim Casey <tim@xxxxxxxxxxxxxxxxx>, but unfortunately
>this list has been used only a few times in 1998 and never been used since.

It is not a list, but an alias.  I would answer any email from it.
Unfortunately
or not, no one has had any questions.  This is the second such list I have
made.

>As far as I know, the most complete description of the protocol is
>in the files goserver.l and gointer.y of the IGS client xgospel, which
>I maintain. But understanding those files requires minimum knowledge
>of regular expressions, lex and yacc. The xgospel sources are available
>on my go page http://gailly.net/go.html

xgospel does TOO good of a job, but that is another letter :).
We have had many conversations about this.

>xgospel parses with a strictly defined grammar all the data sent by IGS
>and is often the first client to break whenever an undocumented change
>is made in the protocol.

It is the first to break, documented or not :).

>The most difficult problem with the protocol is that it is not really
>a protocol. Because of net lag, there is often no way to relate an
>answer sent by IGS to a command sent by the client. The client can
>receive many unrelated messages before the answer arrives (including
>answers to previous commands), and when the answer arrives it may not
>contain enough information in itself to be interpreted without
>ambiguity. The protocol was designed assuming that a client need
>only interpret one line at a time, but this is generally impossible.
>The client must reconstruct enough context to interpret the line.

Any output coming from a command is selfcontained.  The intermixxing
happens at the level above that.  This being said, there is still not BNF
for IGS output except what xgospel has done.


tim