Configuration
Cette section décrit les fichiers .h et .lib que vous devez inclure lorsque vous utilisez les API Winsock.- Ajoutez
#include <winhttp.h>dans vos fichiers sources. - Pour les titres PC, continuez à effectuer l’édition des liens avec
Winhttp.lib. - Pour les titres de console XBOX, vous devez effectuer l’édition des liens avec
XGamePlatform.lib, plutôt que directement avecWinhttp.lib.
WINAPI_PARTITION_GAMES fonctionnent dans les titres du Microsoft Game Development Kit (GDK).
Initialisation du réseau
Avant le premier appel à WSAStartup, les titres du Microsoft Game Development Kit (GDK) doivent s’assurer que la pile réseau est prête. SiWSAStartup est appelée trop tôt pendant le processus de lancement du titre, WSAStartup ou les appels Winsock subséquents peuvent échouer. Pour savoir comment déterminer quand la pile réseau est prête, consultez Initialisation et connectivité réseau.
Suspension et reprise
Vous devez vous inscrire aux événements de suspension et de reprise au moyen deRegisterAppStateChangeNotification. Lors de la suspension, vous devez fermer tous les descripteurs de socket et appeler WSACleanup. Lors de la reprise, vous devez de 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 au moyen de Winsock pour faciliter la communication en jeu par UDP. La plateforme du Microsoft Game Development Kit (GDK) garantit que ce port précis est celui qui a le plus de chances de fonctionner dans l’environnement réseau particulier de chaque utilisateur. L’utilisation de ce port précis maximise le recours aux flux de soutien à la clientèle et de diagnostic de la plateforme, augmente la compatibilité standardisée de la traduction d’adresses réseau (NAT), fournit une fonctionnalité standardisée d’appareil certifié 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. Les titres qui reposent sur des topologies réseau pair à pair dans le Microsoft Game Development Kit (GDK) doivent tout de même fournir leur propre 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é à lui seul améliore 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 aussi de l’utilisation du port UDP. Le dépannage, 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 fortement que les titres du Microsoft Game Development Kit (GDK) utilisent le port multijoueur UDP local préféré pour leur principal trafic réseau multijoueur et de clavardage.Sécurité des sockets
Les titres du Microsoft Game Development Kit (GDK) sont responsables d’assurer une sécurité et un chiffrement appropriés pour toutes les données transférées sur le réseau au moyen de l’API Winsock. BCrypt, WinCrypt, schannel et d’autres API Windows standard fournissent les primitives cryptographiques recommandées. Les titres du Microsoft Game Development Kit (GDK) doivent utiliser ces API pour implémenter le protocole 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 une solution complète et intégrée de sécurité des sockets, entre autres fonctionnalités.Considérations relatives à la mémoire des sockets
Les titres du Microsoft Game Development Kit (GDK) ne disposent actuellement que d’environ 16 Mo pour la pile réseau pour toute l’utilisation de WinSock et de WinHTTP, au-delà de quoi le système peut devenir instable. L’une des plus grandes sources de consommation de mémoire se trouve dans les pools de mémoire d’envoi et de réception en 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 dans la mémoire en mode utilisateur de votre titre au moyen de l’une des nombreuses variantes derecv.
En particulier dans les situations de 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 que le pair ou le serveur distant envoie. Il existe quelques 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 à 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 de la mémoire gérée directement par vous dans le pool de mémoire beaucoup plus grand de votre titre.
Les API de plus haut niveau qui consomment WinSock disposent généralement de mécanismes pour contrôler l’utilisation de la mémoire noyau de leurs sockets. WinHTTP et XCurl permettent tous deux de contrôler leur utilisation de la mémoire noyau au moyen de leurs mécanismes respectifs de notification de lecture, tandis que d’autres API comme XSAPI et PlayFab Party réduisent au minimum leur utilisation de la mémoire noyau grâce aux 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 serait toujours bloqué dans un appel recv; tout le temps passé hors de l’appel recv est potentiellement du temps pendant lequel l’utilisation de la mémoire noyau augmente en attendant que vous appeliez recv de nouveau. Souvent, si vous tentez de traiter les données avant d’appeler recv de nouveau, votre titre peut prendre du retard et l’utilisation de la mémoire noyau augmentera tant que les données continueront d’être reçues à des débits élevés. Nous recommandons également de spécifier des tailles de mémoire tampon d’au moins 8 ko afin de s’aligner sur les limites de taille des mémoires tampons du noyau et d’aider à gérer la gigue et les modèles d’envoi en rafales.E/S superposées WinSock
Les E/S superposées de WinSock vous permettent de garder de façon asynchrone une mémoire tampon de réception en mode utilisateur en attente. Elles permettent aussi au noyau d’utiliser directement votre mémoire tampon et d’éviter une copie de mémoire supplémentaire (contrairement au paradigme des sockets Berkeley), et en supposant qu’une mémoire tampon est toujours en attente, le noyau n’effectuera aucune allocation pour les données reçues. De plus, avec les E/S superposées, vous pouvez définir SO_RCVBUF et SO_SNDBUF sur la valeur spéciale 0, ce qui évitera en grande partie toute allocation de mémoire noyau d’envoi ou de 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 et d’envoi utilisées directement par le noyau, afin de vous assurer d’avoir toujours des mémoires tampons prêtes pour les données entrantes.Taille maximale de l’unité de transmission UDP
Bien qu’une taille de charge utile maximale théorique 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. Plutôt que d’essayer de déterminer l’unité de transmission maximale (MTU) réelle et de réagir aux changements 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 en cours de transmission. Nous la recommandons, que le type de socket soit IPv4 ou IPv6. La transmission de charges utiles de plus de 1 384 octets exige 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’échecs de l’API Winsock. La fragmentation se manifeste plutôt par 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 vous assurer que votre titre évite la fragmentation et pour l’aider à satisfaire aux exigences XBOX associées concernant les exigences réseau multijoueurs minimales, vous devez appliquer les options de socketIP_DONTFRAGMENT et IP_USER_MTU à chaque socket ouvert par votre titre. Ces indicateurs ne sont offerts aux titres du 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.