Cohérence de copies multiples en environnement sans fil

Transcription

1 Cohérence de copies multiples en environnement sans fil Sophie Chabridon CSC 5004 ASR8 Janvier 2009

2 Plan de la présentation 1 Introduction Cas des applications discrètes Cas des applications continues Pour aller plus loin TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 2/53

3 1 Introduction 1.1 Définition Mobilité et réplication Réplication pessimiste Réplication optimiste Modèles de cohérence Deux catégories d applications TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 3/53

4 1.1 Définition 1 Introduction Un service de cohérence de données répliquées et partagées est un service capable de contrôler le nombre de répliques, leur localisation, leur déplacement, et leur contenu en fonction de leurs attributs, de l environnement d exécution et des contraintes applicatives. TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 4/53

5 1.2 Mobilité et réplication 1 Introduction Dans le contexte des environnements mobiles, besoin de répliquer les données pour : Améliorer les performances et augmenter la disponibilité des données Offrir continuité de service en cas de déconnexion réseau Préserver l autonomie : travail collaboratif, jeux multijoueurs... Solutions envisageables pour la gestion de données - Choix? Réplication pessimiste Prise d un verrou avant de modifier une donnée Pas de mise à jour concurrente Evite les conflits a priori Réplication optimiste Mises à jour concurrentes autorisées Apparition possible de conflits Nécessité d une phase de réconciliation a posteriori TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 5/53

6 1.3 Réplication pessimiste 1 Introduction Encore appelée réplication synchrone Propagation impatiente (eager) des mises à jour Cas d une base de données : mise à jour des différentes copies au sein de la même transaction Equivalent à la sérialisabilité sur une copie unique 1-copy serialisability [Bernstein et al., 1987] : Une exécution d un ensemble de transactions sur une base de données dupliquée est sérialisable si elle est équivalente à une exécution en série de ces transactions sur une base de données non dupliquée TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 6/53

7 1 Introduction Réplication pessimiste (2) Avantages Simple à mettre en oeuvre Cohérence des copies garantie en empêchant l apparition de divergences Inconvénients Ne passe pas à l échelle avec un grand nombre d écritures Vulnérable Etreinte fatale (deadlock) Déconnexions Latence TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 7/53

8 1.4 Réplication optimiste 1 Introduction Encore appelée réplication asynchrone Propagation paresseuse (lazy) des mises à jour Cas d une base de données : Transaction initiale met à jour une seule copie Ensuite propagation asynchrone aux autres copies au sein de transactions séparées TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 8/53

9 1 Introduction Réplication optimiste (2) Avantages Permet de modifier une copie locale Seule approche possible en environnement mobile pour la continuité de service Tolère Déconnexions Latence variable Inconvénients Ne passe pas à l échelle avec un grand nombre d écritures Apparitions de divergences transitoires Complexe à mettre en oeuvre TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 9/53

10 Réplication optimiste - Exemples 1 Introduction Usenet Publication de messages dans des groupes de news Opération principale : envoi de messages indépendants, pas de conflit Utilisateurs acceptent de voir la réponse et quelque temps après la question Systèmes de fichiers répartis Basés sur la règle de Thomas : Last writer wins Conservation du dernier état seulement Utilisateurs acceptent de perdre des écritures TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 10/53

11 1.5 Modèles de cohérence 1 Introduction Nombreux modèles ont été définis pour les systèmes distribués (à mémoire distribuée partagée, gestion de bases de données...) Non détaillés dans ce cours. Voir Chap 6 de [Tanenbaum and van Steen, 2002] Classification proposée par [Tanenbaum and van Steen, 2002] : Modèles centrés sur les données Avec synchronisation permanente : stricte, séquentielle, causale, FIFO Avec synchronisation uniquement à des moments précis, lors de la prise ou du relâchement d un verrou faible, au relâchement, en entrée Modèles centrés client Monotonic reads Monotonic writes Read your writes Writes follow reads TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 11/53

12 1 Introduction 1.5 Modèles de cohérence Cohérence à terme Eventual consistency En l absence de nouvelles mises à jour, l ensemble des copies convergent vers la même valeur Garantit que les opérations d écriture seront propagées Modèle de cohérence le plus faible Aucun ordre sur les opérations n est imposé La plus adaptée aux environnements mobiles TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 12/53

