Chaque fois qu'une modification est enregistrée, je lui associe une révision de la forme
<counter>-<hash>
où counter est un compteur incrémental, et hash est un hash sha1.
Le compteur permet d'avoir un ordre dans les mises à jour; si j'en suis à la version 6 et qu'un changement sur le disque est enregistré, je passe à la révision 7 et j'update le hash (on verra après comment).
Maintenant on passe du côté du receveur: je reçois un message qui me dit Nouvelle version: 7. Si j'en suis déjà plus loin, je rejette. Sinon je prends la nouvelle version après avoir vérifié la signature.
Là où ça se gâte c'est si je suis déjà à la version 7. Dans ce cas je vérifie le hash.
Celui-ci est calculé à chaque révision à partir de la révision précédente et de l'infohash de la version courante. L'idée est que ce hash identifie de manière unique l'historique de l'échange. Du coup, si le hash que je reçois est le même que celui que j'ai, je suis totalement sûr qu'il n'y a pas eu de conflits puisque l'historique est le même; si les hash diffèrent alors j'ai un conflit. Dans ce cas-là ce qui est prévu (et pas encore présent) est de stocker les différentes versions en parallèle, avoir un indice suffisamment compréhensible pour que l'utilisateur voie qu'il y a un conflit:
$ ls
fichier1
fichier1.conflict.123xyz
fichier1.conflict.456abc
le résolve (ça ne devrait pas être plus compliqué que ça):
après quoi rakoshare devra considérer la version gagnante pour ses futurs échanges.
Note que si j'en reçois 2 messages comportant le même compteur mais deux hash différents en même temps, il y en a un que je traiterai avant l'autre puisque je ne traite pas les choses en parallèle, donc on retombe dans le cas précédent.
Pour faire court, rakoshare ne résoud pas les conflits, mais délègue ça à l'utilisateur pour qu'il s'en occupe, tout en éliminant les cas où on a l'assurance qu'il n'y a en fait pas de conflits.
[^] # Re: Specs ?
Posté par rakoo (site web personnel) . En réponse à la dépêche Rakoshare, un outil de synchronisation de dossiers pour tout le monde. Évalué à 7.
Comme Couchdb.
Chaque fois qu'une modification est enregistrée, je lui associe une révision de la forme
où counter est un compteur incrémental, et hash est un hash sha1.
Le compteur permet d'avoir un ordre dans les mises à jour; si j'en suis à la version 6 et qu'un changement sur le disque est enregistré, je passe à la révision 7 et j'update le hash (on verra après comment).
Maintenant on passe du côté du receveur: je reçois un message qui me dit Nouvelle version: 7. Si j'en suis déjà plus loin, je rejette. Sinon je prends la nouvelle version après avoir vérifié la signature.
Là où ça se gâte c'est si je suis déjà à la version 7. Dans ce cas je vérifie le hash.
Celui-ci est calculé à chaque révision à partir de la révision précédente et de l'infohash de la version courante. L'idée est que ce hash identifie de manière unique l'historique de l'échange. Du coup, si le hash que je reçois est le même que celui que j'ai, je suis totalement sûr qu'il n'y a pas eu de conflits puisque l'historique est le même; si les hash diffèrent alors j'ai un conflit. Dans ce cas-là ce qui est prévu (et pas encore présent) est de stocker les différentes versions en parallèle, avoir un indice suffisamment compréhensible pour que l'utilisateur voie qu'il y a un conflit:
le résolve (ça ne devrait pas être plus compliqué que ça):
après quoi rakoshare devra considérer la version gagnante pour ses futurs échanges.
Note que si j'en reçois 2 messages comportant le même compteur mais deux hash différents en même temps, il y en a un que je traiterai avant l'autre puisque je ne traite pas les choses en parallèle, donc on retombe dans le cas précédent.
Pour faire court, rakoshare ne résoud pas les conflits, mais délègue ça à l'utilisateur pour qu'il s'en occupe, tout en éliminant les cas où on a l'assurance qu'il n'y a en fait pas de conflits.