> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Options de transport > Comparez les options de transport de PlayFab Party, notamment le relais cloud transparent et la connectivité directe d'égal à égal, ainsi que leur incidence sur la latence, la NAT et la fiabilité. # 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](/fr/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_sendmessage) pour transmettre un datagramme d'un point de terminaison Party local à un point de terminaison distant, spécifiez [PartySendMessageOptions](/fr/services/playfab/multiplayer/networking/reference/enums/partysendmessageoptions) pour affiner le comportement de transport souhaité. Les fonctionnalités sont les suivantes : * **Remise garantie** : l'indicateur `GuaranteedDelivery` garantit 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 est `BestEffortDelivery`, 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 `SequentialDelivery` avec `GuaranteedDelivery` peut 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](https://wikipedia.org/wiki/Head-of-line_blocking). * **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'indicateur `AlwaysCoalesceUntilFlushed` retarde la transmission jusqu'à l'appel de `PartyLocalEndpoint::FlushMessages`, moment auquel les messages en file d'attente sont regroupés et transmis. Options de transport de Party ## Combinaison des options de remise et de séquencement Les options `GuaranteedDelivery`/`BestEffortDelivery` et `SequentialDelivery`/`NonsequentialDelivery` sont indépendantes et peuvent être combinées librement. Chaque combinaison produit un comportement distinct : | Remise | Séquencement | Comportement | | - | - | - | | `GuaranteedDelivery` | `SequentialDelivery` | Fiable et ordonné. Chaque message arrive dans l'ordre d'envoi. Si un message est perdu en transit, les messages séquentiels suivants sont mis en file d'attente sur le récepteur jusqu'à ce que le message manquant soit retransmis et remis. Le plus sensible au blocage en tête de ligne. | | `GuaranteedDelivery` | `NonsequentialDelivery` | Fiable et non ordonné. Chaque message arrive, mais chacun est remis à l'application dès son arrivée, quel que soit l'ordre d'envoi. Aucun blocage en tête de ligne. | | `BestEffortDelivery` | `SequentialDelivery` | Non fiable et ordonné. Les messages sont remis dans l'ordre, mais des lacunes sont autorisées. Si un message arrive après qu'un message séquentiel ultérieur a déjà été remis, le message arrivé en retard est abandonné. La séquence avance toujours. | | `BestEffortDelivery` | `NonsequentialDelivery` | Non fiable et non ordonné (par défaut). Envoyer et oublier : chaque message est remis dès son arrivée, sans garantie d'ordre ni de remise. Latence la plus faible. | ### 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 est **`SequentialDelivery`**, 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` + `SequentialDelivery`** pour 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` + `NonsequentialDelivery`** pour les états qui changent rapidement, où une faible latence compte davantage que l'exhaustivité (par exemple, positions des joueurs, direction de visée). Comme les messages séquentiels et non séquentiels sont indépendants, un message de changement d'état en cours de retransmission ne retarde pas la remise des mises à jour de position. ### 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 dans `PartyNetworkConfiguration.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. ## Statistiques réseau et mise en file d'attente locale Selon les options d'envoi des messages et l'état du réseau, Party peut mettre les messages en file d'attente localement avant leur transmission. Cette mise en file d'attente locale est gérée avec soin pour éviter d'introduire de la latence. La mise en file d'attente est nécessaire pour garantir que Party ne sature pas le réseau du joueur et que des fonctionnalités telles que le regroupement peuvent être appliquées. [PartyNetwork::GetNetworkStatistics](/fr/services/playfab/multiplayer/networking/reference/classes/PartyNetwork/methods/partynetwork_getnetworkstatistics) collecte des données sur les performances réseau globales, y compris la latence vers le service de relais Party. [PartyLocalEndpoint::GetEndpointStatistics](/fr/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_getendpointstatistics) offre une visibilité sur les statistiques de mise en file d'attente et de perte de paquets pour un point de terminaison distant spécifique. ## Related topics - [PAGE 111 · Transports accessibles pour les événements de jeu vidéo](/fr/build/game-principles/accessibility/page/page-111-transportation.md) - [Fonctionnalités de PlayFab Party](/fr/services/playfab/multiplayer/networking/party-features.md) - [Intégration de PlayFab pour les titres utilisant les services XBOX](/fr/services/xbox-services/playfab-integration.md) - [Erreurs de transport XTF](/fr/tools/tools-console/commandlinetools/xtf-transport-errors.md) - [Codes d'erreur](/fr/reference/errorcodes.md)