13 1 Introduction 1.5 Modèles de cohérence Cohérence continue Modèle TACT : Tunable Availability and Consistency Tradeoff [Yu and Amin, 2001] Niveau de cohérence peut fluctuer entre cohérence forte : obtenue par la réplication pessimiste cohérence faible : obtenue par la réplication optimiste Trois métriques Erreur numérique : nombre maximal d écritures manquées Erreur d ordre Manque de fraîcheur (staleness) Détermination de bornes max (upper bound) pour chaque métrique Corrélation entre disponibilité de service et niveau de cohérence Placement des copies pour maximiser la disponibilité TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 13/53

14 1.6 Deux catégories d applications 1 Introduction Applications discrètes Etat change uniquement en fonction d opérations de lecture/écriture Exemples : News Bases de données Systèmes de fichiers Applications continues Etat change à la fois avec les opérations de l utilisateur ET avec le passage du temps Exemples : Supervision d un procédé industriel Applications multimedia interactives et Distribuées : Réalité virtuelle, réalité augmentée, Jeux vidéo, Performances musicales en réseau (concert réparti), Théâtre virtuel TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 14/53

15 2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification Maintien de la cohérence Résolution de conflit Bayou IceCube Transformées opérationnelles Travaux basés sur SOCT TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 15/53

16 2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification Caractéristiques : Opérations de lecture/écriture Faites à des instants précis Critères de classification et de comparaison voir Etat de l art paru en 2005 [Saito and Shapiro, 2005] Modèle de transfert : maître unique ou multi-maîtres Unité de transfert : état vs opération Sens du transfert : pull vs push TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 16/53

17 2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification Modèle de transfert Maître/écrivain unique Site primaire seul autorisé à faire les mises à jours et à les diffuser aux autres répliques Bon passage à l échelle si nombreuses écritures Mais : master = point de défaillance et goulot d étranglement Multi-maîtres Chaque copie peut être mise à jour à tout instant et assure la diffusion des mises à jour aux autres copies Meilleure disponibilité mais complexe Nécessite une technique globale de détection et de résolution des conflits TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 17/53

18 2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification Unité de transfert Etat Transmission du nouvel état Simple à mettre en oeuvre Ne facilite pas la réconciliation : un état en remplace un autre Opération Conservation de la suite des opérations effectuées (histoire) Convergence obtenue en rejouant les opérations sur chacune des copies Permet différentes stratégies de réconciliation TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 18/53

19 2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification Mode de transfert A la demande (pull) Une copie doit interroger le maître/une autre copie afin de récupérer la nouvelle valeur Interrogation périodique Sur notification (push) Lorsqu une copie est mise à jour, elle doit en informer les autres copies En multi-maître, nécessite un mécanisme de diffusion efficace TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 19/53

20 2.2 Maintien de la cohérence 2 Cas des applications discrètes Distribution des Majs entre les copies Détection et résolution des conflits entre les Majs conflit : violation de la cohérence dépendance entre 2 opérations : relation "happens-before" cohérence interne vs externe interne : entre les répliques d un même objet externe : définition d invariants sur un ensemble d objets conflit syntaxique vs sémantique syntaxique : basé uniquement sur l occurrence des opérations sémantique : lié à la sémantique de l application TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 20/53

21 2.3 Résolution de conflit 2 Cas des applications discrètes A la charge de l utilisateur Ex : Lotus, Palm Pilot - 2 versions de l objet sont présentées pour choisir Résolution automatique selon la sémantique de l application Ex : Coda, Locus, Ficus, Roam - programmes de résolution prévus pour des types de fichiers connus Limitée dans le cas des systèmes à transfert d état Plusieurs propriétés à respecter pour garantir l uniformité sur toutes les répliques : déterminisme commutativité : résultat identique indépendamment de l ordre TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 21/53

22 2.4 Bayou 2 Cas des applications discrètes Projet de Xerox PARC ( ) [Terry et al., 1995, Petersen et al., 1997] Système de gestion de bases de données collaboratives mobiles Transfert d opérations Critères syntaxiques (basés sur les estampilles) pour déterminer l ordre d exécution des opérations Chaque écriture est estampillée (accept-stamp) et marquée à l aide de l id de l écrivain Protocole Primary Commit : Estampille de validation ( tant que l opération n est pas validée) Serveur primaire estampille les opérations (séquenceur) Cohérence obtenue avec ordre global par un consensus centralisé TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 22/53

