| 363 | === More on Learning |
| 364 | A party of course can always learn from the sessions it does. |
| 365 | It does not have wait to be used in a Learn protocol. |
| 366 | However the party will have to make the learned information persistent, so that it can be reused in a next run. Additionally, learning usually takes more time than is available in a session. |
| 367 | |
| 368 | A simple way to do this is to store the data in a file. This is less trivial than it looks, because (1) there may be others using the file at the same time, particularly other copies of your party running at the same time (2) the next time, your party may run on an entirely different machine, with no access to the previously written file. |
| 369 | |
| 370 | The appraoch we took currently tries to alleviate some of these issues. If the party is expected to be learning, a parameter {{{negotiationdata}}} is passed to the party at startup, containing a FileLocation. This should contain a non-existing file. The idea is that your party can write essential data to be learned from to this file, and that the learning will take place later in a Learn session. In the meantime, another parameter {{{persistentstate}}} holds info learned so far. |
| 371 | |
| 372 | When a Learn session is entered, the party receives again its {{{persistentstate}}}, but now it has enough time to actually learn and update the persistentstate. It now also receives a list of {{{persistentstate}}} objects, containing all the values it received previously. Now the party can read back what it wrote in the previous sessions, do the learning, and update the persistentstate file. |
| 373 | |
| 374 | Notice that this approach does not solve the assumption that each party runs on the same machine every time. For now, this is simply assumed to be the case. Our current partiesserver implementations run all parties on a single machine. |