Clive Johnson sur le Server Meshing

Traduction: odysseus1992
Relecture: insosama
Intégration: odysseus1992

Le 8 et 13 août 2020, le programmeur réseau en chef chez CIG Clive Johnson a livré, en réponse à des questions sur la plateforme Spectrum, quelques détails supplémentaires sur le Server Meshing.

Question par Dreamy

Comment le “Server Meshing”, etc. peut être construit sur un code serveur aussi mauvais ?

Bonjour,

Je pense que nous savons tous assez bien à quel point le code du serveur est actuellement mauvais. Seuls deux mots-clés sont nécessaires pour résumer la situation : désynchronisation et 30k.
Le “Server Meshing” et iCache (nécessaire pour une persistance complète) ont été annoncés par Chris Roberts lors de sa keynote de la CitizenCon 2018 comme des étapes clés de la “Road to Release”.

Mais comment pouvez-vous techniquement mettre en œuvre ces technologies en vous appuyant sur un si mauvais code serveur ?

Est-ce la raison pour laquelle nous n’avons pas reçu de nouvelles sur les progrès de ces technologies phares ?
Ou est-ce que le “Server Meshing” va réellement améliorer la situation en diminuant la charge des différents serveurs surchargés ?

Qu’est ce qui peut être fait et qu’est-ce qui est actuellement fait ou prévu pour améliorer les problèmes liés au code du serveur ?

Je vous remercie.

Réponse par Clive Johnson

Construire le “Server Meshing” sur des serveurs instables ou sur lesquels les joueurs subissent de la désynchronisation n’est effectivement pas idéal, mais c’est pourtant la seule façon réaliste de le faire.

J’ai déjà publié une réponse sur les causes des pannes serveur (le plus souvent la cause de la tristement célèbre erreur de déconnexion 30000) et sur ce que nous faisons pour y remédier. J’espère que cela ne vous dérange pas si je copie paresseusement le lien en le collant ici :

Les déconnexions serveur et la philosophie de développement de Star Citizen par Clive Johnson

Une instabilité grave pourrait être encore plus préjudiciable avec le “Server Meshing” qu’elle ne l’est actuellement pour des instances séparées, simplement parce qu’un crash serveur pourrait affecter plus de clients que ceux qui sont connectés à un seul serveur. Nous prévoyons de traiter ce problème de plusieurs manières. Premièrement, le “Server Meshing” tentera de minimiser les connexions entre les serveurs, en divisant l’univers en “îlots” de simulation, de sorte que lorsqu’un serveur d’un “îlot” tombe en panne, il ne puisse pas affecter les serveurs et les clients des autres “îlots”. Ensuite, nous ajouterons un système de récupération en cas de crash serveur, de sorte que lorsqu’un serveur tombe en panne, un nouveau se met en route et restaure l’état du serveur en panne à partir de la persistance (les clients du serveur en panne seront probablement toujours redirigés vers le menu, mais auront la possibilité de rejoindre le nouveau serveur). Ces deux éléments sont les raisons principales pour lesquelles la persistance complète et le S-OCS sont nécessaires avant que le “Server Meshing” puisse fonctionner. Bien sûr, nous continuerons également à réparer les crashs serveur aussi rapidement que possible une fois qu’ils auront été découverts.

