Starting Dragon engine on a server

[BertTuyt]

Walter,

I believe that both Bert on yourself have implemented your own enhancements to GUIDE. To get some of the above working properly I would also require some enhancements to the GUIDE protocol (and the DXP protocol e.g. for Fisher time as I proposed in another thread). Would you be interested to standardise these enhancements again and to support a new updated GUIDE protocol version?

I'm very much interested to standardize further the GUIDE protocol.
Basically if I would start from scratch I might do it differently.
So I'm open to share all enhancements, and new proposals.

Bert

[BertTuyt]

Walter,

did you check if the Damage Engine could directly work with DXP as described in my previous post?

Bert

if you want to run a DXP match against Kingsrow (assume you have this program), the next steps are required:
Start KingsRow in a mode Wait for DXP connection....

* Only start the Engine, so without GUI
* And now you need to type the next GUIDE (and non-documented) commands:

opponents engine-engine
levelsfixeddepth XX ( XX whatever you want, XX = Ply), for a fixeddepth mode or
levelsfixedtime XX (for a fixed time mode XX = sec ), I did not implement in this download other options

And then the non GUIDE commands
$dxp client
$dxp match
$dxp go

[Walter Thoen]

Walter,

did you check if the Damage Engine could directly work with DXP as described in my previous post?

Bert

if you want to run a DXP match against Kingsrow (assume you have this program), the next steps are required:
Start KingsRow in a mode Wait for DXP connection....

* Only start the Engine, so without GUI
* And now you need to type the next GUIDE (and non-documented) commands:

opponents engine-engine
levelsfixeddepth XX ( XX whatever you want, XX = Ply), for a fixeddepth mode or
levelsfixedtime XX (for a fixed time mode XX = sec ), I did not implement in this download other options

And then the non GUIDE commands
$dxp client
$dxp match
$dxp go

Hi Bert,

I had no problem getting the Horizon40 engine to play a DXP game against Kingsrow by typing the above commands in the Engine Commands textbox myself.

The next task was then to start the engine process from my program and then send the commands. Starting the engine process from my code was no problem, but as the Horizon engine is not a console app you cannot simply write to stdin to enter the commands.

Then I thought that the only solution was to start the engine in GUIDE mode, connect to the engine using a TCP socket, and send the commands that way. I have gotton as far as making the connection and reading the output from the engine until I receive "engineok". Sending the commands to the engine does not yet work (nothing happens). I guess I will have to do some more ping pong testing to figure out what is wrong.

In any event, starting DXP in this way does not make a whole lot of sense If the GUI already has a GUIDE protocol connection to the engine then why would you want to switch to DXP to play a game. Much better to continue with playing the game using the more powerful GUIDE protocol! Having the GUI play against engines using DXP was only fall back for engines that do not support GUIDE (like Kingsrow, Dam22 etc.).

So as these things go I got diverted from automatically starting engines with DXP activated to implementing GUIDE (which I had planned to do much later).

Regards,
Walter

[BertTuyt]

Walter,

Then I thought that the only solution was to start the engine in GUIDE mode, connect to the engine using a TCP socket, and send the commands that way. I have gotton as far as making the connection and reading the output from the engine until I receive "engineok". Sending the commands to the engine does not yet work (nothing happens). I guess I will have to do some more ping pong testing to figure out what is wrong.

To see the GUIDE commands within the Engine, you can use the command $debug , so you can see if the commands are received by the engine.

Bert

[Walter Thoen]

Walter,

Then I thought that the only solution was to start the engine in GUIDE mode, connect to the engine using a TCP socket, and send the commands that way. I have gotton as far as making the connection and reading the output from the engine until I receive "engineok". Sending the commands to the engine does not yet work (nothing happens). I guess I will have to do some more ping pong testing to figure out what is wrong.

To see the GUIDE commands within the Engine, you can use the command $debug , so you can see if the commands are received by the engine.

Bert

Happy to announce the major achievement of getting a pong

[MichelG]

Hi Michel,

An important goal of my project is that the server engine you play against is stronger than an engine app running on your phone or tablet. That is easy to achieve if you have one engine running on a big server (say 16 cores XEON E5, 128GB with 8pcs egdb) but what if you have to start 20 engine on that server to support twenty simultaneous users? Would these 20 engines still be stronger than an app on your phone or tablet?

