Jeux Libres
       
           

» Les Tutoriels » La simultanéité à distance

La simultanéité à distance


Cet article, purement théorique, n'a pas la prétention d'entrer au cur de grandes théories mais simplement de mettre en évidence certains phénomènes inévitables auquel vous serez confronté si vous devez créer une application réseau à forte contrainte temps-réel.





Latence


Lorsque deux personnes distantes communiquent, il se produit inévitablement un délai entre le moment ou l'émetteur s'exprime et le moment ou le récepteur reçoit le message. Ce délai, appelé "latence", peut varier en fonction de nombreux paramètres : le support de la communication, la distance qui sépare les deux interlocuteurs, etc...

Lorsque ce temps de transfert est trop infime pour être perceptible, on peut considérer qu'il y a une simultanéité entre l'envoi et la réception de l'information. Mais c'est rarement le cas.

Perception de la latence



Sur un réseau informatique comme Internet, par exemple, la latence est assez variable, pouvant aller que quelques millisecondes à plusieurs centaines de millisecondes. C'est le cas d'Internet que nous allons étudier de plus près.

Mesure de la latence au travers d'Internet



La méthode classique pour mettre en évidence et mesurer la latence sur Internet est d'effectuer un ping. Cette technique reprend le principe de l'écho. Elle consiste à envoyer message à une machine distante en lui demandant de nous envoyer immédiatement un accusé de réception. On estime la latence en divisant par deux le temps de l'aller-retour du ping.

Fiabilité de la mesure



La mesure du temps de transfert par le ping n'est pas parfaite. En effet, elle suppose que le machine distante répond immédiatement et que les temps de transfert de l'aller et du retour sont identique. Or, il n'y a rien qui le vérifie. Il ne s'agit donc que d'une mesure approximative.

Un autre paramètre à prendre en compte : la résolution du DNS. Il s'agit, grossièrement, du temps de recherche de la machine. Le premier ping est généralement plus lent que les suivants. Si vous devez mettre en place un mécanisme de mesure du ping dans une de vos applications, vous devrez en tenir compte.

Et enfin, le problème le plus difficile à gérer : la gigue. Il s'agit de la fluctuation du ping au cours du temps. Il est possible que vous ayez actuellement un ping de 100 ms avec une machine et que dans quelques secondes, ce ping chute à 50 ms ou augmente à 200 ms.


Les conséquences


Ce délai vient parasiter le fonctionnement idéal des applications, notamment celle à forte contrainte temps-réel.

La téléphonie



Lorsque vous communiquez avec quelqu'un, que ce soit par messagerie instantanée ou pas téléphone, ces délais de latence influent beaucoup sur la qualité de la conversation. En effet, il n'est pas rare, lorsque la latence est trop élevée, que les deux interlocuteurs commencent à parler sur un même instant de silence et de se faire couper la parole, chacun de leur côté, par la réception de la parole de l'autre, une seconde plus tard.

Petite expérience



Demandez à votre interlocuteur téléphonique de faire claquer périodiquement sa langue en même temps que vous. Toutes les deux secondes par exemple. Soyez très périodique, laissez-le se synchroniser sur vos claquements et écoutez. Vous remarquerez que, malgré sa bonne volonté, son claquement que vous entendez ne se produit pas en même temps que le votre. Vous venez de réaliser un ping !

Les jeux vidéo



Les jeux vidéo à forte contrainte temps réel, tel que les FPS, sont très touché par ce problème de latence et nuit considérablement à la jouabilité. En effet, si les informations de déplacement des adversaires mettent trop de temps à vous parvenir, vous jouez face à une scène devenue obsolète. L'adversaire sur lequel vous tirez actuellement n'est peut-être déjà plus là. De plus, lorsque le serveur recevra votre tir et vérifiera s'il a bien été touché, il est possible que votre adversaire soit déjà loin.

Heureusement, pour remédier à ce problème, des mécanismes sont mis en place. Lorsque vous tirez, le serveur "regarde" dans son passé pour voir si l'adversaire a été touché. Ce mécanisme induit un effet indésirable : l'adversaire a le sentiment de mourir alors qu'il a eu le temps de se cacher.

Le manque de simultanéité induit inévitablement le fait que la vision de notre présent représente le passé de ce qui s'est produit réellement. En d'autre terme, chaque joueur découvre en son présent les actions passées des autres joueurs : "Je meurs maintenant car j'ai été tué avant".


Synchronisation et dérive


Il est parfois nécessaire que deux applications soit synchronisées. Ceci est nécessaire par exemple, dans un jeu vidéo en réseau où la partie doit démarrer en même temps chez chaque joueur.

