Christian (and anyone else interested) in the new CGOS protocol:
There are 2 minor change to the protocol. I'm hoping to do a test drive
today as the new server is functional, though not 100% complete.
Here are the two changes:
First of all, when the server asks for the protocol, you can continue to
use the "e1" protocol and it will default to a default venue (which will be
9x9 for now.) In this way the old clients will continue to work.
But if you specify the new 'e2' protocol, such as: 'e2 cgosPython 0.2
beta' you will next get something like this:
venues 9-300-7.5 11-420-7.5 13-540-7.5 15-660-7.5 17-780-7.5 19-900-7.5
This is a list of available venues and could be anything the server is
configured for. Each venue is separated by a space. A hyphen separates
the 3 elements within a venue which are boardsize, time in seconds, and
komi. So 15-660-7.5 is:
boardsize: 15x15
time control: 11:00 (11 minutes, zero seconds.)
komi: 7.5
You may want to provide some mechanism for informing the user of the
software which venues are available, even if it is as simple as just
displaying it. If the user tries to configure a venue that is not
available the connection will abort. You can also respond with a 'quit'
if the client notices that the user did not specify an available venue.
Of course all of that can be handled any way the client sees fit to do or
you can just ignore the issue and require the user to configure a proper
venue (the available venues will be posted on the web page of course.)
The proper response is ONE of those protocols, such as "13-540-7.5"
After this, everything remains the same as in the old protocol and the
server will next get the username and password as usual.
The second (optional) change is this:
If you respond to the protocol message with something like this:
"t2 cgosNoGo 0.1 alpha - Java engine client for NoGo"
The client will be placed in test mode. Nothing else changes about the
protocol, it is the same as "e2" but this triggers the server to play test
games with the client which will not be rated or recorded. You will then
recieve the venues message which you must respond to just as in the e2
protocol.
Another minor change, which does not directly affect the protocol, is that
the server will abort any connection that seems unduly delayed. For
instance if the client does not respond to messages after a few seconds
(such as gameover or venues) then the server will abort the connection.
This is to avoid a needless buildup of bogus connections.
FYI here is a list of clients GGOS has seen for the e1 protocol. I'm
leaving out the clients I have provided:
e1 CGOS soket engine client 1.3 windows7 by WangManDong
e1 CGOS pike client 0.9 by Gunnar Farneback
e1 CGOS tcl engine client 1.2 [platform] by WangManDong
e1 MROZTEST 1
e1 NaruGoTest
e1 Tesuji Software CGOS Client
e1 cgosNoGo 0.1 alpha - Java engine client for NoGo
e1 cgosNoGo 0.1 alpha - Java engine client for Nogo
e1 cgosPython 0.1 beta
e1 cgosPython 0.2 beta
e1 cgosPython 0.3.0 beta
e1 joe
e1 myCtest
e1 test client
e1 testing
v1 "0.1 NaruGo client for CGOS."
v1 NaruGoTest
- Don
On Tue, Jun 23, 2009 at 8:20 AM, Christian Nentwich <
[email protected]> wrote:
> All,
>
> FYI, the Python version of the CGOS client has moved into the main CGOS
> sourceforge area:
>
> http://cgos.sourceforge.net/client-python/
>
> There is also a new release (0.3.0) out that supports multiple engines.
>
> Christian
> _______________________________________________
> computer-go mailing list
> [email protected]
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
