Le nouveau patcher de LoL et la distribution des données

Traduction du post suivant :

Ces 8 dernières années, LoL a utilisé un système de patching appelé "RADS" (Riot Application Distribution System) pour livrer les mises à jour. RADS est une solution personnalisée basée sur des deltas bninaires que nous avons construit avec LoL en tête. Si RADS nous a bien servi, nous sentions que nous avions une opportunité d'améliorer certaines aspects clés de l'expérience de patching. Nous savions que nous pouvions mettre en place les mises à jour beaucoup plus rapidement et de manière bien plus fiable en utilisant une approche fondamentalement différente, donc nous avons conçu un tout nouveau patcher basé sur une approche de segmentation de contenu.

Pour comparer notre ancienne et notre nouvelle solution dans les mêmes conditions, nous avons mis en place le nouveau patcher au fur et à mesure pendant les derniers mois. Cela nous a permis de valider nos hypothèses concernant l'efficacité d'une approche par segmentation de contenu. Maintenant que ces tests sont terminés et que les mesures ont montré des performances 10 fois meilleures en terme de vitesse de patching, nous aimerions partager quelques détails sur comment ça fonctionne.

Dans cet article, nous allons discuter de quelques éléments clés de notre nouveau patcher, comme les différences apportées par le nouvel algorithme par rapport aux deltas binaires, comment nous avons pu maximiser la vitesse de téléchargement pour les joueurs, et comment nous avons conçu un système de génération de patch qui nous permet de déployer une nouvelle version du jeu en quelques minutes au lieu de quelques heures.

Mise en place de mise à jour​ 

Les deltas binaires​ 

Les deltas binaires sont une manière commune de mettre en place des mises à jour. Un delta binaire représente la différente entre deux version d'un fichier. Vous démarrez avec les deux versions que vous voulez différencier, comparez leur contenu, et générez ensuite un patch binaire. Ce patch permet à n'importe qui avec une ancienne copie du fichier de la convertir dans la nouvelle version en réutilisant autant de données que possible.

Il est possible d'utiliser des outils comme xdelta ou bsdiff pour créer des patchs binaires. Pour RADS, nous utilisions un outil similaire nommé JojoDiff.

Les patchs binaires peuvent être très petits, ce qui aide à mettre en place des mises à jour rapidement. Mais vous finissez par avoir besoin de beaucoup de patchs en réserve lorsque les joueurs tentent de mettre à jour le jeu depuis une très vieille version du jeu. Il y a alors plusieurs options ici :

• Créer un patch à faire d'une version N-1 à N.
  • Avantage : Chaque fois que vous mettez en place une nouvelle version du jeu, vous n'avez besoin que de générer un seul patch.
  • Inconvénient : Si un joueur est M versions en arrière, alors il doit appliquer autant de patchs. Cela peut vraiment ralentir la vitesse de mise à jour.
• Créer un patch à faire pour chaque version précédente à la dernière.
  • Avantage : Les joueurs n'ont qu'un seul patch à effectuer quoiqu'il arrive
  • Inconvénient : Chaque fois que vous sortez une nouvelle version, vous devez créer beaucoup de patchs pour s'adapter aux multiples versions
• Utiliser des "skip lists" (Listes à enjambements) pour créer des patchs qui peuvent sauter plusieurs versions
  • Avantage : Il n'y a besoin que de générer quelques patchs à chaque mise à jour, et les joueurs peuvent faire les mises à jour jusqu'à la dernière version plus rapidement
  • Inconvénient : C'est plus complexe et demande plus de travail direct que les deux autres options

RADS utilise la deuxième option, et se limite 8 versions précédentes. Cela signifie que si un joueur dispose d'une de ces 8 versions, il peut faire une mise à jour vers la dernière en une seule étape. En revanche, pour les joueurs avec des installations plus anciennes, RADS doit retélécharger tous les fichiers, même s'il n'y a qu'une petite partie qui a changé. Cela provoque pour ces joueurs des téléchargement plus conséquents que les autres simplement parce qu'ils ne jouent pas fréquemment.

Les systèmes de deltas binaires sont optimisés pour les patchs de petite taille. Si cela semble bon à première vue, ce système demande des sacrifices importants. C'est pourquoi nous avons commencé à chercher des approches alternatives avec des sacrifices différents, que nous pourrions gérer plus facilement.

La segmentation de contenu​ 

