Chess for Android upcoming network feature

[abik]

Normally people use ssh for this.

Perhaps, but as already discussed above, this may be as involved as shipping ssh with the chess GUI in some cases. Networking on Android is extremely simple, and other than the initial setup of a third party engine binary or network socket, the rest of the UCI/XBoard code in my GUI is completely unaware of the difference.

The reason network engines were not first class citizens yet had more to do with additional complications such as prompting the user for a host port in addition to general engine options and deciding under what name to save earlier selected choices. I am removing some of these artificial barriers with as goal to make tournament participation possible for a network engine (cross-platform in most cases, within the platform in Folkert's interesting application).

[abik]

Ah, and I forgot to add, the built-in network engine support is just for user convenience. Earlier, PJ+ already wrote a network utility that effectively presents itself as an engine to Chess for Android, but really just makes a connection to a remote chess server under water. The setup is a little elaborate, but only has to be done once if the connection parameters do not change.

PJ+ used this approach to connect Chess for Android to a remote chess server with Houdini, yielding over 25,000KNs "on" a smart phone.

[hgm]

Well, this is basically what ssh also does (on Linux), when you run it with the proper command-line arguments. It behaves indistinguishably from the engine that is running on the host.

XBoard can actually invoke ssh automatically. With the aid of the XBoard options -remoteShell, -firstHost and -secondHost (plus engine specification) it forms the required ssh command transparently. So there are two ways to run engines remotely:

1) You can give a complete ssh command line for a remote engine, and install that as an engine. The engine will then always play on that remote machine when it is invoked.

