Remote UCI engines and port forwarding

Discussion about chess-playing software (engines, hosts, opening books, platforms, etc...)
ChessDrone
Posts: 78
Joined: Mon Jan 28, 2013 10:56 am

Re: Remote UCI engines and port forwarding

Post by ChessDrone » Sun May 18, 2014 6:53 pm

Hello HG,
where is the tool you talking about? Is that it works with any GUI and protocol (UCI)? And Linux too?

Regards

H.G.Muller
Posts: 190
Joined: Sun Jul 14, 2013 10:00 am
Real Name: H.G. Muller

Re: Remote UCI engines and port forwarding

Post by H.G.Muller » Sun Jun 22, 2014 9:16 am

A Windows binary of the tool can be downloaded from http://hgm.nubati.net/connect.exe .
A Linux i386 binary from http://hgm.nubati.net/connect .

Whether 'connect' runs as a server or a client is determined by its command-line arguments. To run it as a server you have to specify the command in needs to start the engine, the directory it has to issue that command in, the port on which to listen for incoming connections, and the password. Like

connect.exe -ec ENGINE.exe -ed ENGINEFOLDER -p PORTNUMBER -pw PASSWORD

They have to be given in that order, but, apart from the engine command, can be omitted, in which case the default values will be used. Default port is 27015, default password is "Have fun, have WinBoard!", and default directory is the current directory. The server keeps running until you kill it (when starting it from the command prompt, by typing Crtl-C); if someone connects to the port providing the right password it will create an engine process, which will run until the user disconnects, after which the engine will receive a quit command, and the server goes back to listening mode to wait for a new client.

To run it as a client (i.e. the engine command you have to install in the GUI), you will need to specify the host address, and (optionally) the port and password, like

connect.exe -p PORTNUMBER -pw PASSWORD HOSTADDRESS

Again the arguments must come in exactly this order, but the port and password are optional if you are happy with the default.

It should be protocol independent, as it does not interpret the traffic in either direction, but just passes it on. Except for the quit command: if the client receives a line "quit" on its input, it does not just forward it to the server, but disconnects. But both WB protocol and UCI use that same command. The client prints a spontaneous welcome message when it connects, but I don't think that is a violation of UCI protocol. (It is certainly allowed in WB protocol; most WB engines do it.)

For the benefit of running under XBoard I also made the client scan for a "protover" command, so that it can send a "feature" command in immediate reply to switch off XBoard's nasty habit of sending interrupt signals to its engines, and a "done=0" feature to make sure XBoard will wait long enough for the connection to be made, and not time out waiting for the engine features when this takes a long time. But this would never be triggered in UCI, as the GUI would not send a protover command there. (In UCI there is no timeout, and the GUI will wait unconditionally for "uciok", no matter how long it takes.)

itias
Posts: 7
Joined: Wed Aug 01, 2012 10:19 am
Real Name: Greg

Re: Remote UCI engines and port forwarding

Post by itias » Wed Sep 17, 2014 7:57 pm

Hi HG,

Thanks for the tool, looks promising and I'm going to see if it works in scenario I presented 2 years ago. I know it is an old thread ;)
I was also wondering if you could consider putting your tool on sourceforge or in some place where it will last another couple of years if people are interested in.
But of course this is your intellectual property and it is just a polite request, nothing more ;)

Thanks

Greg

itias
Posts: 7
Joined: Wed Aug 01, 2012 10:19 am
Real Name: Greg

Re: Remote UCI engines and port forwarding

Post by itias » Fri Jan 23, 2015 3:48 pm

Just a followup. I was finally able to reach my goal with netChess and port forwarding. My issue was caused by putty settings for reverse tunnel. It turned out that with putty (and reverse) you can either listen locally or on all interfaces, and there is no way to listen on selected interface only.

H.G.Muller
Posts: 190
Joined: Sun Jul 14, 2013 10:00 am
Real Name: H.G. Muller

Re: Remote UCI engines and port forwarding

Post by H.G.Muller » Fri Jan 23, 2015 8:03 pm

The 'connect' tool did not work?

JesseGersenson
Posts: 10
Joined: Thu Feb 17, 2011 9:15 am
Real Name: Jesse Gersenson

Re: Remote UCI engines and port forwarding

Post by JesseGersenson » Wed Sep 02, 2015 12:10 pm

"The 'connect' tool did not work?"

I wouldn't use this close-source application to access my network.

H.G.Muller
Posts: 190
Joined: Sun Jul 14, 2013 10:00 am
Real Name: H.G. Muller

Re: Remote UCI engines and port forwarding

Post by H.G.Muller » Tue Oct 06, 2015 1:39 pm

That is of course your right. You probably also don't use Windows computers on your network, and closed-source engines like Komodo, and closed-source GUIs like ChessBase?

JesseGersenson
Posts: 10
Joined: Thu Feb 17, 2011 9:15 am
Real Name: Jesse Gersenson

Re: Remote UCI engines and port forwarding

Post by JesseGersenson » Fri Dec 02, 2016 10:27 am

H.G.Muller wrote:That is of course your right. You probably also don't use Windows computers on your network, and closed-source engines like Komodo, and closed-source GUIs like ChessBase?
Correct.

Here's a write-up I wrote about connecting a remote engine on a Linux machine with a Windows chess GUI. One easy, though closed source, tool is InBetween.exe:
https://komodochess.com/remote-engine.htm

kevinfat
Posts: 13
Joined: Tue Aug 09, 2011 3:42 am

Re: Remote UCI engines and port forwarding

Post by kevinfat » Thu Jun 01, 2017 4:20 am

Why don't you guys use Chess Engine Cloud http://www.engine-cloud.com/
I've never tried it myself. Has anyone here tried it and what do you think?

Post Reply