23 2 Cas des applications discrètes Bayou (2) Pour chaque opération, le développeur de l application doit définir un test de vérification des dépendances (détection de conflit) une procédure de fusion (merge) Chaque site maintient un journal des écritures et une copie de la base de données Propagation des mises à jour par un algorithme anti-entropique épidémique Retour arrière possible (rollback) Faiblesse principale : complexité de l écriture de la procédure de fusion TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 23/53

24 Bayou - Exemple d architecture 2 Cas des applications discrètes TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 24/53

25 2.5 IceCube 2 Cas des applications discrètes Travaux démarrés en 2000 par M. Shapiro chez Microsoft Research Laboratory (UK) [Kermarrec et al., 2001] Basé sur une exploration heuristique des ordonnancements possibles Applications visées : Applications collaboratives mobiles Définition très détaillée de contraintes Contraintes statiques, indépendantes de l état de l objet : log, object Contraintes dynamiques (assertion, détection de conflit à la Bayou...) Extension de Bayou, avec prise en compte de la sémantique des opérations et flexibilité pour l ordonnancement des opérations TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 25/53

26 2 Cas des applications discrètes IceCube (2) Gestion de plusieurs versions de l état répliqué des données partagées Réconciliation des logs de deux copies en 3 étapes : 1. Génération d ordonnancements en combinant les opérations des 2 logs en respectant les contraintes statiques 2. Simulation : abandon d un ordonnancement si non satisfaction des contraintes dynamiques 3. Sélection d une solution optimale Proposition d un modèle de cohérence Décomposition de la dépendance causale en deux nouvelles notions before : une opération en précède une autre must have : une opération ne se produit que si autre opération a été exécutée avec succès et fait partie de son histoire TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 26/53

27 2.6 Transformées opérationnelles 2 Cas des applications discrètes Permet de transformer une opération (changement de paramètres...) afin de sérialiser des opérations concurrentes (potentiellement non-commutatives) pour assurer la convergence des copies Preuves théoriques associées ([Vidot, 2002]) Plusieurs types de transformées Transformée en avant : tient compte de l effet d une opération concurrente Transformée en arrière : change l ordre d exécution de deux opérations Transformée inverse TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 27/53

28 2.7 Travaux basés sur SOCT4 2 Cas des applications discrètes SOCT4 : Sérialisation des opérations concurrentes par transposition [Vidot, 2002] Conçu pour le travail collaboratif à contraintes de temps Exploitation des propriétés sémantiques des opérations Utilise la transformée en avant uniquement Ordre global continu (besoin d un séquenceur) Une seule condition (C1) à vérifier pour converger TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 28/53

29 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT Précédence causale vs concurrence TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 29/53

30 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT Critères pour le maintien de la cohérence 1) Préservation de la causalité : Ordre d exécution identique sur tous les sites Livraison causale des opérations à l aide de vecteurs d état [Mattern, 1989] TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 30/53

31 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT4 2) Préservation de l intention de l utilisateur : Gestion des opérations concurrentes (-> transposition avant) 3) Convergence des copies : La fonction de transposition avant doit vérifier : C1 : op1.op2 op1 op2.op1 op2 Résolution des conflits TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 31/53

32 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT4 Au moment de l écriture des transformées Choix arbitraire si possible en garantissant que le même choix sera fait sur tous les sites Sinon, définition d un conflit avec réconciliation par les utilisateurs TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 32/53

