Chess for Android upcoming network feature

[abik]

@Aart: Yes, sorry for sort of hijacking your thread. It is not completely off topic, though.

@Art, sorry for the hijacking your thread. Here we usually look for things to discuss whoever brought up the topics.

Gentlemen, please no apologies! My comment was all in in good jest and my posting has indeed never been this popular
It goes without saying this forum is meant for discussion.

[Daniel Shawul]

You expect much more than I do from the p2p connection. If people want to broadcast their game, they should indeed use a third-party server. The problem I intended to solve is much less ambitious: 2 people want to play a friendly game of (say) Chu Shogi on a Sunday afternoon. Both start WinBoard (alas, no Arena; that does not support Chu Shogi yet) with p2p.exe as engine, one types the IP address of the other in the 'Internet Address' field of the Engine #N Settings dialog, and presses the 'Connect' button there (created by p2p as a -string and a -save option), and starts to play.

That's it.

My app, just like many video games, has a p2p mode where one of the participants become a server by accepting connections on a port. So some will decide to play a game, and some will just observe. Pretty much the same as games I used to play with my friends (Need for speed f.i). Others games with a huge fan base mostly shooter games may have their own servers that people connect to. In any case you need a server for multi-player games i.e p2p or not.

Of course one person could have started WB with p2p plus a second engine, in match mode, and it would act as a fully automatic engine server, letting the connecting person now play against the engine. The connecting party could also have started his GUI with a second engine besides p2p, and hit 'Two Machines' after connecting. Then the engines would play each other, and they can both watch.

No one else can watch. If it should be set up for an audience, one of the players can start the usual broadcasting software next to WinBoard (TLCS, ChessLive!).

Ok you can use other software but what I had in mind was more like the video games I mentioned above that do it themselves.

In case they want to do Chess, and one of them is partial to Arena, it works the same. Arena does not have to accept any commands from p2p. It will get its commands from the person that uses it, either during the game, or when setting it up with an engine.

Arena can only be used as a client since it doesn't matter what is being used on the other side. This is not spectacular, infact my app don't care what is on the other side. It can accept connections from a telnet client (putty f.i) if you can type the moves. No need for adapters since you can simply follow the protocol and type in moves. So that is pretty much a given when you have remote connections. The problem is if it wants to be the server in a p2p it has to accept commands through its adapter which is very difficult to do.

It is not clear to me whatever else you could want to do with it, other than playing games. This is not intended to be an alternative to Remote Desktop. It is not intended to let connecting people select and start up an engine of their choice on the remote machine (ssh would do that fine...).

Not ssh, I wanted something like the p2p connections in video games and I have that working well at least on the desktop. Infact it is pretty much like a gigantic FICS server as it allows the user many choices. I did not want to implement the FICS protocol directly since I found it a little awkward for many variants. If I just start it in console mode it can serve thousands of games at a time . I know you have a variants server with FICS protocol. Anyway by now we have said what we wanted and hopefully cleared up stuff.

[hgm]

My app, just like many video games, has a p2p mode where one of the participants become a server by accepting connections on a port. So some will decide to play a game, and some will just observe.

Well, I had not considered that, but could that not work exactly the same with the adapter? The adapter obviously has to be able to act both as server and as client for two to connect. Once they have connected for setting up a game, they could each continue to accept more connections, and relay the moves also there. I agree observing is made a bit more difficult by the fact that WB protocol does not support a mode where the engine plays both colors. But this can be solved by having the one that wants to observe connect with two p2p loaded as engine. They could let the 'server' p2p know they are an observing pair, and only after they are known as a pair would the server send them all moves done so far in the game that is currently in progress alternatingly to one or the other).

Arena can only be used as a client since it doesn't matter what is being used on the other side.

I still don't understand why you say that. All GUIs are of course always clients of the adapter, but that is does not mean the adapter on that side cannot act as server to the external world.

This is not spectacular, infact my app don't care what is on the other side. It can accept connections from a telnet client (putty f.i) if you can type the moves. No need for adapters since you can simply follow the protocol and type in moves. So that is pretty much a given when you have remote connections. The problem is if it wants to be the server in a p2p it has to accept commands through its adapter which is very difficult to do.

But why do you want it to be a server? What could you possibly want it to do that would require it to be a server???

Not ssh, I wanted something like the p2p connections in video games and I have that working well at least on the desktop. Infact it is pretty much like a gigantic FICS server as it allows the user many choices. I did not want to implement the FICS protocol directly since I found it a little awkward for many variants. If I just start it in console mode it can serve thousands of games at a time . I know you have a variants server with FICS protocol. Anyway by now we have said what we wanted and hopefully cleared up stuff.

Well, if it is a server for many games, I would not call it peer to peer. Because that is clearly a very asymmetric relationship.

[Daniel Shawul]

I still don't understand why you say that. All GUIs are of course always clients of the adapter, but that is does not mean the adapter on that side cannot act as server to the external world.

The adapter on Arena's side can not act as a server as it can not order it to do things. It can only send moves. The adapter needs to tell Arena about the start position (could be from set of epds), moves, take back of moves, resignations, draw offers etc... How is it going to arena to display those if it can not order it. OTOH if it was your app that is on that side, it can order it just like a referee engine does. Think about a situation where you have two arena's on both sides. How can you play games started from EPD positions between two players ?

