Differential Synchronization Neil Fraser Google 2009 BENA Pierrick CLEMENT Lucien DIARRA Thiemoko
2 Plan Introduction Stratégies de synchronisation Synchronisation différentielle Vue d ensemble Dual Shadow Guaranted Delivery Topologies Diff et Patch Conclusion
3 Introduction Besoin d applications qui permettent à plusieurs utilisateurs de collaborer en temps réel Google Docs, SubEthaEdit Ces applications utilisent un algorithme de synchronisation L algorithme choisi peut avoir un impact important sur le fonctionnement de l application Synchronisation différentielle Mécanisme minimaliste, impact minimal sur la conception de l application Peut être utilisé dans des applications existantes
4 Introduction Algorithme de synchronisation optimiste, basé sur les états Permet une divergence à court terme Tolère les défauts pour les liens de mauvaise qualité Propage les changements, découvre les conflits et les résout Principe Détection des changements par la différentiation de l état courant avec l état précédent (diff) La différence est propagée aux autres utilisateurs (patch)
5 Introduction Attributs principaux de l algorithme Symétrique : même code côté client et serveur Basé sur les états : ne nécessite pas un historique des éditions Asynchrone : pas de blocage pendant l attente d une réponse sur le réseau Adapté aux réseaux non fiables Convergent, les erreurs ne font pas diverger les copies Extensible Principales utilisations Synchronisation entre différents éditeurs de code Programmation entre des sites distribués Synchronisation d applications en ligne utilisant la sauvegarde automatique (même utilisateur, machines différentes)
6 Stratégies alternatives 3 approches Pessimiste Un document partagé ne peut être modifié que par un utilisateur à la fois Ne permet pas la collaboration, non adapté à un réseau à la connectivité non fiable Basée sur les éditions Capture de toutes les actions des utilisateurs et répercussion aux autres utilisateurs La perte d une modification peut provoquer l application incorrecte des modifications suivantes : chaque édition change la position des éditions suivantes (non convergent)
7 Stratégies alternatives Fusion tripartite (Three-way merge) Le client envoie le contenu du document au serveur Le serveur effectue une fusion tripartite pour extraire les modifications et les combiner aux modifications des autres utilisateurs Le serveur envoie la nouvelle copie du document au client Pas de mise à jour tant que l utilisateur saisit du texte Non extensible pour la collaboration en temps réel sur un réseau avec de la latence
8 Synchronisation différentielle But : maintenir deux versions de texte aussi près que possible l une de l autre en toutes circonstances Deux documents : Texte Client, Texte Serveur sur le même ordinateur Deux opérations : Diff et Patch Cycle sans fin de différence de fond (diff) et des opérations de patch Processus symétrique
9 Vue d ensemble 1. Texte Client est différencié avec le Common Shadow. 2. Cette fonction retourne une liste des modifications (Edits) qui ont été effectuées sur Texte Client. 3. Le Texte Client est copié dans le Common Shadow. Cette copie doit être identique à la valeur du Texte Client à l'étape 1, donc dans un environnement multi-thread un instantané du texte doit être pris. 4. Les modifications sont appliquées au Texte Serveur. 5. Le Texte Serveur est mis à jour avec le résultat du patch. Les étapes 4 et 5 doivent être atomiques, mais pas bloquantes;
10 Vue d ensemble Example of a dataflow : a. Client Text, Common Shadow and Server Text start out with the same string: "Macs had the original point and click UI." b. Client Text is edited (by the user) to say: "Macintoshes had the original point and click interface. (edits underlined) c. The Diff in step 1 returns the following two edits: @@ -1,11 +1,18 @@ Mac +intoshe s had th @@ -35,7 +42,14 @@ ick -UI +interface. d. Common Shadow is updated to also say: "Macintoshes had the original point and click interface. f. In step 4 both edits are patched onto Server Text. The first edit fails since the context has changed too much to insert intoshe anywhere meaningful. The second edit succeeds perfectly since the context matches g. Step 5 results in a Server Text which says: "Smith & Wesson had the original point and click interface. h. Now the reverse process starts. First the Diff compares Server Text with Common Shadow and returns the following edit: @@ -1,15 +1,18 @@ -Macintoshes +Smith & Wesson had i. Finally this patch is applied to Client Text, thus backing out the failed "Macs" "Macintoshes" edit and replacing it with "Smith & Wesson". The "UI" "interface" edit is left untouched. Any changes which have been made to Client Text in the mean time will be patched around and incorporated into the next synchronization cycle. e. Meanwhile Server Text has been edited (by another user) to say: "Smith & Wesson had the original point and click UI. (edits underlined)
11 Méthode Dual Shadow Même algorithme que la version plus simple Le Texte Client et le Server Shadow sont identiques après chaque moitié de synchronisation
12 Problème avec Dual Shadow Si problème au niveau de la connexion à Shadow plus synchronisé Peut entrainer une perte de paquet entrant ou sortant Pour resynchroniser, il faut retransmettre l intégralité du texte Perte des modifications depuis la synchronisation précédente Pas acceptable Nécessité d améliorer le modèle précédent à Méthode Guaranteed Delivery
13 Méthode Guaranteed Delivery Changements apportés au modèle : Backup Shadow Contient la version précédente du fichier à utiliser si perte de synchronisation Edits Mises dans des piles et taguées avec numéro de version du client (n) Envoyées au serveur avec le numéro de version du serveur (m) Si tout se passe bien : les n et m du Server Shadow doivent concorder avec les n et m du paquet entrant Copie de Server Shadow dans Backup Shadow Dans la 2 ème partie du processus le serveur informe le client qu il a bien reçu l edit de la version n à le client efface l edit n de sa pile Résolution des problèmes suivants : Paquet envoyé 2 fois Perte paquet envoyé par le client ou perte réponse serveur
14
15 Topologies Modèle précédent montrait synchronisation entre un utilisateur et un serveur Topologie suivante permet à plusieurs utilisateurs de travailler sur un même fichier Si un client modifie son fichier client «Text», il mettra à jour le fichier «Text» associé sur le serveur pendant le prochain cycle de synchronisation Les modifications sont ensuite redistribuées par le serveur à tous les clients
16 Topologies 2 opérations dans le processus : diff et patch à opérations lourdes Plus il y a de clients et plus le risque de surcharge sur le serveur est grand 2 solutions : Séparer la database du serveur
17 Topologies Topologie serveur-serveur : on répartit les clients entre plusieurs serveurs Problème : plus on augmente le nombre de serveurs et plus la latence augmente Si le client 1 met 5 secondes pour se synchroniser à un changement effectué par le client 1 mettra 15 secondes pour apparaitre au client 4
18 Diff Method Deux rôles : Mettre à jour le Server Shadow avec le contenu courant du texte Client et le Client Shadow Mettre à jour le texte Serveur avec les changements fait au texte Client Diff doit sémantiquement avoir un sens Client Text: The cat is here. Client Shadow: The hag is here. Minimal Diff: The chatg is here. Semantic Diff: The cathag is here. Problème d adaptabilité Algorithme de Diff en texte clair : O(nd) => peu approprié quand il y a beaucoup de changements Comment éviter de lancer tous l algorithme??
19 Diff Method Trois raccourcis : Egalité : une seule opération == Préfixe/suffixe commun : Identifier le préfixe ou suffixe commun peut être effectué en temps linéaire avec une boucle simple, ou en comparant les sous-chaines en recherche binaire. Insertion/suppression singulière O(log n) contre O(nd) Parties d algorithme exécutées fréquemment : Chaque changement individuel édité Mise en place d un timeout pour les changements instantanés d un document entier
20 Opération Patch Opération qui consiste à appliquer les modifications obtenues suite à l opération diff, soit sur les fichiers serveurs, soit sur les fichiers clients. 2 étapes : 1) le fichier est parcouru entièrement afin de trouver le mot qui a la plus petite distance de Levenshtein par rapport au mot modifié Distance Levenshtein : mesure similarité entre deux chaines de caractères 2) trouver une localisation la plus proche possible de la localisation du mot modifié En cas de contenu qu on ne peut pas fusionner, la dernière modification l emporte
21 Adaptative timing La fréquence de mise à jour est un critère important pour les performances du système. Fréquence trop faible rend les opérations diff et patch très lourdes (+ collisions, échec de fusion, frustration utilisateur) Fréquence trop élevée augmente le trafic et surcharge le système Trouver le juste milieu Solutions : Guaranteed Delivery Method permet d envoyer plusieurs diffs ( stockées dans la pile) en une seule fois Utiliser un système adaptatif
22 Améliorations possibles Fuzzy patch Implémentation d une fusion tripartite simple Peut être remplacé par un autre algorithme de fusion tripartite Limitations de l algorithme Un seul paquet de synchronisation à la fois, problématique en cas de latence significative Idée : envoi en continu des mises à jour Garder la trace des utilisateurs à l origine d une édition
23 Conclusion La synchronisation différentielle utilise les algorithmes de différence et de patch existants pour synchroniser les documents L utilisation de la différence élimine la nécessité de détecter toutes les éditions et rend le système naturellement convergent La méthode de synchronisation garantie résout le problème de défaillance réseau Besoin d un canal de communication entre les utilisateurs pour éviter de polluer le document