33 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT Exemple : Transformée avant pour un éditeur de texte Transpose_forward (insert(p1, c1), insert(p2, c2) ) { // Param1 : opération locale, Param 2: opération distante case p1? p2 of p1 < p2 : return insert(p2 +1, c2); p1 > p2 : return insert(p2, c2); p1 = p2 : if c1 = c2 then return id else // Cas d un conflit // Choix selon valeur du caractère if code (c2) > code (c1) then return insert(p2, c2) else return insert(p2+1, c2); endif; endif; endcase } TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 33/53

34 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT Extensions de SOCT4 SOCT4 suppose une connexion permanente entre les sites Une opération est diffusée immédiatement aux sites distants Travail collaboratif multi-synchrone [Bouazza and Molli, 2000] Travail local avec possibilité de mesurer la divergence Synchronisation périodique possible pour faciliter la convergence Modes de travail couplé et découplé, avec basculement d un mode à l autre En mode couplé (phases synchrones) utilisation de SOCT4 En mode découplé (phases asynchrones) Placement des opérations générées localement dans une file, sans estampille Mise en attente des opérations distantes reçues pour traitement différé L utilisateur/application décide quand envoyer les opérations locales intégrer les opérations distantes TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 34/53

35 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT4 Extensions de SOCT4 pour le multisynchrone TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 35/53

36 2 Cas des applications discrètes 2.7 Travaux basés sur SOCT Extension de SOCT4 pour la mobilité : SOCT4mob [Chateigner et al., 2004] Pas de site fixe Communication directe entre les sites joignables (Utilisation de Javagroups) Séquenceur réparti Déconnexion volontaire Diffusion préalable des opérations locales déjà estampillées Pendant la déconnexion Travail isolé sur les composants déconnectés et journalisation des opérations locales A la reconnexion Récupération des opérations des autres sites et intégration dans l histoire Diffusion des opérations effectuées localement après estampillage TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 36/53

37 3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs Point sur l état de l art Dead reckoning Pre-reckoning TimeWarp Trailing State Synchronization - TSS RendezVous Synthèse sur l état de l art TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 37/53

38 3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs Développement des jeux multijoueurs tributaire de la qualité du réseau Latence élevée des réseaux de téléphonie mobile 2, 2.5 et 3G plusieurs secondes Latence tolérée par un être humain 250 ms [Pantel and Wolf, 2002] Etude des solutions déjà utilisées dans les jeux multijoueurs en réseau fixe Sont-elles adaptées aux téléphones mobiles (capacité de calcul et mémoire limitées)? TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 38/53

39 3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs Caractéristiques des jeux multijoueurs Importance de la notion de temps Applications continues Etat modifié par les opérations effectuées ET par le passage du temps Temps de jeu vs temps réel Durée entre deux événements dans le jeu doit rester proche de la durée dans le monde réel Exemple du décollage d un avion : pas plus de quelques minutes de calcul Impact de la latence diffère suivant le type de jeu Exigence la plus forte : Jeux de tir (First-Person Shooter) avec latence tolérée de seulement 150 ms Exigence la plus faible : Au tour par tour TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 39/53

40 3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs Caractéristiques des jeux multijoueurs (suite) Trois classes de données Données locales Propres à un joueur - affichées localement Données distantes Besoin de cohérence primordial - pas de copie locale Données partagées Besoin de disponibilité primordial - copie locale à synchroniser avec les copies distantes Priorité à la jouabilité au détriment de la cohérence TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 40/53

41 3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs Impact de la latence - Exemple Cas d une course de voitures [Pantel and Wolf, 2002] Qui a gagné? TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 41/53

42 3.2 Point sur l état de l art 3 Cas des applications continues Solutions en environnement fixe Méthodes de prédiction d état Dead reckoning Pre-reckoning Méthodes de synchronisation Time Warp Trailing State Synchronisation Solution sur téléphone mobile RendezVous TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 42/53

43 3.3 Dead reckoning 3 Cas des applications continues Signifie "calcul par déduction" (Deduced reckoning) Recommandé par la norme IEEE DIS (Simulation Interactive distribuée) [IEEE, 1995] But : Minimiser le nombre de messages échangés entre les sites Prédire le mouvement des objets des sites distants sans rafraîchissement systématique Utiliser uniquement les paramètres connus localement : direction et vitesse de déplacement Deux étapes : Un algorithme de prédiction du prochain état Un algorithme de convergence après réception d un message de mise à jour TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 43/53

44 3 Cas des applications continues Dead reckoning (suite) Prédiction du prochain état : Localement, chaque site estime par calcul la position (et/ou l orientation) des entités distantes impliquées Chaque site gère deux modèles pour une entité locale : Un modèle représentant son mouvement réel Un modèle fantôme représentant le modèle prédictif de la position de l entité sur les sites distants TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 44/53

45 3.4 Pre-reckoning 3 Cas des applications continues Extension du dead reckoning Anticiper : ne pas attendre que le seuil d erreur soit dépassé pour envoyer une mise à jour Probabilité de dépassement du seuil entre le modèle réel et le modèle prédictif Conçu pour les chemins à grande variabilité Comparaison des résultats avec le dead reckoning dans un jeu en 3D (CUBE) [Duncan and Graĉanin, 2003] Moins de mises à jour Virages moins marqués Trajectoire plus précise Taux d erreur plus faible TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 45/53

46 3.5 TimeWarp 3 Cas des applications continues Algorithme optimiste prévu pour les simulations militaires interactives Principe : Un cliché (snapshot) de l état de chaque joueur est pris à chaque réception de message Retour en arrière (rollback) si un événement antérieur aux derniers événements exécutés est reçu Ré-exécution accélérée de tous les événements entre le cliché et l instant courant Optimisations possibles [Mauve et al., 2004] Clichés périodiques Retarder la prise en compte des commandes locales pour contre-balancer la latence réseau = Réduit les besoins mémoire, mais rollbacks plus coûteux TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 46/53

47 3.6 Trailing State Synchronization - TSS 3 Cas des applications continues Algorithme optimiste inspiré de TimeWarp Créé pour les jeux FPS sur des architectures miroir Chaque site miroir gère plusieurs états de remorquage (trailing states) du même jeu décalés dans le temps Plusieurs copies du jeu Exécution de chaque commande mais avec un décalage Testé sur le jeu Quake [Cronin et al., 2002] TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 47/53

48 3 Cas des applications continues Trailing State Synchronization - TSS (suite) Temps de simulation Temps de simulation 0 100ms 200ms 300ms 0 100ms 200ms 300ms Etat S0 d0 = 50 ms Etat S0 d0 = 50 ms Etat S1 d1 = 100 ms Etat S1 d1 = 100 ms RECOPIE amplitude de reprise a) Arrivée d une commande avec l estampille : 175 ms b) Reprise après détection d une incohérence Détection des incohérences : Après la prise en compte d une commande, comparaison avec le fil d exécution précédent (le plus ancien) Incohérence (prise en compte d une commande à des dates différentes) = retour en arrière (rollback) en recopiant l état du jeu vers l état précédent L état antérieur ré-exécute les événements survenus après l incohérence jusqu à l état courant TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 48/53

