Moby Dam

[ArthurK]

Python TCP/IP socket client cannot send messages to MobyDam.

I have successfully installed MobyDam on a Linux Mint system.
I tested successfully a connection with Dam 2.2 and play a game.

Now I like to make a connection from a Python TCP/IP socket client program with MobyDam.
The Python client makes succesfully a connection as the log files confirms.
If I send a chat from MobyDam, the Python client receives the chat message!!

BUT vice versa:
I can not send a message from the Python client to MobyDam.
For example a DXP chat message CHello world. Or a DXP gamerequest message.
MobyDam does not react. Also nothing happening in the engine.log and dxp.log

Does anyone know what could be the problem?

An example of a very simple Python client program is:
# Simple python TCP/IP socket client program to test MobyDam.
# Client makes connection with server, send message and stops.
import socket
host = '127.0.0.1' # 'localhost'
port = 27531 # default DXP mobydam
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((host, port))
sock.send('CHello world')
sock.close()

[Ed Gilbert]

Does sock.send('CHello world') send a null character at the end of the text? DXP needs the nulls as message terminators.

-- Ed

[ArthurK]

The problem with sending messages from Python client to MobyDam is solved by:
sock.send('CHello world' + '\00')
Indeed a null chacter is missing!

Thank you very much Ed.

[ArthurK]

Linux DamExchange client for MobyDam

You work on a Linux platform.
You need an application to play draughts against MobyDam (or any other draughts server).
You are used to work with a command line interface.
Maybe you like to use my DamExchange client for 10x10 International Draughts. I created this application as a need to play draughts with MobyDam on a Linux platform. For Linux the only way was to install a client like DAM2.2 together with the Wine emulator.

Although I tested my application on Linux, I am not surprised if it works on other platforms like macOS or Windows. Maybe for Windows you must choose the pieceset ASCII instead of Unicode (menu option).
The application has a command line interface and is written in Python. You can play a game against yourself or connect to and play against a remote draughts server.
The application is open-source. You can find it on github: https://github.com/akalverboer/DXC100_draughts_client

To run the application, download the five Python files. Open a terminal and type: python dxc100_run.py

[Rein Halbersma]

Linux DamExchange client for MobyDam

You work on a Linux platform.
You need an application to play draughts against MobyDam (or any other draughts server).
You are used to work with a command line interface.
Maybe you like to use my DamExchange client for 10x10 International Draughts. I created this application as a need to play draughts with MobyDam on a Linux platform. For Linux the only way was to install a client like DAM2.2 together with the Wine emulator.

Although I tested my application on Linux, I am not surprised if it works on other platforms like macOS or Windows. Maybe for Windows you must choose the pieceset ASCII instead of Unicode (menu option).
The application has a command line interface and is written in Python. You can play a game against yourself or connect to and play against a remote draughts server.
The application is open-source. You can find it on github: https://github.com/akalverboer/DXC100_draughts_client

To run the application, download the five Python files. Open a terminal and type: python dxc100_run.py

Nice job! If you want numbering to appear when you print the position, the custom on real boards is to have the 1, 6, ...46 numbers on the left, and the 5, 10, 50 numbers on the right edge. If you like it, I can give you a pull request on GitHub. Like this:

[ArthurK]

Play draughts in your webbrowser against a draughts engine

I have created a simple user interface for 10x10 draughts that runs in the browser.
You can play a game against yourself or against a draughts engine.
Playing draughts in the browser has a number of advantages.
The advantages of a user interface in the browser are:

1. Cross platform - can be used on any platform with a web browser.
2. Javascript, HTML and CSS make it very easy to build powerful user interfaces very quickly.
3. Web development is standards based; you are not required to use proprietary software that locks you to the platform.
4. Can be used offline as well, limited to one computer or to a LAN.

The current generation of draughts engines are not able to talk to browser clients.
To solve this problem I have created a bridge server that is an intermediate between the browser client and the draughts engine.
The bridge server is a Python application. It works on Linux but I expect it works cross-platform.
You can connect with draughts engines like MobyDam, Scan and Horizon.
The browser client I created expects the DamExchange protocol.

Both the draughts user interface and the bridge server are open source and free to download.
Links:

