peer-to-peer relay server

[JoshPettus]

Weird
I have

Code: Select all

-date 1415337213
-installEngine {"Peer2Peer" -fcp "./p2p" -fd "~~/../../bin/p2p"}

And in the user conf I put

Code: Select all

-saveDate 1415337000

And yet it still refuses to put the line in. It only honors it when i remove the -saveDate line altogether.


Also -addMasterConfig puts the new lines after -saveSettingsFile. Isn't that an issue?

[JoshPettus]

And another problem with the plan. What if the user saves a user conf after I have made the app bundle but before updating? (or rather the date I put into master conf)
Say I launch the app on tomorrow on the 8th and the user doesn't see it until December and has been playing the old one during that time. The new engine wont generate when they do update.

Do I fling it in the master conf so far into the future so as to always generate the line, say 9999999999?

[hgm]

That it puts it after the /settingsFile is as it should be, because the settings file of the user must be read first to retrieve his engine list, and the line must be added to that. Otherwise it would be added to the default engine list defined in the master settings file, which would then be overwritten by the user's list. /saveSettingsFile does not trigger any action when it is read; it just alters the name of the file where XBoard would save settings on exit.

The other issue is more serious. This mechanism was designed to handle the case where a new engine would be installed on the machine where XBoard already was, so that the user would have seen the time stamp for its entire existence. So to work for the purpose we want to use it for now, the -date stamp would have to be set to the time the App was installed on the machine.

What would really be needed is that XBoard would be run to perform the -addMasterOption at the time the App was installed on the machine. Is it possible to equip OSX Apps with such an 'install script'?

There still is another solution: the -addMasterOption also works only conditionally, when the line to add is not yet present in the master file. This to avoid problems when an engine is re-installed (e.g. for a version upgrade), and its install script would try to append a new -installEngine with a more recent -date stamp for that same engine, so that users that have already decided they don't want the engine and have deleted the original line, now see it re-appear.

So when we put at the start of the master settings file the option

-addMasterOption {-installEngine '"Peer-to-Peer" -fcp "p2p" -fd "..."'}

(I hope the triple levels of quoting work; untested), this would append to the master settings file the first time you run XBoard

-date TIMEOFFIRSTRUN
-installEngine '"Peer-to-Peer adapter" -fcp "p2p" -fd "..."'