49 3.7 RendezVous 3 Cas des applications continues Projet de l université de Lancaster (UK) Plateforme pour les applications distribuées temps réel en réseaux non fiables [Chandler, 2004, Chandler and Finney, 2004, Chandler and Finney, 2005] Principe Réplication optimiste Pas de rollback Calcul d un état cible fictif acceptable par tous les joueurs Mise en oeuvre d un arbitre : peut relâcher les règles de jeu pour favoriser la convergence Développement en C++ sur smartphone Tests du mécanisme sur deux jeux mobiles : Pong et Knockabout TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 49/53

50 3.8 Synthèse sur l état de l art 3 Cas des applications continues Méthode F/M Etats fict. Rollback Calcul Mémoire Cohérence 1. Dead reckoning Fixe oui non Pre-reckoning Fixe oui non Timewarp Fixe non oui TSS Fixe non oui RendezVous Mobile oui non TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 50/53

51 4 Pour aller plus loin Journées Francophones sur la Cohérence de Données en Univers Réparti (CDUR) Travaux sur la cohérence des données partagées et dupliquées dans différents domaines 1ères Journées en Novembre 2005 : http :// 2d Workshop en Juin 2008 dans le cadre NOTERE 2008 : http ://igm.univ-mlv.fr/ midonnet/cdur/ Domaines concernés par la problématique de la cohérence : architectures pair à pair, grilles de calcul, architectures multiprocesseurs, architectures de stockage, Web, applications mobiles, réseaux de capteurs, bases de données, applications multimédia (jeux, serveurs de contenu), applications embarquées, systèmes temps réel. TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 51/53

