Configuration du comportement de transport
Les fonctionnalités réseau de PlayFab Party étendent les fonctionnalités UDP (User Datagram Protocol) de la plateforme native afin de fournir des moyens de transport de datagrammes idéaux pour les jeux multijoueurs en temps réel. Alors que TCP (Transmission Control Protocol) fournit des flux fiables et qu’UDP fournit des datagrammes non fiables, vous pouvez configurer le comportement réseau de Party datagramme par datagramme. Lorsque vous utilisez PartyLocalEndpoint::SendMessage pour transmettre un datagramme d’un point de terminaison Party local à un point de terminaison distant, spécifiez PartySendMessageOptions pour affiner le comportement de transport souhaité. Les fonctionnalités sont les suivantes :- Remise garantie : l’indicateur
GuaranteedDeliverygarantit que le message parvient à toutes les cibles, en retransmettant implicitement les données si nécessaire pour atténuer la perte de paquets liée à l’environnement. Cet indicateur d’option convient bien à l’envoi d’informations d’état importantes qui doivent toujours atteindre leur destination, faute de quoi la cible doit être retirée du réseau. L’option par défaut estBestEffortDelivery, qui offre un comportement de type « envoyer et oublier » semblable à UDP. - Remise séquentielle : ordonne la remise du message par rapport aux autres messages envoyés séquentiellement depuis ce point de terminaison local vers le point de terminaison cible. Utilisez cet indicateur d’option pour envoyer des informations d’état qui doivent atteindre la destination dans un ordre particulier. La remise séquentielle peut entraîner une efficacité réseau légèrement inférieure et une attente plus longue pour recevoir tous les paquets en cas de perte ou de réordonnancement de paquets par l’environnement. L’utilisation de
SequentialDeliveryavecGuaranteedDeliverypeut entraîner la mise en file d’attente des messages sur le point de terminaison cible en attendant l’arrivée des messages séquentiels envoyés précédemment. La mise en file d’attente peut augmenter la latence perçue lors d’une perte ou d’un réordonnancement de paquets liés à l’environnement, mais le point de terminaison cible voit toujours chaque message dans l’ordre d’envoi. Ce compromis de performances est commun aux protocoles de type TCP et est parfois appelé blocage en tête de ligne. - Regroupement : la bibliothèque Party fragmente et réassemble automatiquement les messages volumineux qui dépassent la taille maximale prise en charge par l’environnement; les appelants n’ont donc pas à gérer la fragmentation. Si vous envoyez de nombreux petits datagrammes, le regroupement les combine en un seul paquet pour améliorer l’efficacité de la bande passante, au prix éventuel d’une latence supplémentaire. L’envoi avec l’indicateur
CoalesceOpportunistically(par défaut) regroupe le message avec d’autres messages en file d’attente s’il y en a, mais n’attend pas d’autres messages si le message peut être transmis immédiatement. L’envoi avec l’indicateurAlwaysCoalesceUntilFlushedretarde la transmission jusqu’à l’appel dePartyLocalEndpoint::FlushMessages, moment auquel les messages en file d’attente sont regroupés et transmis.
Combinaison des options de remise et de séquencement
Les optionsGuaranteedDelivery/BestEffortDelivery et SequentialDelivery/NonsequentialDelivery sont indépendantes et peuvent être combinées librement. Chaque combinaison produit un comportement distinct :
Comprendre le blocage en tête de ligne
Le blocage en tête de ligne se produit lorsqu’un message situé en tête d’une séquence de remise n’est pas encore disponible. Les messages suivants de la même séquence ne peuvent pas être remis à l’application, même si le récepteur les possède déjà. L’option pertinente pour le blocage en tête de ligne estSequentialDelivery, et non GuaranteedDelivery. La remise séquentielle crée une séquence ordonnée dans laquelle les messages antérieurs bloquent les suivants. GuaranteedDelivery peut amplifier l’impact, car un message manquant doit être retransmis plutôt qu’ignoré, ce qui prolonge l’attente. Avec BestEffortDelivery + SequentialDelivery, une lacune est ignorée et la séquence avance; la fenêtre de blocage est donc courte.
Les messages NonsequentialDelivery ne sont jamais bloqués par des messages séquentiels. Les deux modes de remise n’interfèrent pas l’un avec l’autre. Un message séquentiel garanti en cours de retransmission ne retarde pas la remise d’un message non séquentiel.
Conseils pratiques
Un modèle de jeu courant utilise simultanément plusieurs options d’envoi pour différents types de données :GuaranteedDelivery+SequentialDeliverypour les changements d’état du jeu où l’ordre et l’exhaustivité comptent (par exemple, mises à jour d’inventaire, transitions d’état de partie).BestEffortDelivery+NonsequentialDeliverypour les états qui changent rapidement, où une faible latence compte davantage que l’exhaustivité (par exemple, positions des joueurs, direction de visée).
Plusieurs séquences indépendantes
Chaque point de terminaison local représente un espace de séquence indépendant. Tous les messages séquentiels envoyés d’un point de terminaison local à un point de terminaison cible donné partagent les mêmes garanties d’ordre. Le blocage en tête de ligne au sein de cette séquence ne peut affecter que les autres messages séquentiels de la même séquence. Si vous avez besoin de plusieurs flux ordonnés indépendants entre les deux mêmes appareils (par exemple, un flux par sous-système de jeu), vous pouvez créer plusieurs points de terminaison locaux sur chaque appareil (jusqu’à la limite spécifiée dansPartyNetworkConfiguration.maxEndpointsPerDeviceCount lors de la création du réseau Party). Les messages séquentiels envoyés à partir de différents points de terminaison locaux n’ont aucune relation d’ordre ou de remise entre eux.