TL;DR
Une thèse d’informatique traite des types de données permettant de créer des applications distribuées dont les données convergent sans synchronisation à priori. J’ai traduit et vulgarisé ce papier en deux articles.
Motivation + Introduction
Mon cher coloc m’a fait découvrir en 2014 un papier de recherche qui conceptualise une manière de gérer les données un peu particulière. En informatique, une donnée peut être privée : elle se situe sur le disque dur de l’ordinateur de l’utilisateur uniquement. Elle peut également être publique : elle se situe sur un serveur et d’autres utilisateurs (avec un niveau de contrôle plus ou moins fin) peuvent y accéder. Dans le cas public cependant, il est rare que l’utilisateur possède le serveur qui va distribuer cette donnée, il doit utiliser le serveur d’une entreprise, et cela pose quelques soucis de confidentialité de temps en temps (Dropbox, Facebook, Gmail, etc.).
Il existe une troisième manière de partager une donnée dite de pair-à-pair (en anglais peer-to-peer). Une fois que les clients sont connectés entre eux, plus besoin de serveur. Les logiciels peuvent négocier des données en les morcelant pour réduire la taille des morceaux à demander, et augmenter la possibilité de partage. Le pair-à-pair est répandu pour le partage de fichiers car ces derniers ne varient pas. Mais il est difficile à mettre en place pour des applications dynamiques parce que les algorithmes qui permettent de gérer les conflits au niveau applicatif sont complexes à mettre en œuvre. Qui plus est, personne ne souhaite perdre le dur labeur d’une après-midi de rédaction à cause d’un bogue inopiné, ou d’une perte de connexion dans le train !
Cependant, quelques applications existent comme google docs ou etherpad (hébergé par mozilla par exemple). Bien qu’elles nécessitent un serveur externe, ces applications sont pair-à-pair : elles peuvent continuer de fonctionner quelques minutes en cas de déconnexion réseau, et arrivent au même résultat sur tous les ordinateurs qui regardent et modifient le document en même temps. Chaque lettre entrées par les utilisateurs arrivent dans le désordre sur le réseau, et malgré cela toutes les applications convergent vers la même solution sans se concerter. «La cohérence à terme vise à assurer que les répliques d’un objet partagé modifiable convergent sans synchronisation à priori.»
Deux collègues sont dans le train, sur une connexion 3g intermitente. Chacun modifie le document en même temps. Lorsque la connexion est instable, mais finit par se rétablir, tout se passe comme ci la connexion n’avait jamais été interrompue. L’ensemble est systématiquement cohérent, même après un temps de coupure.
C’est le sujet de cette thèse de l’UPMC que j’ai traduite et vulgarisée pour vous. Elle traite des principes de base qui permettent de simplifier la création d’applications distribuées en reportant de problème de la résolution de conflits au niveau des données. 😉
Photo : Magnificent CME Erupts on the Sun – August 31 – NASA
Légende : L’un des exemples utilisés dans la partie 2 fait référence aux sondes envoyées dans l’espace à la recherche d’environnements propices à la vie.
PS: je m’étais chauffé pour rédiger cette série il y a deux ans, il est grand temps qu’elle sorte au grand jour 🙂
Une réflexion au sujet de « Types de données répliquées convergentes et commutatives »
[…] «La cohérence à terme vise à assurer que les répliques d’un objet partagé modifiable con… […]
Types de données répliquées convergentes et commutatives – Partie 2 : Exemples Pratiques – Sérendipiteur