Pair à pair
La mise en réseau peer-to-peer (pair-à-pair) connecte les joueurs directement entre eux sans serveur dédié intermédiaire, la machine de l'un des joueurs faisant généralement office d'hôte. Cela élimine totalement les coûts d'hébergement. En contrepartie, l'hôte bénéficie d'un avantage en termes de latence, détient l'autorité sur l'état du jeu et met fin à la partie lorsqu'il la quitte.
Aussi appelé
p2p, réseau P2P
,
Que signifie le Peer-to-Peer dans un jeu multijoueur ?
Dans la plupart des jeux qui le proposent, le peer-to-peer signifie hôte-client. Le jeu d'un joueur contient l'état de la partie et fait office de serveur pendant que ce joueur joue, et tous les autres se connectent à lui. Les moteurs appellent souvent cela un serveur d'écoute (listen server) ou un mode hôte. Un service de salon ou de matchmaking aide les joueurs à trouver un hôte, mais une fois le match commencé, le trafic circule entre les machines des joueurs.
Une famille plus restreinte de jeux n'a pas d'hôte du tout : le peer-to-peer déterministe, parfois appelé véritable peer-to-peer. Chaque pair exécute la simulation complète et n'échange que les commandes (inputs), soit en mode lockstep (où tout le monde attend les commandes de chacun avant de progresser), soit avec rollback (où chaque machine prédit et simule à nouveau lorsqu'une commande tardive s'avère différente). C'est une conception spécialisée, que l'on trouve principalement dans les jeux de stratégie et de combat, et c'est rarement ce qu'une équipe veut dire lorsqu'elle parle de P2P.
Quoi qu'il en soit, le serveur n'a pas disparu. Ses fonctions ont été transférées sur les machines des joueurs : connecter les joueurs entre eux, décider de ce qui s'est passé, acheminer le trafic et maintenir la partie active. Les sections ci-dessous abordent ces tâches une par une.
Comment les joueurs se connectent-ils sans serveur ?
La première tâche consiste à faire communiquer deux connexions domestiques. La plupart des joueurs se trouvent derrière un routeur qui effectue une traduction d'adresse réseau (NAT), ce qui bloque le trafic que personne à l'intérieur n'a demandé. Un pair demande son adresse publique à un serveur STUN, puis les deux pairs envoient des paquets au même moment pour ouvrir un chemin à travers leurs routeurs. Cette technique est appelée le percement de tunnels (hole punching).
Elle échoue suffisamment souvent pour influencer la conception du produit. Les paramètres stricts des routeurs et le NAT de classe opérateur (Carrier-Grade NAT), courants sur les réseaux mobiles et chez certains fournisseurs d'accès à domicile, font échouer le percement de tunnels, et certains fournisseurs bloquent carrément le trafic STUN pour des raisons de sécurité. Les éditeurs de plateformes publient des guides de dépannage précisément pour cela : Xbox propose une page sur les erreurs NAT et les correctifs pour le multijoueur qui guide les joueurs à travers les paramètres de leur routeur. Le joueur qui ne peut pas rejoindre un ami ne s'en prend pas à son routeur. Il accuse le jeu.
La solution de repli est souvent un relais, un serveur qui transfère les paquets entre des pairs qui ne peuvent pas s'atteindre. Les relais masquent également les adresses IP des joueurs. Mais une fois que le trafic passe par un relais, un serveur se retrouve de nouveau au milieu, avec ses propres coûts, sa région et sa latence. Un serveur dédié léger se situe au même endroit dans le réseau et peut également conserver l'état de la partie, et en concevoir un est souvent plus simple que de mettre en place un percement de tunnels avec une solution de repli par relais.
Le jeu en pair-à-pair est-il sûr ?
Quiconque détient l'état du match peut le modifier. En mode hôte-client, l'hôte peut modifier les valeurs en mémoire, utiliser un commutateur de décalage (lag-switch) en coupant temporairement sa connexion pour que tout le monde se fige pendant qu'il agit, ou signaler un résultat qui n'a jamais eu lieu. Dans les jeux en mode lockstep et rollback, chaque client est digne de confiance pour ses propres entrées. Les pairs apprennent également les adresses IP des uns et des autres, à moins qu'un relais ne les masque, ce qui expose les joueurs à des attaques par déni de service. Notre analyse des coûts cachés du P2P détaille ces techniques.
Les relais réduisent l'exposition sans pour autant la supprimer. Michal Buras de Highwire Games, en évaluant les options pour Six Days in Fallujah, a montré que les données de salon sur un service de relais gratuit pouvaient être lues en texte clair avec un outil de débogage standard, exposant ainsi les informations privées des autres joueurs (conférence au Live Service Game Summit, septembre 2024).
L'autorité du serveur est ce qui permet de régler ce problème. Bloody Bastards, un jeu mobile avec plus de 40 millions de téléchargements, fonctionnait en peer-to-peer, l'hôte étant digne de confiance pour les résultats des matchs. Son studio décrit les tricheries comme rampantes, parallèlement à une désynchronisation de la physique et à un ping inégal. Après être passé à de petits serveurs faisant autorité et sans interface graphique, Tibith rapporte qu'aucun hacker n'a réussi à tricher depuis la version 5.0.0 (étude de cas, Tibith Ltd, 2026).
Combien de joueurs le peer-to-peer peut-il accueillir ?
Dans un maillage complet (full mesh), chaque pair se connecte à tous les autres. Quatre joueurs ont besoin de 6 connexions, huit de 28, et seize de 120. Chaque joueur envoie ses mises à jour à tous les autres joueurs, via une connexion domestique où le débit montant est généralement le maillon faible.
Le modèle hôte-client évite le maillage en acheminant tout par l'hôte. Cela déplace l'ensemble de la charge sur un seul joueur : son débit montant soutient la partie, et son matériel exécute la simulation tout en affichant son propre jeu. La partie n'est que de la qualité du pire hôte attribué à quiconque.
Puis l'hôte s'en va. Sans migration d'hôte, la partie se termine pour tout le monde. Avec elle, un autre pair doit reprendre l'état de la partie en plein milieu du jeu, et chaque fonctionnalité du jeu doit survivre au transfert. Dans la même conférence, Highwire Games a estimé que retravailler Six Days in Fallujah pour intégrer la migration d'hôte nécessiterait un développeur et un testeur supplémentaires, pour environ 15 000 $ par mois.
C'est la partie du peer-to-peer qui entre rarement dans le calcul du "c'est gratuit". Il n'y a pas de facture d'hébergement. Il y a du temps de personnel, des tickets d'assistance pour les connexions échouées, et des joueurs perdus à cause de parties terminées prématurément.
Un mot de notre sponsor (nous-mêmes !)
Un match n'est pas équitable lorsqu'un joueur habite juste à côté du centre de données. L'Edge Cloud d'Edgegap s'appuie sur plus de 615 emplacements distribués à la demande, positionnant chaque serveur en fonction du lieu de connexion de chaque joueur du match, plutôt que dans une région fixe. Dans l'étude 1v1 d'Edgegap, cela a permis de réduire de 28 % l'écart d'équité entre les adversaires.
Quand le pair-à-pair est-il le bon choix ?
Le peer-to-peer reste une option raisonnable pour les petites sessions entre joueurs qui se font confiance : la coopération entre amis, les prototypes et les jeux où un tricheur gâche une partie plutôt qu'un classement ou une économie. Les jeux de combat avec rollback l'utilisent depuis des années.
Pour un jeu commercial, la question est de savoir ce que cela coûte en termes d'éléments qui ne figurent jamais sur une facture : les connexions qui échouent, les parties perdues lorsqu'un hôte quitte, et l'exposition à la triche qui augmente avec la base de joueurs. Même l'argument de la latence est moins solide qu'il n'y paraît. Dans une analyse réalisée en 2020 sur 122 000 matchs en peer-to-peer d'un jeu console en 1v1, le routage de chaque match via un serveur placé au meilleur endroit entre les deux joueurs a réduit le temps de trajet aller-retour moyen de 23 % dans 70 % des matchs (rapport 1v1). Le chemin direct n'est pas toujours le plus court.
Ce choix est également moins définitif qu'auparavant. Les frameworks réseau tels que Photon Fusion peuvent faire tourner le même jeu avec un joueur comme hôte, via un relais cloud, ou sur des serveurs dédiés, de sorte qu'une équipe qui commence en peer-to-peer peut passer à des serveurs sans avoir à recommencer son netcode à zéro. La propre documentation de Photon cite Edgegap parmi les hébergeurs pour les serveurs dédiés Fusion.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Hébergement gratuit, payant d'autres manières
Le pair-à-pair est la seule architecture dont le coût est payé par vos joueurs. Aucune facture n'arrive. Au lieu de cela, cela se traduit par des joueurs qui n'ont pas pu rejoindre un ami, des parties qui se sont terminées lorsque la connexion d'un hôte a été coupée, et un classement auquel personne ne fait confiance.
Cela peut être le bon compromis. Pour de la coop entre amis, c'est souvent le cas. Pour un jeu commercial qui classe les joueurs, vend des objets ou associe des inconnus, ce ne l'est généralement pas, et l'ajout d'un relais ne résout que la première des quatre tâches accomplies par un serveur.
Avant de choisir, nommez qui effectue chaque tâche dans votre conception : qui connecte les joueurs, qui décide de ce qui s'est passé, quelle bande passante transporte la partie, et que se passe-t-il quand quelqu'un s'en va. Chaque réponse qui indique "un joueur" est un coût que vous avez déplacé, et non un coût que vous avez supprimé.
,
