Thank you everyone for all the responses and pointers to artefacts and papers. Cedric, that is an excellent point; thank you. My current intended use is having the user edit file(s) on host A using a text editor, and, when the user saves a file, having those edits reflected as quickly as possible in the corresponding file on host B. So, my primary measure of performance is the speed of update: I want the time between the events "the user, who runs the editor on host A, has issued a command to the editor to save the file" and "the contents of the file the user has just saved on host A and the corresponding file on host B is identical" to be as low as feasible (there is a mapping between file paths on hosts A and B). Sometimes, the user will create a new file on host A; then the file's contents needs to be put as quickly as possible into the corresponding location on host B. One other consideration is that occasionally the user may have their text editor save a number of files in quick (at least in human scale) succession: for example, the user issues "M-x compile" in Emacs, and Emacs offers to save all modified buffers before running the compilation: in that case, the total time to propagate the changes to all modified file(s) should be as low as possible. So, to summarize: 1. One-way synchronization is acceptable (I may find out otherwise with experience, but, for now, I am willing to make that assumption) 2. It is always known which file(s) have been modified. 3. It is probably feasible to plumb through the information about what part(s) of of a file were modified for each file from the text editor to the updater, if that helps with the speed of the update. The editor usually "knows" what has changed, because it needs to be able to undo the changes. 4. The relevant metric is the speed of the update. 5. Sometimes changes to more than one file may be saved in quick (human scale) succession. The relevant metric is still the speed of update to all files. I apologize for the somewhat long-winded description of the metric I care about. I do hope that clarifies it. -- Best, Evgeny ("Zhenya") On Thu, Feb 8, 2018 at 6:44 AM, Yaron Minsky wrote: > Ha! The paper you linked builds off of an old paper I wrote: > > http://cis.poly.edu/westlab/papers/ref/practical.pdf > > There is in fact a full implementation of the algorithms in this paper > in OCaml, as part of the SKS system that I wrote many years ago. > > https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home > > I'm not especially proud of the code, but it does work... > > y > > On Thu, Feb 8, 2018 at 8:11 AM, Cedric Cellier > wrote: > > -[ Wed, Feb 07, 2018 at 07:05:15PM -0800, Evgeny Roubinchtein ]---- > >> I don't want anything that performs worse than rsync in practice, > > > > It would be interesting to know how you measure performance as one could > > think of many metrics: > > > > - speed on different data > > - speed on similar data > > - reliability in face of simultaneous synchronizations > > - reliability in case of bad network > > - usage of resources > > - confidentiality > > - ...? > > > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa.inria.fr/sympa/arc/caml-list > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >