Cohérence de Données en Environnement Mobile

Cohérence de Données en Environnement Mobile Sophie Chabridon Master Recherche MOPS Module RM Télécom SudParis, CNRS UMR SAMOVAR 10 Octobre 2014

Table des matières Cohérence de Données en Environnement Mobile Sophie Chabridon,, Télécom SudParis, CNRS UMR SAMOVAR, Master Recherche MOPS Module RM 10 Octobre 2014 1 Plan de la présentation 4 1 Introduction 4 1.1 Définition................................................ 4 1.2 Mobilité et réplication......................................... 5 1.3 Verrous à lever............................................. 5 1.4 Solutions envisageables........................................ 6 1.5 Réplication pessimiste......................................... 6 Réplication pessimiste (2)...................................... 7 1.6 Réplication optimiste......................................... 7 Réplication optimiste (2)....................................... 8 1.6.1 Réplication optimiste - Exemples............................... 8 1.7 Modèles de cohérence......................................... 9 1.7.1 Cohérence à terme....................................... 9 1.7.2 Cohérence à terme forte - SEC................................ 10 1.7.3 Cohérence continue....................................... 10 1.8 Deux catégories d applications.................................... 11 2 Cas des applications discrètes 11 2.1 Caractéristiques et critères de classification............................. 12 2.1.1 Modèle de transfert...................................... 12 2.1.2 Unité de transfert....................................... 13 2.1.3 Mode de transfert....................................... 13 2.2 Maintien de la cohérence....................................... 14 2.3 Résolution de conflit.......................................... 14 2.4 Bayou.................................................. 15 Bayou (2)............................................... 15 2.4.1 Bayou - Exemple d architecture................................ 16 2.5 IceCube................................................. 16 IceCube (2).............................................. 17 2.6 Conflict-free Replicated Data Types - CRDTs............................ 17 2.6.1 Exemples de CRDTs...................................... 18 Set................................................... 18 Graph................................................. 19 2.7 Transformées opérationnelles..................................... 19 2.7.1 Exemple d application : Éditeurs collaboratifs........................ 20 2.7.2 Travaux basés sur SOCT4................................... 20 2.7.3 Précédence causale vs concurrence.............................. 21 2.7.4 Trois critères pour le maintien de la cohérence....................... 21 2) Préservation de l intention de l utilisateur :........................... 22 3) Convergence des copies :..................................... 23 2.7.5 Exemple : Transformée avant pour un éditeur de texte.................. 23 2.7.6 SOCT4 en action........................................ 24 2.7.7 Extensions de SOCT4..................................... 24 2.7.8 Extension de SOCT4 pour la mobilité : SOCT4mob.................... 25 2.7.9 Famille des algorithmes OT.................................. 26 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 2

3 Cas des applications continues 26 3.1 Synchronisation pour les jeux multijoueurs............................. 27 3.1.1 Caractéristiques des jeux multijoueurs............................ 27 3.1.2 Impact de la latence - Exemple................................ 28 3.2 Point sur l état de l art........................................ 29 3.3 Dead reckoning............................................. 29 3.3.1 Dead reckoning (suite)..................................... 30 3.4 Pre-reckoning.............................................. 30 3.5 TimeWarp............................................... 31 3.6 Trailing State Synchronization - TSS................................. 31 3.6.1 Trailing State Synchronization - TSS (suite)......................... 32 3.7 RendezVous............................................... 32 3.8 Synthèse sur l état de l art....................................... 33 4 Références 34 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 3

Plan de la présentation 1 Introduction # 2 1 Introduction.................................................................... 4 2 Cas des applications discrètes................................................... 18 3 Cas des applications continues.................................................. 48 4 Références..................................................................... 64 1 Introduction # 3 1.1 Définition..................................................................... 4 1.3 Mobilité et réplication......................................................... 6 1.3 Verrous à lever................................................................ 6 1.5 Solutions envisageables........................................................ 8 1.5 Réplication pessimiste......................................................... 8 1.6 Réplication optimiste......................................................... 10 1.7 Modèles de cohérence........................................................ 14 2.0 Deux catégories d applications................................................ 18 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 4

