Serveur minecraft

Martin Thompson à QCon London – Un bon serveur Minecraft

Le 30 octobre 2019 - 9 minutes de lecture

Les protocoles que nous utilisons devraient être davantage étudiés et mis en pratique, et ils sont très importants à de nombreux égards, Martin Thompson dans sa présentation à QCon Londres 2019, il a d'abord examiné l'évolution de l'humanité et affirmé que les protocoles constituent la découverte humaine la plus significative. Il a ensuite procédé à une analyse critique des protocoles que nous utilisons aujourd'hui.

Thompson, spécialiste des hautes performances et des faibles temps de latence, a commencé par définir le terme protocole à la fois d’un point de vue général et d’un point de vue informatique: un code prescrivant le strict respect de l’étiquette correcte et de la priorité, et un ensemble de conventions régissant le traitement et la mise en forme des données dans une système de communication électronique. Il souligne le mot priorité car c’est une question de timing – l’ordre dans lequel les choses se passent. Dans les systèmes concurrents et distribués, il est essentiel de les faire fonctionner correctement.

Documentation

Thompson recommande fortement de documenter nos protocoles. Lorsqu'il compare une API à un protocole, il décrit cette dernière comme une vue unidimensionnelle et anémique par rapport à un protocole. Il note que les protocoles ne sont pas compliqués et utilise un système de fichiers à titre d'exemple en utilisant une syntaxe de style d'expression pseudo régulière:

Ouvert, *[Read | Write], Proche

Une fois que vous avez ouvert un fichier, vous pouvez effectuer zéro opération ou plus en lecture / écriture et enfin fermer le fichier. Il souligne que ceci, en plus de décrire les opérations disponibles, vous indique également la priorité de l'utilisation, ce qui entraîne moins d'erreurs, et c'est quelque chose que l'API ne vous donnera pas. Vous pouvez ensuite développer cela et décrire chaque opération:

  1. Ouvert: …
  2. Lis: …
  3. Écrire: …
  4. Proche: …

Ceci décrit les interactions de manière très simple et constitue pour Thompson un moyen efficace d'améliorer la qualité du composant ou du service que vous développez. C'est généralement comme cela qu'il commence à travailler sur un système simultané et distribué. Il recommande également de réfléchir et de documenter les événements qui se produisent dans un système et quelles sont leurs conditions pré, post et invariantes.

Thompson recommande également de réfléchir aux problèmes pouvant survenir lorsque vous examinez les étapes ou l’interaction dans un système. Un exemple simple est lorsque vous utilisez une communication asynchrone: vous envoyez une demande et attendez une réponse. Qu'est-ce qui peut aller mal? Vous pouvez, par exemple, ne pas recevoir de réponse du tout, ce qui doit être réglé.

Multidiffusion

Un exemple plus réaliste et complexe implique la multidiffusion. Si vous souhaitez créer une salle de discussion qui partage beaucoup d'informations avec de nombreux utilisateurs, la multidiffusion est une solution courante. Si vous implémentez cela avec TCP, vous aurez un problème d'évolutivité car vous devez envoyer les données à tous les différents clients et gérer tous les accusés de réception (ACK), ce qui peut entraîner une implosion du trafic réseau.

Avec la multidiffusion, en utilisant UDP, vous pouvez envoyer des données une fois à tous les clients, mais cela pose également quelques problèmes. UDP n'est pas fiable. Pour savoir si vous avez perdu des données, vous avez besoin d'un accusé de réception, mais vous vous retrouvez alors dans un problème d'évolutivité – avec une implosion ACK.

Une façon de penser différente, et un protocole différent, consiste à reconnaître négativement (NAK) lorsque des données sont reçues hors séquence ou pas du tout. Cela a également des problèmes, car en cas de perte de données, tous les clients l’auront probablement et renverront un NAK en même temps. Le serveur enverra de nouveau toutes les données à tous les clients, ce qui provoquera un scénario de panne du réseau.

Thompson fait référence à un article de 1997 de Floyd et al: Un cadre multidiffusion fiable pour des sessions légères et un encadrement au niveau des applications, dans lequel ils ont introduit un algorithme permettant de faire un délai aléatoire très court avant qu'un client ne retourne un NAK, mais uniquement si aucun autre client n'a déjà renvoyé un NAK. Cela minimise le nombre de NAK envoyés tout en renvoyant toutes les données nécessaires. Pour Thompson, il s’agit d’une solution simple et agréable, d’un algorithme simple qui évolue très bien et représente l’essence d’un bon protocole en réfléchissant différemment à un problème.