2) You can start XBoard with -firstHost and -secondHost specified (possibly different). That XBoard instance will than always run the engines whose turn it is to play in the tourney on those machines. So sometimes an engine can play on one machine, sometimes on another, depending whether it is first engine or second engine in the particular pairing. (You'd better make sure all engines are installed on both machines, or this will not work...)

The second method is especially useful in combination with concurrent play. You could give each XBoard instance playing games for the tourney different -firstHosts and -secondHost options, so that all games that are played concurrently take place on different machines.

[Daniel Shawul]

To keep an app as small as possible, it is good to support only one client connection mode (eg. socket) and one language (eg. winboard). Then the user can use external tools such as: "polyglot" for uci ,"ssh" or "putty" for remote exec and "java" for java engines or any other "in between" tool as in the case of PosForAndroid ... Usually these external tools do a far better job than whatever minimal code you incorporate in an app. I don't even support native UCI protocol for that reason. For my app that supports many games,there are just too many adapters to support so the natural choice is to leave it up to the user/programmer. The downside of this approach is that android do not come bundled with some common external tools that you would expect to have in an os specially when it is big as in the case of JVM. But you would need an ssh client in your phone anyway for some other purpose, and it is not that big.

My app has the following features that enables it to do many things from the resulting combinations. Some of them could be really weird combos.

Code: Select all

Languages : 
            Winboard
            ICS protocol 
            IGS protocol (native game server protocol for many variants)
            Database of games/epd (for testing)
Client connection modes: 
            Local process (exec)  
            Socket.  (A socket can be used for a local process so really there is one connection mode).
Players:
            Human
            Computer
Type:
            Server (thousands of games can be serverd from the phone simultaneously)
            Client (Users can connect to observe/play games on your phone)

Many of these features are _not_ tested on the android app but the corresponding java application works well on the pc.

[abik]

Some valid points, although sometimes choices are historical, sometimes merely for user convenience.

As example of the first, Chess for Android started with UCI support in 2010 and added Win/XBoard support a bit later. And even though recently I showed that Polyglot for Android works just fine as well, there is no reason for me now to remove UCI support

As example of the second, PJ+'s utility has already been used for a long time to import remote chess servers into Chess for Android (so they are directly first class citizens). By popular demand, however, I also added built-in support for connecting a network socket. These built-in network engines were not first class citizens yet, and my posting merely served to announce that this would soon be resolved. But it is great to see a nice discussion going!

[hgm]

Another adapter that would be useful to have is a peer-to-peer network connection. To the GUI such a pseudo-engine would just look like any other WB engine, but it would make it possible to play against each other over the internet without having to use a third party server such as an ICS. (Especially useful for games for which no servers exist yet.)

I hope to produce such a pseudo-engine for PC shortly. (After I am done building my Chu Shogi engine.)

[Daniel Shawul]

I suppose you are replying to me.

Some valid points, although sometimes choices are historical, sometimes merely for user convenience.

As example of the first, Chess for Android started with UCI support in 2010 and added Win/XBoard support a bit later. And even though recently I showed that Polyglot for Android works just fine as well, there is no reason for me now to remove UCI support

Well yes because the adapter will do all the job so you can be sure it works without even testing. Packaging the adapter with your app is the same us writing code yourself in your app except the latter is tedious and not extensible when you have general game playing in mind (not just chess)

As example of the second, PJ+'s utility has already been used for a long time to import remote chess servers into Chess for Android (so they are directly first class citizens). By popular demand, however, I also added built-in support for connecting a network socket. These built-in network engines were not first class citizens yet, and my posting merely served to announce that this would soon be resolved. But it is great to see a nice discussion going!

A socket connection encompasses everything so it can be used for local/remote engines, connecting to servers, connection to another phone etc... The problem is with defining _protocols_. I have four of them already. I like this server/client design with communication protocol. Even epd testing against engines/humans (remote or local for that matter) are done this way ,after installing an EPD server engine.For my case all engines (humans, local engines, remote engins, ICS servers/clients etc..) are installed the same way. They all share the same interface and are installed using command line and working directory. The type of the game play is decided from the selected engines. For example if a TCP server engien is selected, then the app would act like a dumb client. If a human engine is selected, it provides gui input to it etc.. This makes life much easier

[Daniel Shawul]

For peer-to-peer one of them need to act as a server i.e forwarding positions, move list etc. and also to decide game termination. Ofcourse this requires defining a communication protocol so it can't be a simple adapter. Connection could be to observe or examine a game and not for playing. So it is not an adapter in the sense that it is not used for translation of protocol. It has to keep a database and do other things so it is more part of the gui.

[hgm]

Not really. They can just ping-pong moves. The pair of them can be made to act as a pure WB engine towards either side. Since they are connected to a GUI on each side, there is no need to exchange move lists.

The only things they have to synchronize is start-of-game and the color. An unconnected one will withold pong in reply to new+ping until it was aproached for a connection. The one that connects ('client') acknowledges the new immediately, so that that side can start with a move or go, depending if he wants white or black. When it relays either of these, the other side ('server') can then acknowledge ping, and if the GUI there wants to play the wrong side, it can immediately resign towards the GUI, (without notifying the client), in the hope that that GUI will alternate color (which it will, when it is an unattended server running in match mode).

After the resign the server GUI should now come with the go or move complementary to that of the client, and the game can continue by just relaying moves. If the second game still has the wrong color (e.g. both sides start with 'go', because both want to play black), it can be taken as a counter proposal, and now makes the client resign towards its GUI as a rejection of the original proposal. (Such rejections can be accompanied by a 'telluser' command to request the user to start in the needed color.)

[Daniel Shawul]

Not really. They can just ping-pong moves. The pair of them can be made to act as a pure WB engine towards either side. Since they are connected to a GUI on each side, there is no need to exchange move lists.

Well p2p connection is not merely to match two chess engines. What about two human players ? Human vs engine ? Human vs Epd test etc.. So with all these combinations it is much simpler to have a socket connection between the two GUI's rather than two participants so that all the features of the GUI become immediately accessible. Also observing or examining games should be possible with a p2p. In most cases, you would like to see a board displayed, so that is why position and move lists are exchanged.

The only things they have to synchronize is start-of-game and the color. An unconnected one will withold pong in reply to new+ping until it was aproached for a connection. The one that connects ('client') acknowledges the new immediately, so that that side can start with a move or go, depending if he wants white or black. When it relays either of these, the other side ('server') can then acknowledge ping, and if the GUI there wants to play the wrong side, it can immediately resign towards the GUI, (without notifying the client), in the hope that that GUI will alternate color (which it will, when it is an unattended server running in match mode).

After the resign the server GUI should now come with the go or move complementary to that of the client, and the game can continue by just relaying moves. If the second game still has the wrong color (e.g. both sides start with 'go', because both want to play black), it can be taken as a counter proposal, and now makes the client resign towards its GUI as a rejection of the original proposal. (Such rejections can be accompanied by a 'telluser' command to request the user to start in the needed color.)

Well then even connecting two 'self-playing' chess engines required some thought. GUI1->Adapter1--->Adapter2<--GUI2 is more complicated than GUI1->GUI2 except for the need to define a new protocol. When you go remote it is better to define a new protocol than redirecting input/output. What if one is UCI that can't talk directly to a winboard engine? My app can do p2p connection directly through the GUI1->GUI2 approach by defining a new protocol (FICS protocol was too chessic for me), and it can do many things transparently with ease.