Chess for Android upcoming network feature

[hgm]

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.

It does not matter what is at the other end of the GUIs.You can have

Human1 <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Human2

just as easily as

Engine1 <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Engine2

or

Human <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Engine

The reason for doing it this way is not simplicity, but universality. The scheme

Player1 <--> GUI1 <===> GUI2 <--> Player2

works only if both GUI1 and GUI2 support the same p2p protocol <===>. In practice this will mean they have to be the same GUI, with only a very small subset of all GUIs bein able to do it. With the adapter-mediated scheme any existing GUI can be used on either side (as long as it can run a normal WB engine). So one side could use SCID vs PC, the other Arena. Or one side could use BCMshogi and the other WinBoard.

The p2p protocol can remain private to the adapters, but of course it could be made public so that newer GUIs could support it directly, if they want to. (To no noticeable advantage of their user, if an adapter exists for their platform.) They can then do

Player1 <--> GUI1 <===> Adapter2 <--> GUI2 <--> Player2

[Daniel Mehrmann]

Good point!

However, ssh isn't designed for chess engines. It's designed for remote commands and manual shell actions (humans work lol). The point is that this tool does much more and support much more. This is finally a security risk in the view of just running a stupid engine. You need to be sure that the ssh configuration is always secure and need to send an update if there comes an security hole up.
Just for my taste it's to much work to run a chess engine.

However, Windows for example has no build in ssh client or server! It's a lot of work to run them anyway and it should be no content if a chessplayer likes to run a remote engine.
Well, you might be noticed that no argument will help you...

[hgm]

Well setting up any server in Windows is a lot of work in any case. If only because you have to deal with poking holes in the fire wall, and port translation in all the routers, modems and what have you. It would be hard to produce something that is clever enough for a 'one-click' install by a noob that would work in nearly all cases.

In terms of security you would also have to re-invent the wheel. My money would be on highly evolved and proven technology, like ssh.

[Daniel Shawul]

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.

It does not matter what is at the other end of the GUIs.You can have

Human1 <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Human2

just as easily as

Engine1 <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Engine2

or

Human <--> GUI1 <--> Adapter1 <===> Adapter2 <--> GUI2 <--> Engine

The reason for doing it this way is not simplicity, but universality. The scheme

You miss my point completely. I already said that is how you communicate but that is what makes it exactly part of the GUI! Now you are talking to two adapters directly so now if two engines with different protocols (say Winboard and Uci) are communicating one adapter has to tell the other to start polyglot and then that tells it to GUI. Or it can start it itself but that would be duplicated work since both GUI and Adapter have the same code now. Now that is the easiest case if you add human, epds etc the adapter has to do far more management operations. But you have that in the GUI already which would become accessible directly if you did p2p with the GUI. You do need those features in the GUI when you are not using p2p. It sounds more like the Referee engine which does many things on behalf of the GUI but we had solid reason for that i.e to enable engine authors to write an adapter for any game. But work is not duplicated between GUI and referee unlike the new case.

Player1 <--> GUI1 <===> GUI2 <--> Player2

works only if both GUI1 and GUI2 support the same p2p protocol <===>. In practice this will mean they have to be the same GUI, with only a very small subset of all GUIs bein able to do it. With the adapter-mediated scheme any existing GUI can be used on either side (as long as it can run a normal WB engine). So one side could use SCID vs PC, the other Arena. Or one side could use BCMshogi and the other WinBoard.

The p2p protocol can remain private to the adapters, but of course it could be made public so that newer GUIs could support it directly, if they want to. (To no noticeable advantage of their user, if an adapter exists for their platform.) They can then do

Player1 <--> GUI1 <===> Adapter2 <--> GUI2 <--> Player2

Arena vs Scid is something new. But still you can have whatever you will have in the adapter, part of the GUI , and avoid messages like "tell GUI to update position" from the adapter, and directly update board instead. There is no reason for separateing GUI and adapter unlike the case of the referee engine.

[hgm]