Avec la segmentation de contenu, vous divisez un fichier en une série de briques de taille variable. Vous comparez ensuite la liste des briques que vous avez avec celles dans le nouveau fichier, et téléchargez celles qui vous manquent. Le fichier lui, peut être reconstruit en assemblant les briques dans le bon ordre, et en réutilisant une partie des données que vous avez déjà.

L'algorithme pour la segmentation de contenu est basé sur FastCDC, qui permet un hachage des données rapide (1GB / sec / coeur).

Ce qui rend ce contenu segmenté est que vous divisez le fichier uniquement à l'endroit où les données remplissent une condition particulière. Vous utilisez typiquement un "rolling hash" (Une fonction de hachage qui utilise une "fenêtre". Tout ce qui est dans cette fenêtre est hashé, et si on ajoute/supprime des choses, la fonction recalcule un nouveau hash à partir de l'ancien. L'ancienne valeur est supprimée, et la nouvelle ajoutée) à travers le fichier, et le divisez à chaque endroit où le hash correspond à certaines valeurs. Par exemple, si vous voulez que vos briques soient de 64KB en moyenne, vous pouvez faire la division à chaque fois que la valeur du hash se termine avec 16 bits à zéro. Les limites dépendent du contenu du fichier, donc vous finirez avec des briques plus grandes et d'autres plus petites, mais en moyenne elles devraient être proche de la taille que vous souhaitez.

Les avantages :

Le principal avantage de ce choix de limite est que vos briques ne changent presque pas lorsque des données sont modifiées dans un fichier. Si vous faites une division aveugle à 64KB par exemple, le simple ajout d'un bit au début du fichier changerait toutes les briques dans le fichier, ce qui serait très mauvais pour la taille des patchs.

Un système de patch basé sur la segmentation du contenu vous donne un avantage très important par rapport aux deltas binaires : vous pouvez mettre à jour n'importe quelle vieille version du jeu à jusqu'à la dernière efficacement et en une seule étape. C'était une chose importante pour nous parce que nous voulons que cela soit aussi facile pour quelqu'un de lancer une partie si cela fait quelques années qu'il n'a pas joué que pour quelqu'un qui a joué ce matin. Vous pouvez aussi mettre à jour une version partiellement mise à jour, ou une installation corrompue de la même manière. Vous pouvez même annuler des mises à jour rapidement si nécessaire. Tout ce qui importe est de quelles briques vous disposez, et de quelles briques vous avez besoin.

Les inconvénients :

L'inconvénient avec ce système est la taille des patchs. Du fait que l'unité du patch soit la brique, si seul un bit dans une brique a changé d'une version à l'autre, alors vous devez télécharger la brique entière. Dans un mauvais scénario où chaque brique aurait changé, vous devriez télécharger le jeu entier à nouveau. Heureusement, nous n'avons jamais été proche d'un tel scénario avec LoL. Actuellement, la taille des patchs avec le nouveau patcher est restée raisonnablement proche de celle des anciens.

Les utilisations antérieures :

La segmentation de contenu via les briques est utilisée habituellement dans les systèmes où la duplication des données est importante, notamment dans les systèmes de sauvegarde. C'est parce qu'il est facile de détecter que deux briques sont identiques à travers plusieurs fichiers et de ne garder qu'une seule copie de la brique. Mais c'est aussi utilisé dans les programmes de transferts de fichiers comme rsync pour savoir quelles parties du fichier ont été changées, et ne transférer que ces dernières.

Contrairement à rsync, on peut renseigner la liste des briques comprises dans chaque version du jeu parce que nous n'avons pas besoin de faire des transferts dans les deux sens. On publie la liste dans un réseau de diffusion de contenu (CDN), et on la distribue aux clients de jeu, pour qu'ils sachent quelles données ils doivent récupérer. Cela signifie aussi que nous n'avons pas besoin d'un logiciel serveur particulier non plus, et de cette manière, le système est plutôt similaire à zsync.

Nous appelons ce procédé de création de liste de briques une génération de patch.

La génération de patchs​ 

Avec RADS 