1.1 Définition 1 Introduction # 4 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. Domaines concernés par la problématique de la cohérence : architectures pair à pair, grilles de calcul, architectures multiprocesseurs, architectures de stockage, bases de données, Web, applications mobiles, réseaux de capteurs, applications multimédia (jeux, serveurs de contenu), applications embarquées, systèmes temps réel. 1.2 Mobilité et réplication # 5 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... Menaces pour la cohérence des données Applications multi-écrivains Théorème CAP (Consistency, Availability and Partition Tolerance) [Brewer, 2000] : Impossibilité d avoir les trois propriétés C, A et P simultanément. Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 5

1.3 Verrous à lever 1 Introduction Non-commutativité des opérations Concevoir pour la commutativité [Shapiro and Preguiça, 2007] # 6 Solutions spécifiques aux types d applications Opérations entièrement déterminées à l avance Éditeur de texte Système de gestion de fichiers Base de données Réconciliation plus ou moins automatisée Réplication pessimiste 1.4 Solutions envisageables Prise d un verrou avant de modifier une donnée Pas de mise à jour concurrente Evite les conflits a priori Réplication optimiste # 7 Mises à jour concurrentes autorisées Apparition possible de conflits Nécessité d une phase de réconciliation a posteriori Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 6

1.5 Réplication pessimiste 1 Introduction Encore appelée réplication synchrone Propagation impatiente (eager) des mises à jour # 8 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 Réplication pessimiste (2) Avantages Simple à mettre en oeuvre Cohérence des copies garantie en empêchant l apparition de divergences # 9 Inconvénients Ne passe pas à l échelle avec un grand nombre d écritures Vulnérable Etreinte fatale (deadlock) Déconnexions Latence Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 7

1 Introduction 1.6 Réplication optimiste 1.6 Réplication optimiste Encore appelée réplication asynchrone # 10 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 Réplication optimiste (2) Avantages Permet de modifier une copie locale Seule approche possible en environnement mobile pour la continuité de service # 11 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 8

1 Introduction 1.7 Modèles de cohérence 1.6.1 Réplication optimiste - Exemples # 12 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 1.7 Modèles de cohérence # 13 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...) Pour plus de détails, 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 9

1 Introduction 1.7 Modèles de cohérence 1.7.1 Cohérence à terme Eventual consistency # 14 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 En cas de conflit, arbitrage et éventuellement retour en arrière Modèle de cohérence le plus faible Aucun ordre sur les opérations n est imposé 1.7.2 Cohérence à terme forte - SEC [Shapiro et al., 2011] # 15 Cohérence à terme + aucun conflit Mises à jour concurrentes déterministes Pas besoin de consensus tant que n 1 fautes Résoud l impossibilité CAP Disponibilité, rapidité Ne plus choisir entre passage à l échelle et cohérence Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 10

1.7.3 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 # 16 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é 1.8 Deux catégories d applications Applications discrètes Etat change uniquement en fonction d opérations de lecture/écriture # 17 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 11

2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification 2 Cas des applications discrètes # 18 2.1 Caractéristiques et critères de classification.................................... 20 2.3 Maintien de la cohérence..................................................... 24 2.3 Résolution de conflit..........................................................24 2.4 Bayou....................................................................... 26 2.5 IceCube..................................................................... 28 2.6 Conflict-free Replicated Data Types - CRDTs.................................. 30 2.7 Transformées opérationnelles..................................................34 2.1 Caractéristiques et critères de classification Caractéristiques : Opérations de lecture/écriture Faites à des instants précis # 19 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 12

2 Cas des applications discrètes 2.1 Caractéristiques et critères de classification 2.1.1 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 # 20 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 2.1.2 Unité de transfert Etat Transmission du nouvel état Simple à mettre en oeuvre # 21 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 13

2.1.3 Mode de transfert 2 Cas des applications discrètes A la demande (pull) Une copie doit interroger le maître/une autre copie afin de récupérer la nouvelle valeur # 22 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 2.2 Maintien de la cohérence Distribution des Majs entre les copies Détection et résolution des conflits entre les Majs conflit : violation de la cohérence # 23 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 14

2 Cas des applications discrètes 2.4 Bayou 2.3 Résolution de conflit 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 # 24 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 2.4 Bayou Projet de Xerox PARC (1993-1997) [Terry et al., 1995, Petersen et al., 1997] Système de gestion de bases de données collaboratives mobiles Transfert d opérations # 25 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é Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 15