Démarrage simultané



La "solution" simple pour lancer la partie simultanément chez chacun des joueurs est de leur envoyer un message "en même temps". Seulement, ils n'ont pas tous le même temps de latence. Certain recevront le message trop tard et commenceront la partie après les autres, ce qui peut être gênant.

Démarrage simultané avec une horloge commune



La solution idéal est d'avoir, sur chaque machine, une horloge synchronisée sur une horloge commune. Ainsi, il est très simple d'informer chaque joueur de l'heure de lancement de la partie. Ensuite, ils attendent sagement qu'il soit l'heure pour démarrer la partie. La simultanéité du démarrage est directement liée à la synchronisation des horloges.

Synchronisation des horloges



Généralement, c'est l'horloge du client qui se synchronise sur l'horloge du serveur. Pour se synchroniser, le client demande au serveur de lui envoyer l'heure immédiatement. Lorsque le client reçoit l'heure du serveur, un certain temps s'est écoulé entre temps. L'heure que vient de recevoir le client représente en réalité l'heure qu'il était lorsque le serveur a envoyé le message.

Pour en déduire l'heure actuelle, le client doit ajouter, à l'heure reçu, le temps de latence qu'a mis le message pour lui parvenir.

Prenons un exemple :
- A 21h et 10 secondes (heure local) le client envoi une demande au serveur.
- A 21h et 18 secondes (heure local) le client reçoit la réponse du serveur.
- Le client en déduit que le ping est de 8 secondes. Il estime donc la latence à 4 secondes.
- Le message du serveur contient l'heure "réelle". Il indique qu'il était 21h et 42 secondes (heure de l'envoi de la réponse). Ce qui signifie qu'à 21h et 14 secondes (heure local) il était en réalité 21h et 42 secondes. On en déduit un retard de 28 secondes. Pour synchroniser notre horloge, on ajoute alors 28 secondes à notre horloge locale pour avoir une horloge synchronisée sur celle du serveur.

Une horloge de précision



Pour obtenir une horloge local synchronisée précisément, il est possible d'effectuer plusieurs fois l'opération et de privilégier les plus petits ping. Il est possible également de synchroniser plusieurs horloges locales et de faire la moyenne de celles-ci pour obtenir une "horloge globale" plus précise.

La dérive de l'horloge



Le dernier paramètre à prendre en compte dans la précision de votre horloge, c'est la dérive. Au cours du temps, votre horloge risque de se désynchroniser de celle du serveur. Ce phénomène est principalement dû à l?imprécision du quartz (électronique) de votre machine et du serveur.

Pour les geeks : Imaginons que le quartz du client et du serveur dérive de 50 ppm (parties par million) chacun dans un sens différent. Ce qui fait 100 ppm au total. Après 30 minutes de jeu, on obtient une dérive de 180 millisecondes :
[math]30 \times 60 \times 1000 \times \frac{100}{10^6} = 180[/math]
Si cette horloge erronée est utilisée pour déterminer la distance parcourue par un personnage qui se déplace à 3 mètres par secondes, on obtient une erreur de plus de 50 cm :
[math]d = v \times t = \frac{3}{1000} \times 180 = 0.54[/math]


Pour une application qui nécessite une grande précision à long terme, il est préférable de resynchroniser l'horloge de temps en temps.




Nous avons passé en revue les principales caractéristiques du réseaux Internet ainsi que les enjeux de la synchronisation de machine distante, parfois nécessaire à la simultanéité d'action distante.

J'espère que vous saurez faire bon usage de ce que vous avez appris dans ce petit article.



Rédigé par David
Consulté 6146 fois



Hébergeur du site : David
Version PHP : 5.4.45-0+deb7u2
Uptime : 16 jours 7 heures 1 minutes
Espace libre : 1599 Mo
Dernière sauvegarde : 09/12/2018
Taille de la sauvegarde : 1109 Mo


4958048 pages ont été consultées sur le site !
Dont 2317 pages pendant les 24 dernières heures.

Page générée en 0.482 secondes


Nos sites préférés
- Création d'un jeu de plateforme de A à Z avec SDL
- Zelda ROTH : Jeux amateurs sur le thème de Zelda
- Zeste de Savoir : la connaissance pour tous et sans pépins
- YunoHost : s'héberger soi-même en toute simplicité
- Site de Fvirtman : recueil de projets et de codes en C et C++
- Par ici la sortie : le site des idées de sorties


  © 2005-2018 linor.fr - Toute reproduction totale ou partielle du contenu de ce site est strictement interdite.