You miss my point completely. I already said that is how you communicate but that is what makes it exactly part of the GUI! Now you are talking to two adapters directly so now if two engines with different protocols (say Winboard and Uci) are communicating one adapter has to tell the other to start polyglot and then that tells it to GUI.

A think you have a completely wrong notion about what these adapters are supposed to do. Adapters don't 'start' anything. They are engines, and are started as daughter process of the GUI by the the GUI, like any engine. In the process hierarchy they are the ultimate slaves. If Polyglot is needed, the GUI handling the UCI engine will take care of starting Polyglot and putting it in between engine and itself (as usual). The adapter knows absolutely nothing about this. E.g.:

WB engine <--> Arena <--> adapter1 <===> adapter2 <--> WinBoard <--> Polyglot <--> UCI engine

In this example WinBoard was started on the rightmost machine therough the command

winboard -fcp p2p.exe -scp UCIengine.exe -sUCI

taking care of starting Polyglot, UCIengine and p2p.exe. The user on the Arena side would be responsible for starting Arena there. I, sitting on the rightmost machine don't need (and don't want) to know about that.

It sounds more like the Referee engine which does many things on behalf of the GUI but we had solid reason for that i.e to enable engine authors to write an adapter for any game. But work is not duplicated between GUI and referee unlike the new case.

No, referee engines are completely different beasts, and the adapters are not supposed to be able to act as referee engines. That would destroy the whole idea of them being usable for each and every variant. In a GUI reuiring a referee engine, you would start a separate engine as referee, and then play against the adapter pseudo-engine, which is dumb:

Code: Select all

referee1 <----
              |
              V
human1 <--> GUI1 <--> adapter1 <===> adapter2 <--> GUI2 <--> human2

Were GUI2 (or human2) are smart enough to refrain from using a referee

Arena vs Scid is something new. But still you can have whatever you will have in the adapter, part of the GUI , and avoid messages like "tell GUI to update position" from the adapter, and directly update board instead. There is no reason for separateing GUI and adapter unlike the case of the referee engine.

I don't see why you would want the adapter to tell the GUI to update the position. Are you talking about 'variant alien' now? That variant would still be playable by only exchanging moves between the GUIs if both of them were equiped with a referee. If there is a referee loaded, then the GUI should only use the board updates of the referee, and ignore that of the engine. So it doesn't make any difference if the adapter sends board updates or not. (So we choose 'not'.)

The reason for the separation is to be able to use any existing GUI, and thus equip all GUIs that exist in the entire world in one blow with this capability. That seems a good-enough reason to me...

[Daniel Shawul]

A think you have a completely wrong notion about what these adapters are supposed to do. Adapters don't 'start' anything.

No I don't but you repeated ignore my comments. I said they could do that if they want but it would be duplicated work. And then I described the better option of telling the GUI to do it. So now you have something in between which you can completely avoid.

They are engines, and are started as daughter process of the GUI by the the GUI, like any engine. In the process hierarchy they are the ultimate slaves. If Polyglot is needed, the GUI handling the UCI engine will take care of starting Polyglot and putting it in between engine and itself (as usual). The adapter knows absolutely nothing about this. E.g.:

WB engine <--> Arena <--> adapter1 <===> adapter2 <--> WinBoard <--> Polyglot <--> UCI engine

Look at all your notations see the adapter is immediately connected to a GUI. You brought about Arena and other GUIs just in your _last_ post which I pointed out. That is not an argument at all if you have the same GUI on both sides but you want p2p connections then better integrate it into GUI. That is how every p2p game or other app is setup. Don't invent something weird to make a point...

In this example WinBoard was started on the rightmost machine therough the command

winboard -fcp p2p.exe -scp UCIengine.exe -sUCI

taking care of starting Polyglot, UCIengine and p2p.exe. The user on the Arena side would be responsible for starting Arena there. I, sitting on the rightmost machine don't need (and don't want) to know about that.

It sounds more like the Referee engine which does many things on behalf of the GUI but we had solid reason for that i.e to enable engine authors to write an adapter for any game. But work is not duplicated between GUI and referee unlike the new case.