Générer un patch avec RADS impliquait beaucoup d'étapes très coûteuses en ressources. Nous avions d'abord à vérifier les différences de chaque fichier avec les 8 versions précédentes. Le dossier du jeu ne contient que 400 fichiers, mais ils sont lourds, et faire cette vérification peut prendre du temps. Après ça, nous devions compresser et packer des patchs binaires dans des fichiers BIN. Nous avions aussi à compresser chaque fichier original pour le cas où un client ne pourrait pas patcher une copie existantes. Nous avions ensuite à les upload sur un serveur, et enfin à les synchroniser avec chaque réseau de diffusion de contenu.

Beaucoup de ces étapes ne se faisaient pas en parallèle, ce qui rendait le procédé encore plus lent. Cela prenait généralement plusieurs heures à nos machines pour exécuter ces opérations.

 Avec le nouveau patcher

Le patcher à briques utilise un process beaucoup plus organisé. Nous commençons par appliquer l'algorithme de segmentation du contenu à chaque fichier pour déterminer de quelles briques il dispose. Nous n'avons pas besoin de comparer ces fichiers à leur précédentes versions, tout ce qui est compte, c'est quelles briques sont dans les nouveaux fichiers que nous voulons livrer. Nous n'avons besoin que de faire une passe sur les dernières données, ce qui est très rapide.

Une fois que nous avons déterminé la liste des briques, nous les hachons et les compressons. La valeur du hash en 64 bits est utilisée comme identifiant unique d'une brique. Cela nous permet de savoir rapidement lorsqu'une brique est trouvée dans plus d'un emplacement, et nous pouvons alors la dédupliquer (Méthode qui consiste à factoriser des séquences de données identiques pour économiser de l'espace de stockage). Nous somme capable de dédupliquer 10% des briques du jeu de cette manière, ce qui aide à réduire la taille du téléchargement initial.

La compression

Pour compresser les briques, nous utilisons Zstandard. Nous compressons en utilisant le niveau 19, ce qui nous donne un bon ratio de compression tout en gardant une bonne vitesse de décompression. Cette vitesse est importante lorsque vous téléchargez des briques sur le client. D'autres algorithmes comme LZMA ont un ratio de compression meilleur, mais l'utilisation du CPU pendant la décompression serait bien plus élevée.

Après la compression, nous réunissons toutes les briques dans un pack contenant un petit nombre de fichiers qui finiront sur le réseau de diffusion de contenu. Ces packs sont juste des concaténations de briques que les clients de jeu vont généralement télécharger en masse. Nous compressons chaque brique séparément, comme ça les clients peuvent télécharger certaines briques individuellement s'ils n'ont besoin que de ça.

Package

Le package est important pour améliorer l'efficacité des téléchargement. LoL contient plus de 300 000 briques, mais nous les regroupons en moins de 5 000 packs. Cela signifie que les joueurs peuvent télécharger l'intégralité du jeu sans utiliser plus de 5 000 requêtes HTTP. Si les briques étaient stockées séparément sur le réseau de diffusion de contenu, alors les joueurs auraient à faire 300 000 requêtes différentes, chacune pour un petit volume de données. Cela ralentirait fortement les mise à jour avec un tel nombre de requêtes à faire.

Les packs sont nommés après leur identifiant unique sur 64 bits. Nous calculons cet ID en fonction des briques dans le pack, ce qui fait que deux packs avec le même contenu auront le même nom. Cela nous permet de partager beaucoup de fichiers à travers différentes versions, ce qui permet de les garder en cache sur le réseau de diffusion de contenu plus longtemps. Nous pouvons aussi éviter d'upload un pack sur le réseau s'il existe déjà via une version précédente. Cela améliore la vitesse de génération des patchs de façon significative, puisque nous avons besoin d'upload moins de données, et n'avons pas à nous soucier de la compression de ces briques. Chaque version de LoL partage 85% des packs de la version précédente.

Écrire le manifeste de la mise à jour

Une fois que nous avons terminé de tout réunir dans des packs, l'étape suivante est d'écrire le manifeste de la mise à jour. Il stocke des informations sur les fichiers, les briques, et les packs qui sont une partie de la mise à jour. Cela pèse environ 8MB. Le manifeste utilise le format binaire FlatBuffers pour stocker ces informations, ce qui nous permet de la charger très rapidement sur le client. Nous pouvons également faire évoluer le schéma en fonction de nos besoin tout en maintenant la compatibilité.

