Configuration
Cette section décrit les fichiers .h et .lib à inclure lors de l’utilisation des API Winsock.- Ajoutez
#include <winhttp.h>dans vos fichiers sources. - Pour les titres PC, continuez à effectuer l’édition de liens avec
Winhttp.lib. - Pour les titres de console XBOX, vous devez effectuer l’édition de liens avec
XGamePlatform.lib, au lieu de le faire directement avecWinhttp.lib.
WINAPI_PARTITION_GAMES fonctionnent dans les titres Microsoft Game Development Kit (GDK).
Initialisation du réseau
Avant le premier appel à WSAStartup, les titres Microsoft Game Development Kit (GDK) doivent s’assurer que la pile réseau est prête. SiWSAStartup est appelé trop tôt pendant le processus de lancement du titre, WSAStartup ou les appels Winsock suivants risquent d’échouer. Pour savoir comment déterminer quand la pile réseau est prête, consultez Initialisation et connectivité du réseau.
Suspension et reprise
Vous devez vous inscrire aux événements de suspension et de reprise viaRegisterAppStateChangeNotification. Lors de la suspension, vous devez fermer tous les handles de socket et appeler WSACleanup. Lors de la reprise, vous devez à nouveau attendre l’initialisation du réseau avant d’appeler WSAStartup et de créer de nouveaux sockets.
API du port multijoueur UDP (User Datagram Protocol) local préféré du Microsoft Game Development Kit (GDK)
L’API du port multijoueur UDP local préféré du Microsoft Game Development Kit (GDK) retourne un port optimal, sélectionné dynamiquement, auquel les titres doivent se lier à l’aide de Winsock pour faciliter la communication en jeu via UDP. La plateforme Microsoft Game Development Kit (GDK) garantit que ce port spécifique est celui qui a le plus de chances de fonctionner dans l’environnement réseau particulier de chaque utilisateur. L’utilisation de ce port spécifique optimise l’exploitation des flux de support client et de diagnostic de la plateforme, augmente la compatibilité standardisée avec la traduction d’adresses réseau (NAT), fournit une fonctionnalité standardisée pour les appareils certifiés UPnP™ et identifie les paquets comme sensibles au temps réel pour les algorithmes de qualité de service (QoS) des routeurs et des FAI. Le port UDP est particulièrement pertinent pour les titres qui reposent sur des topologies réseau pair à pair. C’est le seul port qui autorise les paquets UDP entrants à traverser le pare-feu sans effectuer de traversée du pare-feu (firewall punching). Les titres qui reposent sur des topologies réseau pair à pair dans le Microsoft Game Development Kit (GDK) doivent toujours fournir leur propre mécanisme de découverte de l’adresse IP publique et du port, ainsi qu’une solution de traversée NAT pour les clients dont le type de NAT est modéré ou strict. Le port préféré améliore à lui seul le taux de réussite de ces technologies, mais ne les remplace pas. Les titres qui utilisent des topologies réseau client/serveur bénéficient également de l’utilisation du port UDP. La résolution des problèmes, UPnP™ et l’identification des paquets restent pertinents pour les portails captifs et les autres approches de filtrage basées sur la source, courantes dans les hôpitaux, les hôtels et les résidences universitaires. Nous recommandons vivement aux titres Microsoft Game Development Kit (GDK) d’utiliser le port multijoueur UDP local préféré pour leur trafic réseau principal de jeu multijoueur et de conversation.Sécurité des sockets
Les titres Microsoft Game Development Kit (GDK) sont chargés de garantir une sécurité et un chiffrement appropriés pour toutes les données transférées sur le réseau avec l’API Winsock. BCrypt, WinCrypt, schannel et d’autres API Windows standard fournissent les primitives de chiffrement recommandées. Les titres Microsoft Game Development Kit (GDK) doivent utiliser ces API pour implémenter DTLS (Datagram Transport Layer Security) et d’autres protocoles de sécurité standardisés pour tous les flux de sockets. Pour les titres qui ne souhaitent pas implémenter leur propre modèle de sécurité, la bibliothèque PlayFab Party du Microsoft Game Development Kit (GDK) fournit, entre autres fonctionnalités, une solution de sécurité des sockets complète et intégrée.Considérations relatives à la mémoire des sockets
Les titres Microsoft Game Development Kit (GDK) ne disposent actuellement que d’environ 16 Mo pour la pile réseau pour l’ensemble de l’utilisation de WinSock et WinHTTP ; au-delà, le système peut devenir instable. L’une des principales sources de consommation de mémoire se trouve dans les pools de mémoire d’envoi et de réception du mode noyau de WinSock, où les paquets entrants et sortants sont stockés jusqu’à ce qu’ils puissent être envoyés sur le réseau ou transférés vers la mémoire en mode utilisateur de votre titre via l’une des nombreuses variantes derecv.
En particulier dans les situations à bande passante élevée, il incombe à votre titre de transférer les données dans ses propres mémoires tampons en mode utilisateur avec une faible latence, à un débit au moins égal à celui auquel le pair ou le serveur distant envoie les données. Il existe plusieurs façons d’y parvenir, avec une complexité et des garanties croissantes, mais l’objectif sous-jacent de toutes les suggestions ci-dessous est de toujours avoir une mémoire tampon en mode utilisateur en attente pour un transfert immédiat dès l’arrivée des données, afin que le noyau n’ait pas besoin d’allouer une quantité croissante de mémoire. L’effet net est de déplacer l’utilisation de la mémoire pour les données en attente non traitées du pool noyau, extrêmement limité, vers la mémoire que vous gérez directement dans le pool de mémoire beaucoup plus grand de votre titre.
Les API de niveau supérieur qui utilisent WinSock disposent généralement de mécanismes permettant de contrôler l’utilisation de la mémoire noyau par leurs sockets. WinHTTP et XCurl permettent tous deux de contrôler leur utilisation de la mémoire noyau via leurs mécanismes respectifs de notification de lecture, tandis que d’autres API telles que XSAPI et PlayFab Party réduisent au minimum leur utilisation de la mémoire noyau à l’aide des techniques ci-dessous.
Sockets Berkeley (BSD)
Si vous souhaitez conserver les API de sockets Berkeley bloquantes, vous devez augmenter la fréquence des appels recv. Nous recommandons d’utiliser un thread dédié avec une boucle serrée qui met en file d’attente les données reçues pour qu’elles soient traitées ailleurs. Idéalement, le thread devrait toujours être bloqué dans un appel recv ; tout le temps passé en dehors de l’appel recv est potentiellement un temps pendant lequel l’utilisation de la mémoire noyau augmente en attendant que vous appeliez à nouveau recv. Souvent, si vous essayez de traiter les données avant d’appeler à nouveau recv, votre titre peut prendre du retard et l’utilisation de la mémoire noyau augmente tant que les données continuent d’être reçues à un débit élevé. Nous recommandons également de spécifier des tailles de mémoire tampon d’au moins 8 Ko afin de vous aligner sur les limites de taille des mémoires tampons du noyau et de mieux gérer la gigue et les modèles d’envoi en rafales.E/S avec chevauchement WinSock
Les E/S avec chevauchement de WinSock vous permettent de maintenir de manière asynchrone une mémoire tampon de réception en mode utilisateur en attente. Elles permettent également au noyau d’utiliser directement votre mémoire tampon et d’éviter une copie mémoire supplémentaire (contrairement au paradigme des sockets Berkeley) et, à condition qu’une mémoire tampon soit toujours en attente, le noyau n’effectue aucune allocation pour les données reçues. De plus, avec les E/S avec chevauchement, vous pouvez définir SO_RCVBUF et SO_SNDBUF sur la valeur spéciale 0, ce qui évite en grande partie toute allocation de mémoire noyau pour l’envoi et la réception. Cette approche est la meilleure façon de gérer la mémoire utilisée par vos sockets dans presque tous les scénarios.E/S inscrites
Les E/S inscrites (Registered I/O) constituent une API réseau complexe qui vous offre la latence la plus faible et garantit qu’aucune mémoire noyau n’est utilisée pour les opérations d’envoi et de réception. Elle vous permet de configurer plusieurs mémoires tampons de réception/d’envoi directement utilisées par le noyau, afin de garantir que vous disposez toujours de mémoires tampons prêtes pour les données entrantes.Taille maximale de l’unité de transmission UDP
Bien qu’une taille maximale théorique de charge utile existe dans le Microsoft Game Development Kit (GDK), en pratique, le maximum pour une connexion donnée dépend du type de connexion réseau. Il peut varier pendant l’exécution d’un titre. Au lieu d’essayer de déterminer l’unité de transmission maximale (MTU) réelle et de réagir aux modifications de la MTU pendant l’exécution de votre titre, vous devez concevoir votre code réseau en supposant une charge utile UDP maximale de 1 384 octets par paquet. Cette valeur peut être utilisée en toute sécurité dans toutes les configurations réseau pour éviter la fragmentation pendant la transmission. Nous le recommandons que le type de socket soit IPv4 ou IPv6. La transmission de charges utiles supérieures à 1 384 octets nécessite souvent une fragmentation des paquets au niveau IP. La fragmentation des paquets IP n’est pas bien prise en charge par les FAI ni par les routeurs et appareils domestiques des utilisateurs. Dans ces configurations réseau, la fragmentation des paquets IP ne provoque pas d’échec de l’API Winsock. La fragmentation apparaît plutôt comme des pertes de paquets pour votre titre. Pour éviter la fragmentation des paquets au niveau IP, utilisez 1 384 octets comme maximum sûr pour la charge utile de vos paquets. Pour garantir que votre titre évite la fragmentation et l’aider à satisfaire aux exigences XBOX associées concernant la configuration réseau minimale pour le jeu multijoueur, vous devez appliquer les options de socketIP_DONTFRAGMENT et IP_USER_MTU à chaque socket ouvert par votre titre. Ces indicateurs ne sont disponibles pour les titres Microsoft Game Development Kit (GDK) que lorsque l’API XGameRuntimeIsFeatureAvailable(XGameRuntimeFeature::XNetworking) retourne true. Si la fonctionnalité XNetworking n’est pas disponible, l’appel à setsockopt échoue. Voici un exemple de définition de ces deux options de socket.