Therefore, the main reason for asking about starting multiple engines on different ports was to demonstrate the concept and than do some scalability testing. (I do not need it personally as I have enough problems to win against one engine at a time )

I will certainly not make anything publicly available without approval of the engine owners!

However, the ultimate goal is to make the system available to the general public (as part of the Killerdraughts.org initiative), but there is still a long way to go before that might become feasible.

1) I only have a prototype that passes DXP message between a web page and a draught engine and vice versa. The Web User Interface is being worked on.

2) To create a fully functional web user interface I also intend to implement the GUIDE protocol. This is important to allow the user to see search info and to do analysis.

3) I would like to have a feature to query the 8 or higher endgame databases (similar to http://www.shredderchess.com/online-che ... abase.html)

4) I want to support the Killer-rule (no engines currently support this apart from your old Dragon version).

5) And finally a big, costly server is needed to support simultaneous users

I believe that both Bert on yourself have implemented your own enhancements to GUIDE. To get some of the above working properly I would also require some enhancements to the GUIDE protocol (and the DXP protocol e.g. for Fisher time as I proposed in another thread). Would you be interested to standardise these enhancements again and to support a new updated GUIDE protocol version?
Walter

Thank you for this detailed explanation

I understand the reasons for running the engine on a server and guide would be the most obvious API for the job. In theory you could use DXP, but in dragon the DXP is handled by the gui and then translated into guide.

I currently have very little time available to develop dragon further or support new interfaces and features and i will concentrate my efforts on increasing it's strength and resolve a few last bugs.

Michel

[Walter Thoen]

Thank you for this detailed explanation

I understand the reasons for running the engine on a server and guide would be the most obvious API for the job. In theory you could use DXP, but in dragon the DXP is handled by the gui and then translated into guide.

I currently have very little time available to develop dragon further or support new interfaces and features and i will concentrate my efforts on increasing it's strength and resolve a few last bugs.

Michel

I reached the same conclusion that I better spend time on implementing GUIDE.

I will try to continue my project as far as I can using the features that the existing engines provide.

I initially intended to use Rein's excellent DCTL library to build my own engines that would support all the features I need. The DCTL library still needs time to develop into a full blown engine though and unfortunately my modern C++ skills are also nowhere near Rein's. I am buying the books Rein recommended to Bert. Whether I will actually find the time to read them I don't know

Walter

[Walter Thoen]

Krzysztof,

can you explain what doesn't work?

Does the GUI not start ?
The GUI should also activate the Engine in a separate window.

You can also try to only start the Engine. Does this work?

Do you see error messages like some DLL's missing (like MFC, .... )

Bert

Bert, Krysztof,

I had a problem starting Horizon40.exe on another laptop. I had to download and install the Visual C++ 2008 x64 redistributable from the Microsoft website to get it to work.

Maybe it helps with your problem as well.

Regards,
Walter

[Krzychumag]

I had a problem starting Horizon40.exe on another laptop. I had to download and install the Visual C++ 2008 x64 redistributable from the Microsoft website to get it to work.

Maybe it helps with your problem as well.

Regards,
Walter

Walter thanks for information and advice. Your advice helped and the program started itself.

-- Krzysztof.

[Walter Thoen]

Bert,

I got various things working using GUIDE and Horizon40 as engine.

The Searchinfo message from the engine do not seem to strictly follow the GUIDE protocol spec.

I am not sure about the opening book though. I am trying to send "setoption 0 1" to switch it on, but it doesn't seem to affect the engine. It still plays the same move every time.

Does the Damage/Horizon40 version support the use of an Opening Book? If so, then how do I switch it on?

Michel,

I have not managed to make GUIDE work with Dragon. I tried to start the engine with "dragon64r -guide -port 27533" but cannot get the GUID to connect to the engine on port 27533. The console output states "Waiting for data on shared memory connection", which seems to indicate that you use a different communication method than TCP/IP. Can you tell more about what communication method Dragon is currently using? It could be an idea to add "named shared memory" or even "stdin/stdout" to the GUIDE protocol spec.

Thanks,
Walter

[MichelG]

Michel,