No, referee engines are completely different beasts, and the adapters are not supposed to be able to act as referee engines. That would destroy the whole idea of them being usable for each and every variant. In a GUI reuiring a referee engine, you would start a separate engine as referee, and then play against the adapter pseudo-engine, which is dumb:

Funny how you debate with yourself. I didn't bring up the referee engine to show how variants are played or whatever... The referee engine basically does the job of a GUI so we could have integrated it to the GUI. The only reason why we didn't was because the user could invent many variants meaning different adapters. SO this new adapter you proposed has similar feature in that regard. It can only be useful to separate it from the GUI if it has different behaviours as well. But you only brought up connecting Arena vs Winboard, Arena vs Scid etc just in your last post.
And even at that there aren't many chances for the user to write as many adapters for GUIs as there are adapters for different chess variants. So you might as well integrate it with your gui in short add support to Arena, Scid etc simple.

Code: Select all

referee1 <----
              |
              V
human1 <--> GUI1 <--> adapter1 <===> adapter2 <--> GUI2 <--> human2

Were GUI2 (or human2) are smart enough to refrain from using a referee

Arena vs Scid is something new. But still you can have whatever you will have in the adapter, part of the GUI , and avoid messages like "tell GUI to update position" from the adapter, and directly update board instead. There is no reason for separateing GUI and adapter unlike the case of the referee engine.

I don't see why you would want the adapter to tell the GUI to update the position. Are you talking about 'variant alien' now? That variant would still be playable by only exchanging moves between the GUIs if both of them were equiped with a referee. If there is a referee loaded, then the GUI should only use the board updates of the referee, and ignore that of the engine. So it doesn't make any difference if the adapter sends board updates or not. (So we choose 'not'.)

The reason for the separation is to be able to use any existing GUI, and thus equip all GUIs that exist in the entire world in one blow with this capability. That seems a good-enough reason to me...

Right but we were not talking about connecting entire GUIs in the first place. So either you have to admit it sounds like the referee engine designed to equip all GUIs that exist in the entire world in one blow. Or that it is better to integrate it in the GUI if the purpose is to have p2p connections between your apps ...

[abik]

I am running some tests tournaments and will post some results shortly.

Going back to the original topic, if I may, I picked some engines from the bottom of the qualification tournament I ran on Android a while back and started a new one-second-per move tournament with these engines and the new DeepBrutePosForAndroid, played from both sides all Nunn positions on a Nexus One. The results are below. I was hoping for better results for Folkert, but I hope this provides motivation for lots of future improvements in his program.

Code: Select all

                           1         2           3          4          5         6                    
1 BikJump v2.1P            *      17.5- 2.5  20.0- 0.0  20.0- 0.0  20.0-0.0  20.0-0.0  97.5/100
2 fairymax48q           2.5-17.5      *      10.0-10.0  12.5-7.5   18.5-1.5  20.0-0.0  63.5/100
3 umax48w               0.0-20.0  10.0-10.0      *      12.0- 8.0  20.0-0.0  20.0-0.0  62.0/100
4 Chess for Android     0.0-20.0   7.5-12.5   8.0-12.0      *      17.0-3.0  20.0-0.0  52.5/100
5 Simplex 0.9.7 rev 180 0.0-20.0   1.5-18.5   0.0-20.0   3.0-17.0      *     20.0-0.0  24.5/100
6 DeepBrutePos v1.6     0.0-20.0   0.0-20.0   0.0-20.0   0.0-20.0   0.0-20.0     *      0.0/100

[hgm]

@Aart: Yes, sorry for sort of hijacking your thread. It is not completely off topic, though: you started the subject of adapters by promoting Folkert's connection adapter. Look at it on the bright side: It keeps your thread on top!

No I don't but you repeated ignore my comments. I said they could do that if they want but it would be duplicated work. And then I described the better option of telling the GUI to do it. So now you have something in between which you can completely avoid.