Considérations de protocole

Lorsque nous examinons les protocoles en général, de nombreux aspects doivent être pris en compte, mais avec sa présentation dans la piste de la performance, Thompson a mis en exergue quelques aspects importants en mettant l'accent sur la performance:

  • Codage. N'utilisez pas de protocoles texte, utilisez des protocoles binaires. Thompson souligne que c'est le changement le plus important qui fera la différence. Il souligne également qu'un codec de texte n'est pas lisible par un humain. Nous utilisons un éditeur pour le lire, un outil, afin de pouvoir également utiliser un outil pour un codec binaire.
  • Sync vs Async. Les protocoles synchrones sont très lents et ils bloquent. Avec une latence accrue, ils deviennent encore plus lents et vous en faites moins. En utilisant un protocole asynchrone, vous pouvez en faire beaucoup plus, et cela fonctionne toujours bien avec une latence accrue. L’argument courant en faveur de l’utilisation de Synchrone est que c’est tellement plus facile, mais Thompson affirme que ce n’est pas le cas. Pour lui, c’est la façon dont vous envisagez le problème et dont vous gérez l’état. Vous devez dès le début concevoir une communication asynchrone avec un modèle d’état et une machine à états appropriée. D'après son expérience, les systèmes synchrones sont plus faciles à démarrer, mais ils deviennent beaucoup plus difficiles à mesure que la complexité augmente. Les systèmes asynchrones sont un peu plus difficiles à démarrer, mais restent au même niveau.

Nous devrions utiliser davantage les événements. Thompson souligne que le monde réel est distribué, découplé dans le temps et dans l’espace, et que nous devrions utiliser les événements pour le modéliser. La plupart des protocoles du monde réel, sinon tous, sont asynchrones, mais nous leur imposons des protocoles synchrones. Il vous recommande vivement de fournir une interface asynchrone lorsque vous concevez une API. Ensuite, si vous en avez vraiment besoin, ajoutez un wrapper synchrone autour de celui-ci. Ne construisez pas simplement une interface synchrone, vous êtes alors coincé avec elle.

En regardant dans les protocoles qu'il pense avoir des problèmes de performances ou d'autres problèmes, il souligne:

  • RPC – HTTP – TCP, une pile commune de protocoles utilisée de nos jours par Thompson, est inappropriée. TCP n'a pas été conçu pour requête – réponse. C’est un bon protocole, mais pas pour ce à quoi il sert. Nous l’emballons ensuite avec HTTP, un modèle de récupération de documents, puis nous plaçons en plus le code RPC dont nous savons qu’il est en panne depuis des années. Il note cependant que nous essayons de résoudre les problèmes avec TCP Fast Open, QUIC et TLS 1.3.
  • 2PC / XA. Le commit en deux phases est un exemple d’essai de résoudre ce qui devrait être notre problème, le problème de quelqu'un d’autre. Il fait remarquer qu'ils ne tolèrent pas les fautes et fait référence à un article de Jim Gray et Leslie Lamport: Consensus on Transaction Commit.
  • Livraison garantie, quelque chose qui s'est avéré être faux à maintes reprises. Pour que les applications Thompson ne doivent pas compter sur le transport sous-jacent pour traiter toutes les erreurs susceptibles de se produire, elles doivent disposer de leurs propres protocoles de retour d'informations et de récupération. Il note également que nous devons dépendre du comportement d'un protocole, pas de son implémentation.

Thompson conclut en affirmant que les protocoles devraient être davantage étudiés et mis en pratique, ils sont très importants à de nombreux égards.

Les diapositives de la présentation sont disponibles au téléchargement. La plupart des présentations de la conférence ont été enregistrées et seront disponibles sur InfoQ au cours des prochains mois. La prochaine conférence de QCon, QCon.ai, sera axée sur l'IA et l'apprentissage automatique. Elle aura lieu du 15 au 17 avril 2019 à San Francisco. QCon London 2020 est prévu du 2 au 6 mars 2020.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.