All engines: DXP configuration

[gwiesenekker]

Hi,

I hope you all enjoyed watching the games played during the tournament organized by Krzsyztof, as always very interesting and useful! Now to make it easier to run these tournaments I am working on a Python script so that (most) engines can play against each other automatically using PyDraughts and DXP as the protocol. I know how to configure Scan in DXP mode so GWD can play automatically against Scan using DXP. If your engine has the option to be launched in DXP mode (perhaps with a command-line switch, perhaps through a configuration file) I would appreciate it if you could share the instructions with me. PyDraughts will be the listener, so your engine should connect to a (preferably configurable) IP address and port number. Also, please let me know if DXP mode can only be configured through the GUI after launch.

Regards,
GW

[Ed Gilbert]

Hi Gijsbert. Kingsrow supports dxp but it can only be started interactively with gui commands. However there is a Hub version of kingsrow that provides what you need. Hub give you control of all the kingsrow settings, and more options for time control. It does support the x moves in y minutes that dxp uses. PyDraughts supports Hub, so hopefully it will be easy for you to include support for that protocol in your script.

edit: I should add, you can download the hub version of kingsrow here. https://edgilbert.org/InternationalDrau ... ub_163.zip
It includes a pdf file with documentation.

-- Ed

[Krzysztof Grzelak]

Hi Gijsbert. Kingsrow supports dxp but it can only be started interactively with gui commands. However there is a Hub version of kingsrow that provides what you need. Hub give you control of all the kingsrow settings, and more options for time control. It does support the x moves in y minutes that dxp uses. PyDraughts supports Hub, so hopefully it will be easy for you to include support for that protocol in your script.

edit: I should add, you can download the hub version of kingsrow here. https://edgilbert.org/InternationalDrau ... ub_163.zip
It includes a pdf file with documentation.

-- Ed

Ed this is about dxp not hub.

[Ed Gilbert]

Ed this is about dxp not hub.

It's about automating engine matches using the PyDraughts library. The PyDraughts library supports both dxp and hub. I'm assuming that each engine will talk to the PyDraughts script so that it can control the games. It shouldn't matter which protocol PyDraughts uses to talk to the engines. Of course I'm not familiar with PyDraughts so there may be something about its implementation that makes this difficult or impossible, but in theory it should work fine. The PyDraughts library should be able to send the moves and time information to each engine and get each engine's reply moves using either protocol.

[FrankMesander]

Hi,

I hope you all enjoyed watching the games played during the tournament organized by Krzsyztof, as always very interesting and useful! Now to make it easier to run these tournaments I am working on a Python script so that (most) engines can play against each other automatically using PyDraughts and DXP as the protocol. I know how to configure Scan in DXP mode so GWD can play automatically against Scan using DXP. If your engine has the option to be launched in DXP mode (perhaps with a command-line switch, perhaps through a configuration file) I would appreciate it if you could share the instructions with me. PyDraughts will be the listener, so your engine should connect to a (preferably configurable) IP address and port number. Also, please let me know if DXP mode can only be configured through the GUI after launch.

Regards,
GW

Hi Gijsbert,
Please make clear who is the DamExchange Initiator and who the DamExchange Follower. This is independent of who is "listener".
Regards,
Frank

[gwiesenekker]

Hi,

PyDraughts is the DXP initiator. The reason for choosing the DXP protocol is that most engines (if not all) support it, but I will check if Pydraughts supports mixed mode, so one engine using DXP and the other (like Kingsrow) using hub.

Regards,
GW

[BertTuyt]

Gijsbert, what is your idea.
To run all the programs from the same computer using DXP (and as Ed posted this could also be HUB), or that programs connect to your program from the outside (using TCP-IP), and join this way a tournament.

Bert

[Joost Buijs]

Running all programs from the same computer with HUB as protocol does not seem like a good idea.

When a program wants to use all available threads pondering wont be possible, and often programs get in each other's way by grabbing resources the others also want to use.

I've seen on several occasions when a game gets in the endgame phase and both programs start using endgame tables (and loading them dynamically) that the operating system starts paging which will hurt one way or the other, this will give skewed results. Not all programs seem to behave properly in this respect, so the only solution would be to restrict endgame tables to (lets say) 6P, and this is not what you want.

[FrankMesander]

The idea of DamExchange is that every program runs on its own computer. Windows, Linux, mainframe or whatever. Connection with the tournament server is made only once for the entire tournament. The tournament server, as DamExchange Initiator, runs all the games.

[Joost Buijs]

The idea of DamExchange is that every program runs on its own computer. Windows, Linux, mainframe or whatever. Connection with the tournament server is made only once for the entire tournament. The tournament server, as DamExchange Initiator, runs all the games.

Exactly, this is the way it should be done. To distinguish between clients their IP-address can be used, it's not necessary to use different port-numbers for different clients. For each client that connects to the server a new socket will be created, beside their IP-addresses there are other possibilities to distinguish between clients.

[FrankMesander]

The idea of DamExchange is that every program runs on its own computer. Windows, Linux, mainframe or whatever. Connection with the tournament server is made only once for the entire tournament. The tournament server, as DamExchange Initiator, runs all the games.