L'étape finale consiste à upload les packs et le manifeste via une requête http post multipart (Ce genre de requête permet l'envoi de fichier vers un serveur http. C'est utilisé couramment par les navigateurs) vers un service C++ appelé "Patchdata-service". Ce service fonctionne sur AWS (Amazon Web Service), et est en charge du déploiement des données vers S3 (Le réseau de diffusion de contenu global). Le service procède également à des vérifications sur les données importées pour s'assurer qu'elles sont valides, avant de signer le manifeste de la mise à jour. Les clients de jeu ne chargeront un manifeste de mise à jour que s'il est correctement signé.

Mettre le tout ensemble

Même si cela semble être un processus étape par étape, toutes les étapes décrites plus haut se produisent en parallèle. Nous alimentons les fichiers à déployer d'un côté pendant que les données packées arrivent sur le S3 pour celles prêtes, en même temps que les données en attentes sont converties en briques. Ce procédé est aussi long que la partie la plus lente, qui est habituellement la compression.

Nous pouvons déployer une nouvelle version du jeu en moins d'une minute au lieu des 5 heures que cela prenait auparavant, ce qui est une grande victoire pour notre capacité à mettre en place des hotfix rapidement.

Gérer les téléchargements 

La tâche fondamentale du patcher est de fairre tout ce qui est nécessaire pour transformer l'installation existante du jeu vers celle désirée. Cela peut impliquer de télécharger de nouvelles briques, de mettre à jour des fichiers existants, de supprimer d'anciens fichiers, etc... 

Préparer la mise à jour 

1. Déterminer ce que nous avons déjà.
2. Déterminer ce dont nous avons besoin.
3. Télécharger tout ce qui manque, et transformer l'installation.

Vérifications 

Mais malgré tous nos efforts, parfois la base de données peut ne pas représenter parfaitement le contenu d'une installation du jeu. Par exemple, si un autre logiciel modifie les fichiers du jeu, ou si quelqu'un efface un fichier ici par erreur, la base de données ne sera plus correcte. C'est pour cela que nous procédons toujours à une petite vérification qui détermine si quelques chose ne va pas avec l'installation. Ce processus est très rapide, de l'ordre de 100ms, parce qu'il n'y a besoin que de lire les métadonnées des fichiers systèmes.

Chaque fois qu'un joueur lance le jeu, nous vérifions que tous les fichiers sont présents, et qu'ils ont la taille et l'horodatage attendus. Même si nous ne pouvons pas détecter tous les potentiels problèmes comme les secteurs disques défectueux ou une modification d'un fichier qui n'a pas modifié l'horodatage, cela nous aide à détecter les problématiques les plus communes. Approfondir et scanner le contenu de tous les fichiers prendrait trop de temps, donc nous le faisons uniquement lorsqu'un joueur demande une réparation complète du jeu dans le client.

Si nous détectons que quelque chose ne va pas avec la base de données, alors nous lançons un processus de réparation pour la reconstruire, chose dont on parlera plus bas. Pour l'heure, considérons que la base de données est correcte.

La mise à jour​ 

Maintenant qu'on sait ce que nous avons déjà, nous devons déterminer ce dont nous avons besoin. Cette information est dans le manifeste de la mise à jour. Avec le manifeste, nous pouvons comparer la liste des briques dont nous disposons avec celle dont nous avons besoin et faire un "plan de mise à jour". Ce plan crée toutes les étapes par lesquelles nous allons devoir passer pour mettre à jour l'installation. Nous pouvons utiliser le plan pour effectuer la mise à jour, ou nous pouvons l'utiliser juste pour estimer le volume de téléchargement et l'espace disque requis.

Avec le plan de mise à jour en main, nous pouvons démarrer le processus de mise à jour. Le plus important dans ce processus est de mettre à jour les fichiers sur le disque avec leur nouveau contenu, ce que nous faisons à la volée (Le terme anglais est "Update in place", mais je n'ai pas trouvé de traduction. Concrètement, ça signifie remplacer chaque fichier directement plutôt que d'en créer une copie au préalable). Procéder de la sorte nous permet de ne pas solliciter de l'espace disque supplémentaire. Cela réduit également le nombre d'entrées/sorties nécessaires en évitant des copies supplémentaires des fichiers concernés.

Le slicing

Nous mettons à jour les fichiers avec des étapes discrètes en écrivant un bloc à la fois. Un bloc est une partie continue d'un fichier qui doit être mise à jour avec de nouvelles briques. Elles peuvent provenir du réseau de diffusion de contenu si elles sont nouvelles du fait de la mise à jour, ou de fichiers existants si on les a déjà quelque part. Nous assemblons toutes les briques dont nous avons besoin dans le bon ordre vers une mémoire tampon, et les écrivons sur le disque en une fois.