which would then be encountered later, to have its effect on the user's engine list based on the just-added time-stamp. Subsequent runs of XBoard would also encounter the -addMasterOption, but it wouldn't do anything, because it recognizes that the indicated line already occurs in the master settings file, and thus would not add it again with a new timestamp. (This assumes ordinary users would be able to write to the master settings file. On Linux this would therefore not work. But on Linux there are install scripts that can run things (e.g. during "sudo make install"), so the problem doesn't exist. It exists here only because XBoard and p2p are installed at the same time, and it is really the p2p install that should have done this.)

[hgm]

I was thinking: perhaps the relay server could be made more useful by allowing it to somehow export its list of connected p2p clients waiting for a game. It would then be able to fulfill (in a primitive way) the role of a more conventional Chess server.

We could for instance make it attach special meaning to passphrases starting with the word "Public". It would first try to match this passphrase with that of a waiting client, but if there is no match (so that we now would be put in the waiting list ourselves), the relay server could send all passphrases of waiting clients that start with "Public" to us, after having send the "Wait for matching password" message. Currently p2p would ignore all these passphrases (because it is waitig for a line "Password accepted"), but it could be made to show them to the user (e.g. in the Engine Output window, by sending them to the GUI as Thinking Output).

The idea is that people could pick a passphrase like

Public I want to play Omega Chess

and hope that someone who doesn't have an appointment with a fixed opponent will also connect with a Public passphrase, see his game request listed, and then reconnect using that passphrase if he is in the mood for Omega Chess. Or, in stead of reconnecting, use a new option in the Engine Settings dialog to resend the password after changing it. The relay server could then be made to consider input from waiting clients as alterations of their passphrase, and treat them as new arrivals, attempting to rematch them with other waiting clients.

[JoshPettus]

Putting

Code: Select all

-addMasterOption {-installEngine '"Peer-to-Peer" -fcp "p2p" -fd "~~/../../bin/p2p"'}

At the beginning of the master conf does yield

Code: Select all

-date 1415366993
-installEngine '"Peer-to-Peer" -fcp "p2p" -fd "~~/../../bin/p2p"'

at the end of the file. We could also have put it in the gtk launching script, but this is cleaner.

Again, it still doesn't add the line to the user script unless I delete the -saveDate line in the user script entirely. I don't think it's comparing the date like it should.

[JoshPettus]

I was looking at the xboard protocol and saw that engines could send a time command to the GUI. Can we use that to sync the clocks the moment white moves on the second computer? And maintain some sort of sync afterward?

What about the other option so rather then tell the second user to configure upon receiving a proposal, clicking "ok" would let the engine set up the receiving xboard with the proposed game settings for the second user and "no" would let the second user do a counter proposal?

[hgm]

I was looking at the xboard protocol and saw that engines could send a time command to the GUI. Can we use that to sync the clocks the moment white moves on the second computer? And maintain some sort of sync afterward?

Indeed, this is a new feature in XBoard 4.8. But I thought I did not advertize that yet; it is not in the protocol specs on GNU Savannah. It was indeed intended for exactly this type of application, and XBoard should only accept it from engines that were installed by the user with the option -firstPseudo or -secondPseudo. These options would grant the engine extra powers to mess with GUI settings, with the aid of commands that would otherwise be ignored. The 81Dojo adapter (which was ultimately derived from p2p) that I use to let HaChu play Chu Shogi on 81Dojo.com uses this feature to keep XBoard's engine clock in sync with the server clock.

What about the other option so rather then tell the second user to configure upon receiving a proposal, clicking "ok" would let the engine set up the receiving xboard with the proposed game settings for the second user and "no" would let the second user do a counter proposal?

Well, disagreement on the initial position would be pretty rare to begin with. Originally p2p was designed to play standard variants, and sommunicating the setboard commands they might receive was only added later. The position is not the only thing the two sides could differ on. E.g. the TC could also be different, and just exchanging the time on the clock doesn't tell you if that is for one move, for the entire game or for some number of moves. Plus that the user not initiating the game would still have to set its GUI to play the requested side, by clicking MachineWhite or Black. So starting could never be fully automatic.

Of course we could extend the protocol with even more powerful commands, which would enable a total takeover of the GUI by a (pseudo-)engine. Like allowing the engine to issue any command in the menu.

The original design goal of p2p was that it would not just be able to work with XBoard, but with any GUI that supports XBoard engines. So I wanted to limit the dependence on non-standard commands. For 'time' to sync the GUI clocks this is not so bad; it is in many ways an optional feature, as the GUI clocks should already do a reasonable job in tracking the used time by themselves. And if the opponent time starts lagging, it does cause a popup with a request to the user to correct it. So it works even without engine->GUI time commands, and sending those could only make things better, while you are not off any worse if the GUI would ignore them.

The worst flaw in the current design is that it is very cumbersome to take back moves. It would be very nice if the engine could send commands to the GUI that would result in stripping off two halfmoves. OTOH, this should be subject to some acceptance procedure by that player. Now he gets a request to do it himself. But it would be nice of he could accept/reject this request, and if accepting it when would amake p2p strip off the moves, while rejecting it sould order the player wh tried the takeback to replay the moves on his side.

[JoshPettus]

Oh ok, I think we were probably talking about two different time commands. I don't have ESP. XD

Code: Select all

time (boolean, default 1, recommended 1)
    If time=1, xboard will send the "time" and "otim" commands to update the engine's clocks; if time=0, it will not. 

Oh well, nice to know that that is an option for us.

The original design goal of p2p was that it would not just be able to work with XBoard, but with any GUI that supports XBoard engines. So I wanted to limit the dependence on non-standard commands.

This makes sense. I think that is a good goal.

And about the problem 2 posts above?

[hgm]

OK, that is the original time command, for GUI->engine. This is of course also sent to p2p, and can be shared with the p2p on the other end.

The problem is that that p2p also is just another engine, and in original WB protocol it is the GUI that dictates thinking time to the engine, and not the engine that can decide if the GUI clocks run forward or backward. (ICS can do that, but these communicate with XBoard through another channel.) So I added such 'reverse' time commands for the benefit of 'pseudo-engines' like p2p or the 81Dojo adapter.

About the other problem: it could indeed be that there is a bug here in XBoard. Which is kind of strange, as I thought I tested this. Could you, in args.h, delete the words 'unsigned' from the declarations of saveDate and dateStamp:

Code: Select all

unsigned int saveDate;
unsigned int dateStamp;

compile, and try again? XBoard now tests whether saveDate - dateStamp < 0 to decide if it should add the engine, but when they are 'unsigned' their difference will also be considered unsigned, and thus by definition never smaller than 0. (Strange the compiler does not warn us against that, though.)

It could be that at some point after testing I goofed, and replaced 'saveDate < dateStamp' by 'saveDate - dateStamp < 0', not realizing these were declared as 'unsigned'. (For normal ints the latter expression is resistant against overflow.)

[JoshPettus]

Yup that fixed it!