Exactly, this is the way it should be done. To distinguish between clients their IP-address can be used, it's not necessary to use different port-numbers for different clients. For each client that connects to the server a new socket will be created, beside their IP-addresses there are other possibilities to distinguish between clients.

Distinguish between the clients should not be done at the IP level, but on the DamExchange level. A GAMEREQ can be sent to each client. The client returns a GAMEACC with its name. Then a GAMEEND is then sent (stop current game, open to new games) with a return GAMEEND by the client. This is the way DamExchange was designed.

[Joost Buijs]

The idea of DamExchange is that every program runs on its own computer. Windows, Linux, mainframe or whatever. Connection with the tournament server is made only once for the entire tournament. The tournament server, as DamExchange Initiator, runs all the games.

Exactly, this is the way it should be done. To distinguish between clients their IP-address can be used, it's not necessary to use different port-numbers for different clients. For each client that connects to the server a new socket will be created, beside their IP-addresses there are other possibilities to distinguish between clients.

Distinguish between the clients should not be done at the IP level, but on the DamExchange level. A GAMEREQ can be sent to each client. The client returns a GAMEACC with its name. Then a GAMEEND is then sent (stop current game, open to new games) with a return GAMEEND by the client. This is the way DamExchange was designed.

Of course, it's better to let the protocol handle this. I run a small chess-server which handles this at the protocol level too.

I have a few questions and remarks about the DamExchange (DXP) protocol though:

When is it going to be used for a server shouldn't there be a way to authenticate a client (user) by means of a password? The server could also handle this by requiring a user to logon with name and password before activating the DXP protocol.

In the MOVE record there is a 4 byte field to transmit the 'thinking time' used by the engine in seconds, a resolution of 1 second seems way to low to get accurate timings, maybe there should an option to increase the resolution to at least 1 msec.

I think there should be an option in the GAMEEND message to claim a draw when one of the draw rules is triggered, of course this should also be handled by the server.

Ed Gilbert has added a 'Fisher clock' extension to the GAMEREQ message (which also has better time resolution), maybe this can be added to the official DXP specification as well.

[FrankMesander]

Of course, it's better to let the protocol handle this. I run a small chess-server which handles this at the protocol level too.

I have a few questions and remarks about the DamExchange (DXP) protocol though:

When is it going to be used for a server shouldn't there be a way to authenticate a client (user) by means of a password? The server could also handle this by requiring a user to logon with name and password before activating the DXP protocol.

In the MOVE record there is a 4 byte field to transmit the 'thinking time' used by the engine in seconds, a resolution of 1 second seems way to low to get accurate timings, maybe there should an option to increase the resolution to at least 1 msec.

I think there should be an option in the GAMEEND message to claim a draw when one of the draw rules is triggered, of course this should also be handled by the server.

Ed Gilbert has added a 'Fisher clock' extension to the GAMEREQ message (which also has better time resolution), maybe this can be added to the official DXP specification as well.

The current DamExchange specification is version 01 (see the GAMEREQ message and its handling). Let's keep this version "01" unchanged and create a new version "02" which addresses the current needs. It preferably should be done in such a way that the GAMEREQ message remains compatible with a "01" Draughts program. The "01" Draughts program can reply GAMEACC with code 1 (version not supported) when GAMEREQ is sent with version "02". The Tournament Server, or other Draughts program acting as Initiator, can fall back to version "01" for that program.

By the way, many programs return "0000" as time in the MOVE message, as it was only meant for informational purposes. It is not essential for playing games.

If we go the way with a new version "02" for DamExchange, it can delay organizing a DamExchange tournament with something like pydraughts. We can first try to do a tournament with version "01".

[Joost Buijs]

By the way, many programs return "0000" as time in the MOVE message, as it was only meant for informational purposes. It is not essential for playing games.

I think the server would like to know how much time the engine spent for calculating the move, when you let the server handle this by it's own the communication delay will be added to the move time. E.g. when the server resides in Europe and the client in the USA, the total communication delay added for each move will be > 200 msec., this is clearly too much.

On most chess servers they use 'time-seal' or 'time-stamp' to cope with communication delays, these are secure and encrypted protocols to prevent users from tampering with it.

For our purpose it seems good enough if the client sends the time it actually spent on calculating the move.

[FrankMesander]

By the way, many programs return "0000" as time in the MOVE message, as it was only meant for informational purposes. It is not essential for playing games.

I think the server would like to know how much time the engine spent for calculating the move, when you let the server handle this by it's own the communication delay will be added to the move time. E.g. when the server resides in Europe and the client in the USA, the total communication delay added for each move will be > 200 msec., this is clearly too much.

On most chess servers they use 'time-seal' or 'time-stamp' to cope with communication delays, these are secure and encrypted protocols to prevent users from tampering with it.

For our purpose it seems good enough if the client sends the time it actually spent on calculating the move.

In DamExchange "02" we can alter the format of the field (e.g. mSec) and make it an obligation to fill in the actual thinking time for the move.