52 Références [Bernstein et al., 1987] Bernstein, P., Hadzilacos, V., and Goodman, N. (1987). Concurrency Control and Recovery in Database Systems. Addison-Wesley. [Bouazza and Molli, 2000] Bouazza, A. and Molli, P. (Philadelphia, Pennsylvania, USA, Décembre 2000). Unifying coupled and uncoupled collaborative work in virtual teams. In ACM CSCW workshop on collaborative editing systems. [Chandler, 2004] Chandler, A. (2004). Rendezvous : An alternative approach to conflict resolution for real time multi-user applications. 13th Euromicro Conference on Parallel, Distributed and Network-based Processing. [Chandler and Finney, 2004] Chandler, A. and Finney, J. (2004). Rendezvous : The case for a highly optimistic real-time consistency mechanism. In IEEE WACERTS 04 Proceedings, Lisbonne, Portugal. [Chandler and Finney, 2005] Chandler, A. and Finney, J. (2005). Rendezvous : Supporting real-time collaborative gaming in high latency environments. In International Conference on Advances in Computer Entertainment Technology ACM SIGCHI ACE 2005, Valencia and Spain. [Chateigner et al., 2004] Chateigner, L., Chabridon, S., Sabri, N., and Bernard, G. (2004). Service de réconciliation pour la synchronisation de copies. In Actes de la 1ère Conférénce ACM Francophone Mobilité et Ubiquité, Nice, France. [Cronin et al., 2002] Cronin, E., Filstrup, B., Kurc, A. R., and Jamin, S. (2002). An efficient synchronization mechanism for mirrored game architectures. In Netgames 02 Proceedings. Braunschweig, Germany, ACM. [Duncan and Graĉanin, 2003] Duncan, T. and Graĉanin, D. (2003). Pre-reckoning algorithm for distributed virtual environments. In Proceedings of the Winter Simulation Conference. [IEEE, 1995] IEEE (1995). Application protocols. In IEEE Standard for Distributed interactive Simulation. IEEE Std TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 52/53

53 [Kermarrec et al., 2001] Kermarrec, A., Rowstron, A., Shapiro, M., and Druschel, P. (26-29 Août 2001). The icecube approach to the reconciliation of divergent replicas. In Proceedings of the 20th ACM Symposium on Principles of Distributed Computing (PODC 2001), Newport, Rhode Island (USA). [Mattern, 1989] Mattern, F. (1989). Virtual Time and Global States of Distributed Systems. In Proceedings of the International Workshop on Parallel and Distributed Algorithms, Amsterdam, NH. [Mauve et al., 2004] Mauve, M., Vogel, J., Hilt, V., and Effelsberg, W. (2004). Local-lag and timewarp : Providing consistency for replicated continuous applications. IEEE Transactions on Multimedia, 6(1). [Pantel and Wolf, 2002] Pantel, L. and Wolf, L. (2002). On the impact of delay on real-time multiplayer games. In Proceedings of the 12th Int. Conf. on Network and Operating Systems for Digital Audio and Video, Miami, Florida, USA. [Petersen et al., 1997] Petersen, K., Spreitzer, M. J., Terry, D. B., Theimer, M. M., and Demers, A. J. (1997). Flexible Update Propagation for Weakly Consistent Replication. In Proc. 16th ACM Symposium on Operating Systems Principles, pages , Saint Malo, France. [Saito and Shapiro, 2005] Saito, Y. and Shapiro, M. (2005). Optimistic replication. ACM Comput. Surv., 37(1) : [Tanenbaum and van Steen, 2002] Tanenbaum, A. and van Steen, M. (2002). Distributed Systems : Principles and Paradigms. Prentice-Hall. [Terry et al., 1995] Terry, D. B., Theimer, M. M., Petersen, K., and Demers, A. J. (1995). Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System. In Proc. 15th ACM Symposium on Operating Systems Principles, pages [Vidot, 2002] Vidot, N. (Septembre 2002). Convergence des Copies dans les Environnements Collaboratifs Répartis. Thèse de doctorat, Université Montpellier-2, Montpellier, France. [Yu and Amin, 2001] Yu, H. and Amin (2001). Combining generality and practicality in a conit-based continuous consistency model for wide-area replication. In Proceedings of the 21st International Conference on Distributed Computing Systems (ICDCS). TELECOM SudParis Sophie Chabridon Janvier 2009 CSC 5004 ASR8 53/53