I have not managed to make GUIDE work with Dragon. I tried to start the engine with "dragon64r -guide -port 27533" but cannot get the GUID to connect to the engine on port 27533. The console output states "Waiting for data on shared memory connection", which seems to indicate that you use a different communication method than TCP/IP. Can you tell more about what communication method Dragon is currently using? It could be an idea to add "named shared memory" or even "stdin/stdout" to the GUIDE protocol spec.

Thanks,
Walter

If you add the -sockets command to the engine, it should connect through sockets. Otherwise it uses shared memory for communication, but that's not intended to be a standard.

Michel

[BertTuyt]

Walter,

Bert,

I got various things working using GUIDE and Horizon40 as engine.

The Searchinfo message from the engine do not seem to strictly follow the GUIDE protocol spec.

I am not sure about the opening book though. I am trying to send "setoption 0 1" to switch it on, but it doesn't seem to affect the engine. It still plays the same move every time.

Does the Damage/Horizon40 version support the use of an Opening Book? If so, then how do I switch it on?

The Opening Book is not activated/implemented in this download version, but the command(s) as you mentioned should work in future versions.

Bert

[Krzychumag]

Hi Bert.

Bert need a favour, and you can make this book available devolutions to the program Horizon 4.

--Krzysztof.

[BertTuyt]

Walter,

Bert,

I got various things working using GUIDE and Horizon40 as engine.

The Searchinfo message from the engine do not seem to strictly follow the GUIDE protocol spec.

Could you indicate where the Searchinfo message does not strictly follow the GUIDE protocol spec?

As I only use it for Damage , and interoperability with other Engines/GUI's is not yet an issue.
So you are most likely right.......

Bert

[Walter Thoen]

Bert,

The searchinfo that I receive from the engine is as follows:

searchinfo search 0.10 9.01 0.00 14x23 0
searchinfo string 0.12 9.01 0.00 14x23
searchinfo string Look : 116971 47422 0
searchinfo string DB64 : Cache ( R, W, F ) : 0 0 131072
searchinfo string Depth ( N, -, +, A ) : 9 20
searchinfo pv 14x23 39-33 13-19 44-39 10-14 34-29 23x34 39x30 11-17 37-31

I had two small issues parsing this. The GUIDE standard states

Commands to and from the engine are separated by one or more separators. Any character with a value below 32 can be used to separate 2 or more commands.

The values of the "searchinfo search", however, are TAB delimited. TAB has a number under 32 so I initially parsed it as the end of the command. I now made an exception for TAB to resolve this.

The actual definition of searchInfo is:

searchInfo <searchinfo_string>
During the search process the Engine will sent constant searchinfo messages towards the GUI.
The <searchinfo_string> contains multiple search tokens with associated token_strings. The way the specific tokens are processed by the GUI is not prescribed by the GUIDE protocol.
Overview search tokens:
• currmove <move> Currently searching the move <move>
• currmovenumber <x> Currently searching move number x ( 1 … n)
• neval <x> Number of evaluation function calls
• nodes <x> x nodes searched.
• ply <x> Search depth in plies (half move).
• pv <pv_string> Principal variation.
Example: pv 32-18 17-21 37-32 21-26 32-27 26x37 41x32
• score <x> The engine score x.
• time <x> Time search in seconds.
• string <string_string. General (not specified) information.
Example: searchinfo string look 45678 (number move generator calls)

"searchinfo search" is not actually defined. Moreover, the token names of the values "time", "ply", "score", "currmove" are omitted. (Did I get the order right?)

"searchinfo pv " shows the token name correctly.

I also have a question about how to interprete:

game <position_data> <nr_moves> <move_list>
Sends the starting position and all moves of a game to the Engine.
The position data consists of 2 parts, a colour to move ( white or black ) and a 50-character string

What should the 2 parts of the position data actually look like? Horizon is happy to start a new game if I omit the colour to move and other parts:

game bbbbbbbbbbbbbbbbbbbbeeeeeeeeeewwwwwwwwwwwwwwwwwwww

Dragon is not happy whatever I try: "game bbb..." "game white bbb..." or "game w bbb..." or "game W bbb..."

Dragon is also not happy about "levelsblitzgame 300 0", Horizon is. However, the Dragon issues might also have other causes; I never see the "engineok" message after connecting. Horizon gives me name, author, options and then engineok. However, as you confirmed the listed options are sometimes not actually supported

Regards,
Walter