Les blocs font jusqu'à 64MB, et commcencent/se terminent toujours à la limite d'une brique. La taille d'un bloc est limitée pour éviter d'utiliser trop de mémoire lorsque de gros fichiers sont mis à jour.

Après avoir écrit chaque bloc, nous mettons à jour la base de données avec les informations concernant les nouvelles briques qui occupent désormais cet espace. Cela rend la mise à jour facile à annuler pendant son exécution parce qu'elle est toujours dans un état connu, même si elle n'est pas totalement terminée. La prochaine fois que le joueur lance le client, le patcher sait exactement ce qu'il reste à faire.

Le téléchargement 

Pendant l'écriture des nouvelles données sur le disque, nous téléchargeons également les briques dont nous avons besoin depuis le réseau de diffusion de contenu. Nous les téléchargeons dans l'ordre où nous en aurons besoin, et nous essayons toujours d'avoir un peu d'avance sur le téléchargement par rapport à l'écriture sur le disque, mais nous limitons le volume de briques que nous téléchargeons à 128MB, de sorte à ce que l'usage de mémoire ne soit pas trop élevé dans le cas où l'écriture sur le disque est lente, et/ou la connexion peu performante.

Nous utilisons 8 connexions HTTP/1.1 concurrentes en parallèle pour télécharger les briques, ce qui aide à améliorer la vitesse et éviter le blocage "Head-of-line" (En HTTP, c'est un phénomène où le nombre de requêtes en parallèle autorisées est dépassé, et où les requêtes en trop doivent attendre que les précédentes se terminent). Nous n'utilisons pas HTTP/2 du fait d'une librairie (libcurl) que nous utilisons pour les téléchargements, qui a des problèmes connus impactant la vitesse de téléchargement, et qui ne nous aideraient pas avec le blocage "Head-of-line" au niveau du protocole TCP. Nous pensons que le HTTP/3 nous permettrait d'utiliser moins de connexions concurrentes, du fait du protocole QUIC, et nous espérons le tester quand il sera disponible à large échelle.

Nous avons lancé une série de tests A/B (Ces tests consistent à faire varier des requêtes d'un seul critère pour mesurer l'impact du changement de ce dernier) et déterminé que 8 connexions est la meilleure solution pour nous, plus que doubler la vitesse de téléchargement pour beaucoup de joueurs par rapport à une connexion simple :

Au delà de ces connexions HTTP au réseau de diffusion de contenu, nous envoyons une série de "Multipart range requests" (Requêtes visant à ne demander à un serveur qu'une portion d'un fichier) pour télécharger les briques dont nous avons besoin. Si nous avons besoin de toutes les briques dans un pack donné, on peut alors le télécharger en entier. Mais si nous n'avons besoin que de certaines d'entre elles, alors ce genre de requêtes permet de récupérer celles que nous voulons. Cela aide à réduire le nombre de requêtes HTTP que nous faisons lorsque nous avons besoin de beaucoup de briques spécifiques dans des fichiers.

Nous essayons de diviser ces connexions HTTP de sorte à toujours télécharger sur plusieurs réseaux de diffusion de contenu en même temps, et même plusieurs fournisseurs de réseaux de diffusion de contenu si possible. Cela rend le patcher plus résiliant face aux problématiques d'un serveur, et peut aider à trouver le fournisseur de réseaux de diffusion de contenu le plus efficace dans chaque région. Chaque minute, nous faisons des requêtes DNS pour obtenir la liste la plus à jour des serveurs disponibles, et divisons les connexions de cette manière.

Nous répétons également les requêtes ayant échoué agressivement. Chaque erreur réseau n'est pas considérée comme fatale, et la requête sera renvoyée avec un délai aussi long que nécessaire, même si nous pouvons annuler la mise à jour si nous ne sommes pas en mesure de progresser après plusieurs minutes. Cela aide le patcher à surmonter les problématiques de connectivité temporaire, et à compléter la mise à jour dans de nombreux cas où RADS aurait précédemment abandonné.

Les réparations

Parfois, les choses ne se déroulent pas comme prévues. Le processus de mise à jour considère que le contenu du disque correspond à ce qui est enregistré dans la base de donnée. Quand ce n'est pas le cas, il faut corriger ça. On appelle ça une réparation.

Le processus de réparation est très utile pour corriger de façon proactive les problèmes d'installation qui pourrait faire crash le jeu plus tard. Une réparation complète prend moins de deux minutes en moyenne, et beaucoup moins avec un processeur rapide et un SSD.

Réparation partielle​

Le premier type de réparation se produit lorsque le processus de vérification détecte une incohérence entre la base de donnée et le disque. Nous appelons ce type de réparation une réparation partielle, parce qu'il n'y a besoin que de scanner les fichiers qui semblent défaillants. Certains fichiers peuvent être absents, ou avoir la mauvaise taille, ou un mauvais horodatage. Si un fichier est manquant, alors on efface juste ses enregistrements en base de données, puisque nous n'avons clairement plus ces briques. Nous récupérons ensuite les fichiers défaillants et les reconstruisons pour rétablir la liste des briques qu'ils contiennent. Ce processus demande juste à lancer l'algorithme de segmentation de contenu sur ces fichiers. Pour finir, nous mettons à jour la base de données avec la liste des briques que nous avons trouvé, ainsi la base de données correspond à ce qui se trouve sur le disque.

Réparation complète​

L'autre type de réparation, à savoir la réparation complète, se produit quand le patcher met à jour l'installation mais rencontre un problème qu'il ne peut pas gérer. Par exemple, il peut être en train d'essayer de lire une brique existante d'un fichier, mais le fichier s'avère illisible. Comme il est possible que ce ne soit pas le seul problème avec l'installation, nous reconstruisons tous les fichiers que nous voyons avec des problèmes. Si un fichier est illisible, alors nous l'effaçons pour pouvoir le télécharger à nouveau plus tard. Quand une réparation complète se termine, nous avons une nouvelle base de données correspondant à ce qui est sur le disque.

Les résultats 

Nous mettons beaucoup d'efforts en oeuvre pour utiliser les ressources d'une machine efficacement. Réseau, disque, et usage du processeur se superposent chaque fois que c'est possible. Nous avons aussi changé notre processus de packaging de données pour nous assurer d'avoir des fichiers stables à travers les versions, en réduisant le volume nécessaire sur le disque. Associé à notre algorithme fondamentalement plus simple, le résultat final est un processus de mise à jour bien plus rapide que ce que nous avions avant.

Nous avons comparé le temps pour une mise à jour pour chaque type de patcher - RADS et notre patcher à segmentation de contenu - sur le patch 9.9. Pour donner un peu de contexte, ces temps représentent la durée pendant laquelle un joueur doit attendre avant de pouvoir jouer, y compris le temps pour télécharger de nouvelles données, et le temps pour appliquer la mise à jour à des fichiers sur le disque.

La taille du patch était d'environ 68MB pour RADS, et de 83MB pour le nouveau patcher. Malgré la plus grande taille et le téléchargement plus long, le joueur moyen était en mesure de mettre à jour le jeu en moins de 40sec avec le nouveau patcher, contre 8min pour l'ancien.

En fonction de la région, les joueurs ont vu leur vitesse de mise à jour être jusqu'à 14 fois plus rapide qu'avant. Et les mises à jour sont constamment plus rapide à travers les régions que nous avons contrôlé.

Si avoir des mises à jour plus rapide est une bonne chose, cela n'en vaudrait pas la peine si elles échouaient fréquemment au point que les joueurs ne puissent pas lancer le jeu. Nous avons été heureux de constater que le taux d'échec de mise à jour, a également baissé de façon significative.

Le taux d'échec de mise à jour est passé de 2.2% à 0.3%, et la majorité des échecs restant sont des problématiques de connectivité. Dit d'une autre manière, les joueurs ont vu une réduction des erreurs pendant une mise à jour aller jusqu'à 95%, en fonction de la région.

Ces résultats ont validé nos hypothèses concernant le fait que nous pouvions améliorer l'expérience de mise à jour avec un nouveau patcher.

Conclusion​

Notre patcher RADS a fait son travail de façon admirable pendant longtemps, mais repenser complètement notre approche des mises à jour avec la segmentation de contenu nous a permis d'atteindre un niveau de performance et de fiabilité que nous n'avions encore jamais vu. Nous continuerons à améliorer la technologie avec tout ce que nous avons appris sur la distribution de contenu de jeu à une audience mondiale.