Remote UCI engines tool

Remote UCI engines tool:-

H.G.Muller wrote:
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.)