If I ignore them, it is because I think they are not valid points. In fact what you reiterate here is exactly the opposite of what IMO is actually the case. 'Duplicate work' is when you have to implement the same thing in many different GUIs. With an adapter using a protocol they all already know you only have to do it once.

And I still don't see what would be in the adapter that is also in the GUI. Your remark about having the adapter tell the GUI 'how to set up a position' or 'sending move lists' is still totally unclear to me. Why do you think an adapter would need to do any of that? What else can I do with points I don't understand other than ignore them, if no clarification is forthcoming?

In the adapter I propose there would only be some standard server / client code for making the network connection (which would not be in the GUI, which only makes pipe connections to daughter processes), and some algorithm for negociating the color, resigning games in either direction (accompanied by a telluser message) until both ends got it right. After that it would just relay the moves or result commands. None of that would be in the GUI.

Look at all your notations see the adapter is immediately connected to a GUI. You brought about Arena and other GUIs just in your _last_ post which I pointed out. That is not an argument at all if you have the same GUI on both sides but you want p2p connections then better integrate it into GUI. That is how every p2p game or other app is setup. Don't invent something weird to make a point...

Weird? What is weird about wanting to allow Arena users to connect directly with WinBoard users on another machine? People ask for exactly such capabilities in GUIs all the time. And yes, the adadapter connects immediately to the GUI, sitting in between it and the network. That is why it is called an adapter. Polyglot also always connects directly to the GUI. Or engines. Why do you think that is significant? Surely you agree that even though engines always connect to GUIs, it doesn't mean it would be a good idea to incorporate the engine code into the GUI?

But you only brought up connecting Arena vs Winboard, Arena vs Scid etc just in your last post.

Indeed, I brought it up when it became clear that it was not obvious from the beginning (as I thought it would be). What else would you want me to do? If there is a misunderstanding because I was apparently not clear enough in the initial post, should I not clear it up?

And even at that there aren't many chances for the user to write as many adapters for GUIs as there are adapters for different chess variants. So you might as well integrate it with your gui in short add support to Arena, Scid etc simple.

Adding something to Arena would be 'simple'? How? It is closed source... And even if it were not, it would be duplicate work.

Right but we were not talking about connecting entire GUIs in the first place.

I don't understand what you are trying to say here. What is 'connecting entire GUIs'? Are there also half GUIs or quarter GUIs? If we are not talking about it, why do you bring it up? You think we should be talking about it?

So either you have to admit it sounds like the referee engine designed to equip all GUIs that exist in the entire world in one blow. Or that it is better to integrate it in the GUI if the purpose is to have p2p connections between your apps ...

Well, as should be clear now, my purpose is not just to have p2p connections just between two apps. It is to provide a possibility for any two GUIs in the world to connect to each other. OK, the referee engine connects to a GUI. The adapter connects to a GUI. So yes, I suppose in this sense this adapter (and any adapter) is similar to a referee engine (or any engine).

The advantage of a modular approach is flexibility: the user can pick any set of components he likes, without having to accept a package deal, where he has to put up with aspects of the package he doesn't like just because he needs a unique feature only that package offers. This is why we moved away from stand-alone Chess programs, and separated GUI and engine. So that any GUI can be used with any engine, and vice versa.

[Daniel Shawul]

@Aart: Yes, sorry for sort of hijacking your thread. It is not completely off topic, though: you started the subject of adapters by promoting Folkert's connection adapter. Look at it on the bright side: It keeps your thread on top!

No I don't but you repeated ignore my comments. I said they could do that if they want but it would be duplicated work. And then I described the better option of telling the GUI to do it. So now you have something in between which you can completely avoid.

If I ignore them, it is because I think they are not valid points. In fact what you reiterate here is exactly the opposite of what IMO is actually the case. 'Duplicate work' is when you have to implement the same thing in many different GUIs. With an adapter using a protocol they all already know you only have to do it once.

