Discussion :

[Oneil67]

Bonjour,

après de nombreuses recherches infructueuses (certainement parce que je n'ai pas trouvé le terme technique de ce problème) je viens solliciter votre aide :-)

De façon théorique, je voulais savoir comment synchroniser des objets sur des ordinateurs distants (tous connectés à Internet (donc possibilité d'intégrer dans le réseau un serveur central qui centralise les objets)) et ce de façon "temps-réel" (juste un décalage du au ping en somme) tout en ayant des contraintes d'intégrités sur ces objets (exemple : 2 clients tentent de réaliser une modification au même moment, la modif du client 1 est réalisé, par contre la modif du client 2 est irréalisable à cause de la modif du client 1 qui s'est exécutée 1ms avant : il faut donc dire au client 2 que son action est irréalisable).

J'avais pensé au début à ce que chaque modification d'un objet partagé passe par une demande de modification sur le serveur et que celui-ci la valide ou l'invalide et que le client soit en mis en attente pour savoir si il peut continuer ou non son action. Mais cela pose un problème de mise en attente du programme à chaque modification de l'objet... avec un ping de 200ms, 5 modifications successives prendraient rien qu'en temps de transite 1 seconde...

J'ai donc ensuite pensé à une façon asynchrone de faire : les modifications sont réalisés en local chez le client et envoyés de façon asynchrone au serveur pour le mettre à jour et propagé aux autres clients la modification. Si la modification est invalidé par le serveur un ordre de rollback est envoyé au client. Tout le problème dans cette solution réside dans la mise en place de ce système de rollback...

Existe-t-il d'autres façon de faire ceci ? Avez-vous des idées ou bien des pistes à me donner ?

Merci d'avance :-)

[professeur shadoko]

ah Jini (Apache River) nous manque

[Oneil67]

Effectivement, Jini (Apache River) est une solution complète. Mais qui serait trop imposante pour mes besoins, je n'ai pas besoin de faire fonctionner toute mon application autour de ces objets synchronisés, juste certaines parties.

Mon problème peut-être comparable avec ceux des jeux en réseau type FPS, voici un scénario représentant ma problématique :

1. 3 joueurs sont présents;
2. 2 joueurs font chacun 1 tir sur le même joueur en même temps;
3. le tir de chacun des joueurs a suffisamment de puissance pour tuer le joueur ciblé;
4. chaque joueur réalise de son côté les tests de collision, chacun détecte que son tir a touché le joueur ciblé et l'a tué;
5. chacun envoi au serveur la commande indiquant que le joueur et mort par son tir;
6. de façon a avoir un jeu fluide cet envoi est asynchrone et continue donc leur logique d'exécution;
7. chacun gagne 100 points bonus qui les font chacun passer au niveau suivant et débloquer une nouvelle arme;
8. les packets TCP indiquant la mort du joueur atteignent enfin le serveur;
9. les packets TCP du joueur 1 ayant étaient plus rapides, c'est lui et lui seul qui a réellement tué le joueur;
10. le serveur valide la mort de joueur et envoi à ce joueur l'information qu'il vient de mourir
11. les packets TCP du joueur 2 arrivent, mais le serveur les invalides car le joueur est déjà mort, tué par le joueur 1 il y a 3 millisecondes...

Problématique : comment faire faire au joueur 2 un rollback sur ces actions locales non-synchronisés (ici le déblocage de la nouvelle arme) parce que le "kill" ne lui a pas été attribué ?

Si quelqu'un à une solution, une piste, une idée, un pré-sentiment, une intuition, qu'il n'hésite pas à s'exprimer

[hwoarang]

Si quelqu'un à une solution, une piste, une idée, un pré-sentiment, une intuition, qu'il n'hésite pas à s'exprimer

Mon intuition, c'est qu'un systeme de rollback est trop compliqué à mettre en oeuvre (en plus, ca parait bizarre d'afficher à un joueur "vous avez débloqué un niveau" puis, une seconde plus tard, "finalement, vous n'avez pas débloqué le niveau") et que la seule solution fiable pour s'assurer qu'il n'y a pas de probleme est d'envoyer la donnée au serveur et d'attendre sa réponse pour valider ou pas la mort du joueur...

Quand aux problématiques sur le temps de réaction, elles supposent que 5 modifications de la meme donnée en meme temps (peu probable si peu d'utilisateurs). Et un temps de réaction d'une seconde n'a rien de choquant pour une appli web...

[olivier.pitton]

Pourquoi un rollback ? A mes yeux c'est le serveur qui décide de la mort du joueur. Lorsqu'il reçoit des tirs qui touchent, le serveur vérifie que le joueur touché est mort. Le dernier joueur à avoir tiré alors qu'il avait encore de la vie est le tueur, donc il a les points. Un message est envoyé au joueur 2 pour lui dire qu'il est mort et il s'arrête. Si ce-dernier effectue une action entre le moment où le tueur a tiré et celui où il est mort, c'est seulement du à la latence, comme dans n'importe quel jeu vidéo.