Well, if it is a server for many games, I would not call it peer to peer. Because that is clearly a very asymmetric relationship.

Why? Peer to peer needs one of them to be a 'server' of games so it is already asymmetric. Ofcourse it doesn't need to be as complex as I made it and it suffices to have features for playing games only (not observing). The difference between a p2p and an FICS server is that in the former case the 'server' is also a participant in the game.

[Don]

Well, I have never done this myself, but isn't it simply matter of specifying

ssh user@system 'fairymax'

as engine command in the local GUI in order to run Fairy-Max as an engine on the remote system (after logging in there as 'user')?

I have done this several times and it's how Komodo communicated with the Keck machine at Leiden.

The only issue is that you set up the encryption keys correctly so that a password is not needed to make the connection.

I think your syntax is correct. There is also ssh for android but I think there are issues - maybe you have to root the device to make it work or something, I have not looked into that too much. That would make it as easy as using xboard. With xboard I think you can use polyglot on either end, since polyglot just makes a program look like a UCI engine and whether it's a remote engine wouldn't matter.

The beauty of Unix/Linux is that when stuff like this comes up there is usually a seamless solution that is not a hack or kludge.

But I think it's really cool that Aart is providing this - since Android doesn't appear to have ssh really built in as a standard utility - and it's a pain making it work with windows anyway.

[Don]

Well, I have never done this myself, but isn't it simply matter of specifying

ssh user@system 'fairymax'

as engine command in the local GUI in order to run Fairy-Max as an engine on the remote system (after logging in there as 'user')?

I have done this several times and it's how Komodo communicated with the Keck machine at Leiden.

The only issue is that you set up the encryption keys correctly so that a password is not needed to make the connection.

I think your syntax is correct. There is also ssh for android but I think there are issues - maybe you have to root the device to make it work or something, I have not looked into that too much. That would make it as easy as using xboard. With xboard I think you can use polyglot on either end, since polyglot just makes a program look like a UCI engine and whether it's a remote engine wouldn't matter.

Correction: I meant to say that polyglot make a program look like a winboard engine.

The beauty of Unix/Linux is that when stuff like this comes up there is usually a seamless solution that is not a hack or kludge.

But I think it's really cool that Aart is providing this - since Android doesn't appear to have ssh really built in as a standard utility - and it's a pain making it work with windows anyway.

[hgm]

The adapter on Arena's side can not act as a server as it can not order it to do things. It can only send moves. The adapter needs to tell Arena about the start position (could be from set of epds), moves, take back of moves, resignations, draw offers etc... How is it going to arena to display those if it can not order it.

Resignations and draw offers are no problem at all. In WB protocol engines can resign and offer draws. As for setting up positions: ICS cannot do this either, (for games), so this was not on my list of desired features. Note that the WinBoard-Alien protocol would allow this without problem, though, (but of course is not supported by Arena.) by using the 'setup' command for that. The only real problem might be takebacks. Note that ICSs also don't accept takebacks without opponent approval. Which is fine if you play a human, but a bot opponent most likely would ignore any takeback request. In the human case my p2p adapter would also have no problem: it would let Arena present the request to the human opponent as a popup, so the user could enter a takeback command into Arena.

OTOH if it was your app that is on that side, it can order it just like a referee engine does. Think about a situation where you have two arena's on both sides. How can you play games started from EPD positions between two players ?

You can't. Just like you cannot do that with two Arenas (or WinBoards, or whatever) that are connected to FICS. But why would you want that? Btw, between humans you could still do it with a p2p adapter when both agree on the starting position, and both enter the same EPD into their respective GUIs. The p2p adapters would see the same setboard command loaded into them from both sides (or the same sequence of moves in force mode), and conclude the setting is viable for starting a game. If not, they would ask one of the sides to comply with the request of the other, displaying the EPD to be entered as a GUI popup through telluser. Just like they would do when the chosen colors do not match. So that already beats a connection through FICS. Between two humans I don't see why one of them should have the power to force an initial position on the other. With Human vs bot the bot can select the EPD through the same mechanism.

If you want to have an engine bot on the remote machine that is a total slave, obeying all your whims like it is a locally loaded engine, there is no reason why there should be a GUI at the other end at all. That task is much more efficiently and straightforwardly performed by ssh, connecting to the remote engine directly. Then you can feed it all the EPDs you want. This problem has already been solved for decades, so it is not within the aim of my p2p pseudo-engine project. My interest is to provide an opportunity for humans to play exotic games for which there exist no servers over the internet with each other.

Why? Peer to peer needs one of them to be a 'server' of games so it is already asymmetric. Ofcourse it doesn't need to be as complex as I made it and it suffices to have features for playing games only (not observing). The difference between a p2p and an FICS server is that in the former case the 'server' is also a participant in the game.

OK, I see. But if participating in the game becomes only a quite minor part of the task, it kind of stretches the p2p concept. I usually leave a Fairy-Max bot on my ICS, and it is running on the same machine that is running the ICS (because that is always on). Does that now suddenly make connections of other people to my ICS to play Fairy-Max a peer-to-peer connection? But this is not really worth discussing. What's in a name, after all?