1. [url=http://svg_experimenten.deds.nl/wsdam/wsdam.html]WsDam Draughts Client online[/url].
2. WsDam on Github.
3. Bridge server on Github.

PS
The bridge server is generally applicable.
It can also be used for 8x8 checker engines, chess engines and other applications.
It bridges the Websocket protocol and the Tcp Socket protocol.

[Rein Halbersma]

Play draughts in your webbrowser against a draughts engine

I have created a simple user interface for 10x10 draughts that runs in the browser.
You can play a game against yourself or against a draughts engine.
Playing draughts in the browser has a number of advantages.
The advantages of a user interface in the browser are:

1. Cross platform - can be used on any platform with a web browser.
2. Javascript, HTML and CSS make it very easy to build powerful user interfaces very quickly.
3. Web development is standards based; you are not required to use proprietary software that locks you to the platform.
4. Can be used offline as well, limited to one computer or to a LAN.

The current generation of draughts engines are not able to talk to browser clients.
To solve this problem I have created a bridge server that is an intermediate between the browser client and the draughts engine.
The bridge server is a Python application. It works on Linux but I expect it works cross-platform.
You can connect with draughts engines like MobyDam, Scan and Horizon.
The browser client I created expects the DamExchange protocol.

Both the draughts user interface and the bridge server are open source and free to download.
Links:

1. [url=http://svg_experimenten.deds.nl/wsdam/wsdam.html]WsDam Draughts Client online[/url].
2. WsDam on Github.
3. Bridge server on Github.

PS
The bridge server is generally applicable.
It can also be used for 8x8 checker engines, chess engines and other applications.
It bridges the Websocket protocol and the Tcp Socket protocol.

Awesome stuff! Will have a more detailed look.

[nufje]

Arthur,

Thank you. Very niche!

I have a question: is it possible to extend the Bridge so that it is also possible to use the Hub protocol (stdio)?
Because damexchange protocol is very limited...

[ArthurK]

The bridge server is not dependent of the used protocol. You can connect a draughts server that uses the Hub protocol with a webclient that uses the Hub protocol. But you have to build your own Hub webclient. The webclient I created was only meant to illustrate how to build such a client using the damexchange protocol.

[nufje]

Ok, thank you for clarification.

[nufje]

Arthur,

Hopefully you can help me (if you have time and if you want). I have changed the bridge so that it can work with the hub protocol, it only works with one command , when i use the second command i receive error: I/O operation on closed file

I have made the following changes:

1) The main function is changed to

Code: Select all

   if len(sys.argv) == 2:
      arg1, arg2 = sys.argv   # script arguments
      if arg2 == "auto":
         runConsoleHandler(["start", "connect"])
      elif arg2 == 'hub':
         runConsoleHandler(["hub"])
   else:
         runConsoleHandler([])

2) In def runConsoleHandler(stack) i have added a global variable hubProces and added following code to the while loop

Code: Select all

elif comm.lower().startswith('hub'):

         if tWebsocketHandler.server != None:
            # prevent starting websocket handler twice
            print("Websocket server already started")
            continue
         host, port = WS_HOST, WS_PORT  # default
         words = comm.split()
         if len(words) == 2: _,host = words
         if len(words) == 3: _,host,port = words
         try:
            tWebsocketHandler.host = host
            tWebsocketHandler.port = int(port)
            tWebsocketHandler.start()   # exec run() of thread
            #print( "xxx Websocket server started xxx " )
            info_txt = "Listening at %s on port %s for messages from browser clients ..." %(host,port)
            msglog.info(info_txt)
            syslog.info( "Websocket server started at %s on port %s" %(host,port) )
            current.ws_host = host
            current.ws_port = port
         except:
            err = sys.exc_info()[1]
            print( "Error trying to start websocket server: %s" % err )
            continue

         try:
            hubProces = Popen(['./scan', 'hub'], cwd='/home/tobyhage/workspace/scan/', stdout=PIPE, stdin=PIPE, stderr=STDOUT )
         except:
            print( "Error trying to start scan" )

3) Following changes in Class: WebsocketHandler - def onReceive(self, iClient, iServer, iMessage) after: print("\n" + "Message from " + msg_info)

Code: Select all

if hubProces != None:
         hubProces.stdin.write(iMessage)
         output = hubProces.communicate()[0]

I Start the bridge with argument hub and i use the "Test send" in the web client to send hub commands. The first command i send is init, that goes well and after that i send a second command e.g. go think and then i get the I/O operation on closed file error.

I have tried some things but couldn't solve the issue

kinds regards,

Toby.

[Fabien Letouzey]

Hi Toby,

I Start the bridge with argument hub and i use the "Test send" in the web client to send hub commands. The first command i send is init, that goes well and after that i send a second command e.g. go think and then i get the I/O operation on closed file error.

I don't know Python at all, but I get the impression that "communicate" closes stdin? That would explain your error message.
---
The key it to close stdin (flush and send EOF) before calling wait. This is actually what communicate does internally minus all the stdout and stderr stuff I don't need.
---
https://gist.github.com/waylan/2353749

Some people also seem to recommend "pexpect" to handle processes in Python. Maybe you can have a look at what it does: https://github.com/pexpect/pexpect

Fabien.

[Fabien Letouzey]

I don't know Python at all, but I get the impression that "communicate" closes stdin? That would explain your error message.

This page seems to confirm that "communicate" is not what you want, and proposes something else:
https://stackoverflow.com/questions/167 ... ommunicate

Also, don't forget to append '\n' and flush stdin every time.

[nufje]

Fabien,

Thank you for this information, very helpfull!!

regards,

Toby.

[Harm Jetten]

Hello all, just a heads-up that a new release of Moby Dam is available. This is the version that I used at the tournament in Amersfoort on May 19. The changes are minor, I don't expect a noticeable increase in playing strength. Enjoy!

Edit - Here is the link: https://hjetten.home.xs4all.nl/mobydam/mobydam.html