Le terme “désynchronisation” est souvent utilisé pour décrire un large éventail de problèmes, y compris les saccades, la téléportation, le “rubber banding[1]”, la latence élevée ainsi que la vraie désynchronisation, où les objets sont dans des états complètement différents sur différents clients et ne se rétablissent pas. Les différents symptômes ont leurs propres causes et sans les informations correctes, il est souvent difficile de reproduire ces bugs en interne. Lorsque vous signalez des problèmes de désynchronisation à l’Issue Council, veuillez être aussi précis que possible sur ce que vous avez réellement vu et fournir des vidéos là où vous le pouvez (de préférence avec le QR code r_displaySessionInfo = 1 activé). Ce que nous savons, cependant, ce sont les causes principales de ces différents types de désynchronisation. Les “vraies désynchronisations” sont généralement causées par une erreur de logique dans un morceau de code et la seule façon de les corriger est de reproduire le bug et de trouver où l’erreur de logique se produit. Les saccades, la téléportation et le “rubber banding” sont le plus souvent causés par une faible fréquence de trames (frame rate en anglais) ou par des pics de trame (frame spikes en anglais) soudains (une trame qui prend beaucoup plus de temps à traiter que celles immédiatement avant ou après) sur un client ou le serveur. La meilleure façon de remédier à ces problèmes est d’optimiser le code pour améliorer la fréquence moyenne de trames ou éliminer les pics. Mon équipe (réseau) a également pour tâche de corriger les pics qui se produisent dans notre code (mais il y a aussi des pics dans d’autres systèmes que chaque équipe en charge devra traiter). Une latence élevée peut être causée par de faibles fréquences de trames du serveur et une bande passante élevée entre les clients et le serveur. De plus, certains pics de trame peuvent provoquer une bande passante élevée (et donc une latence), ou peuvent être causés par eux. Nous avons des travaux pour optimiser la bande passante et étudier d’autres techniques pour réduire ou masquer la latence. Certains sont dans d’autres équipes et seront déployés progressivement en fonction de leur calendrier. Ceux de mon équipe sont actuellement prévus après que nous ayons fait fonctionner le “Server Meshing” mais, comme pour tout ce qui concerne le développement du jeu, les plans peuvent changer et nous continuerons à surveiller la situation.

Mise à jour : Le “Server Meshing” en lui-même devrait bien sûr aider à résoudre les problèmes de désynchronisation causés par les performances des serveurs, car chaque serveur ne se concentrera que sur une partie relativement petite de la simulation globale, répartissant la charge sur plusieurs serveurs. Mais ce n’est pas une solution miracle et nous devrons encore optimiser le code.


Question par Pitapa

Bonjour, cette question est une hypothèse émise par une personne qui n’a aucune connaissance du “Server Meshing”.

Si j’ai bien compris, avec le Server Meshing, si une zone est trop encombrée, le serveur se divise en plusieurs serveurs pour pouvoir traiter toutes les données.
Je ne sais pas à quel point ce processus est rapide, mais j’ai eu une idée qui pourrait être utile.

Avez-vous songé à utiliser le temps du voyage quantique pour réaliser ce processus ? Je veux dire, nous savons combien de joueurs se trouvent dans une zone et la charge du serveur. Lorsqu’un joueur sélectionne une destination pour le QT, le serveur peut faire quelques calculs avant le voyage. Ainsi, s’il prévoit que la destination sera trop fréquentée, il peut effectuer le “fractionnement du serveur” avant que le joueur n’y arrive.

Réponse par Clive Johnson

Oui, c’est une chose à laquelle nous avions déjà pensé et que nous avons intégrée dans nos plans. La première version du “Server Meshing” sera celle où les serveurs seront affectés à des régions fixes de l’espace, comme une planète ou une lune (pour les références futures, nous appelons cette première version le “Server Meshing statique”). Les limites entre ces serveurs seront si éloignées dans l’espace qu’il est peu probable que quiconque puisse les franchir autrement que lors de voyages quantiques entre les lieux. Cela réduira les types d’entités qui peuvent passer entre les serveurs, et la fréquence à laquelle elles le feront. Cela nous donnera également une bonne partie du temps nécessaire pour effectuer la transition entre les serveurs afin que nous puissions surveiller les performances de ce processus et apporter des améliorations sans que cela ne perturbe trop le gameplay.

PULSAR42 Association à but non lucratif de droit français régie par la loi du 1er juillet 1901, N° RNA : W923006718. SIRET 839 734 175 00012 - APE 9499Z

Design By June Lottin

This site is not endorsed by or affiliated with the Cloud Imperium or Roberts Space Industries group of companies. All game content and materials are copyright Cloud Imperium Rights LLC and Cloud Imperium Rights Ltd.. Star Citizen®, Squadron 42®, Roberts Space Industries®, and Cloud Imperium® are registered trademarks of Cloud Imperium Rights LLC. All rights reserved.