Bayou (2) 2 Cas des applications discrètes 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) # 26 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 2.4.1 Bayou - Exemple d architecture # 27 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 16

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 # 28 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 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 # 29 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 17

2 Cas des applications discrètes 2.6 Conflict-free Replicated Data Types - CRDTs 2.6 Conflict-free Replicated Data Types - CRDTs [Shapiro et al., 2011] # 30 Deux conditions suffisantes Évolution monotone : mises à jour non destructives Commutativité (par conception) Réduire la taille des objets manipulés Limité à certains types d applications 2.6.1 Exemples de CRDTs Set # 31 Graph (DAG) Counter Sequence Register Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 18

Set 2 Cas des applications discrètes # 32 Conserver les valeurs intermédiaires Opération "delete" > ajout d un marqueur (tombstone) À terme, convergence vers le même ensemble de valeurs Graph # 33 Choisir une implémentation déterministe. Ex : "addedge" prioritaire Par défaut, cohérence à terme Consensus nécessaire pour une cohérence à terme forte Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 19

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2.7 Transformées opérationnelles 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 # 34 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 2.7.1 Exemple d application : Éditeurs collaboratifs # 35 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 20

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2.7.2 Travaux basés sur SOCT4 SOCT4 : Sérialisation des opérations concurrentes par transposition [Vidot, 2002] # 36 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 2.7.3 Précédence causale vs concurrence # 37 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 21

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2.7.4 Trois critères pour le maintien de la cohérence # 38 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] # 39 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 22

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2) Préservation de l intention de l utilisateur : Gestion des opérations concurrentes (-> transposition avant) # 40 3) Convergence des copies : La fonction de transposition AVANT doit vérifier : C1 : op1.op2 op1 op2.op1 op2 # 41 Résolution des conflits 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 23

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2.7.5 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 # 42 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 } 2.7.6 SOCT4 en action # 43 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 24

2 Cas des applications discrètes 2.7 Transformées opérationnelles 2.7.7 Extensions de SOCT4 SOCT4 suppose une connexion permanente entre les sites Une opération est diffusée immédiatement aux sites distants # 44 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 # 45 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 25

2.7.8 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 # 46 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 2.7.9 Famille des algorithmes OT Avec condition C1 uniquement SOCT4 [Vidot, 2002] COT (Context-based OT) [Sun and Sun, 2006] : opération UNDO Avec 2 conditions C1 et C2 # 47 C2 : T(op3,op1.T(op2,op1)) = T(op3,op2.T(op1,op2)) Pas d ordre de réception des opérations ADOPTED [Ressel et al., 1996], GOTO [Sun and Sun, 1998], SOCT2 [Suleiman et al., 1998] Très difficile d écrire des transformées vérifiant C2 Preuve que les transformées proposées ne garantissent pas toujours C2 [Imine et al., 2003] Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 26

3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs 3 Cas des applications continues # 48 3.1 Synchronisation pour les jeux multijoueurs..................................... 51 3.3 Point sur l état de l art....................................................... 54 3.3 Dead reckoning.............................................................. 54 3.4 Pre-reckoning................................................................ 56 3.6 TimeWarp................................................................... 58 3.6 Trailing State Synchronization - TSS.......................................... 58 3.7 RendezVous..................................................................60 3.8 Synthèse sur l état de l art.................................................... 61 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 # 49 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)? Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 27

3 Cas des applications continues 3.1 Synchronisation pour les jeux multijoueurs 3.1.1 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 # 50 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 # 51 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 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 28

3.1.2 Impact de la latence - Exemple 3 Cas des applications continues Cas d une course de voitures [Pantel and Wolf, 2002] Qui a gagné? # 52 3.2 Point sur l état de l art Solutions en environnement fixe # 53 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 29

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 : # 54 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 3.3.1 Dead reckoning (suite) Prédiction du prochain état : # 55 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 30

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 # 56 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 3.5 TimeWarp 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 # 57 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 31

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 # 58 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] 3.6.1 Trailing State Synchronization - TSS (suite) Temps de simulation Temps de simulation Etat S0 d0 = 50 ms 0 100ms 200ms 300ms Etat S0 d0 = 50 ms 0 100ms 200ms 300ms # 59 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 Télécom SudParis, CNRS UMR SAMOVAR Sophie Chabridon 10 Octobre 2014 MOPS/RM 32