And I still don't see what would be in the adapter that is also in the GUI. Your remark about having the adapter tell the GUI 'how to set up a position' or 'sending move lists' is still totally unclear to me. Why do you think an adapter would need to do any of that? What else can I do with points I don't understand other than ignore them, if no clarification is forthcoming?

In the adapter I propose there would only be some standard server / client code for making the network connection (which would not be in the GUI, which only makes pipe connections to daughter processes), and some algorithm for negociating the color, resigning games in either direction (accompanied by a telluser message) until both ends got it right. After that it would just relay the moves or result commands. None of that would be in the GUI.

Look at all your notations see the adapter is immediately connected to a GUI. You brought about Arena and other GUIs just in your _last_ post which I pointed out. That is not an argument at all if you have the same GUI on both sides but you want p2p connections then better integrate it into GUI. That is how every p2p game or other app is setup. Don't invent something weird to make a point...

Weird? What is weird about wanting to allow Arena users to connect directly with WinBoard users on another machine? People ask for exactly such capabilities in GUIs all the time. And yes, the adadapter connects immediately to the GUI, sitting in between it and the network. That is why it is called an adapter. Polyglot also always connects directly to the GUI. Or engines. Why do you think that is significant? Surely you agree that even though engines always connect to GUIs, it doesn't mean it would be a good idea to incorporate the engine code into the GUI?

But you only brought up connecting Arena vs Winboard, Arena vs Scid etc just in your last post.

Indeed, I brought it up when it became clear that it was not obvious from the beginning (as I thought it would be). What else would you want me to do? If there is a misunderstanding because I was apparently not clear enough in the initial post, should I not clear it up?

And even at that there aren't many chances for the user to write as many adapters for GUIs as there are adapters for different chess variants. So you might as well integrate it with your gui in short add support to Arena, Scid etc simple.

Adding something to Arena would be 'simple'? How? It is closed source... And even if it were not, it would be duplicate work.

Right but we were not talking about connecting entire GUIs in the first place.

I don't understand what you are trying to say here. What is 'connecting entire GUIs'? Are there also half GUIs or quarter GUIs? If we are not talking about it, why do you bring it up? You think we should be talking about it?

So either you have to admit it sounds like the referee engine designed to equip all GUIs that exist in the entire world in one blow. Or that it is better to integrate it in the GUI if the purpose is to have p2p connections between your apps ...

Well, as should be clear now, my purpose is not just to have p2p connections just between two apps. It is to provide a possibility for any two GUIs in the world to connect to each other. OK, the referee engine connects to a GUI. The adapter connects to a GUI. So yes, I suppose in this sense this adapter (and any adapter) is similar to a referee engine (or any engine).

The advantage of a modular approach is flexibility: the user can pick any set of components he likes, without having to accept a package deal, where he has to put up with aspects of the package he doesn't like just because he needs a unique feature only that package offers. This is why we moved away from stand-alone Chess programs, and separated GUI and engine. So that any GUI can be used with any engine, and vice versa.

I will reply to your comments point by point later (i.e continue the heated debate ). Let me just say that I have a working p2p connection that connects my apps to observe and play games against one another using engines or human players. But if I used another GUI on the other side Arena for instance, how is the adapter going to be able to communicate with it unless Arena is willing to accept commands from it? Arena doesn't even connect properly for FICs let alone let it self be handled by a third party adapter. If you just start the adapter as an engine, there is not much you can do with it as Arena always has to be the server! Then there is the problem that Arena accepts only two engines, so even if I let it be the server, you can't watch the game being played there. It is just too much too ask from a third party software. If you have a common server in between like FICS, then different GUIs can be used to act as slaves to it (observe/play a game). But with p2p you have one of them as server ... And as I said the original discussion was about connecting your apps p2p to do whatever you want with it. Many GUIs simply follow their own protocol. Well I will be curious to see how this turns out with or without using an adapter (doesn't matter), once you started coding it.
@Art, sorry for the hijacking your thread. Here we usually look for things to discuss whoever brought up the topics.

[hgm]

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.

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!).

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.

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...).