> ## 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. # Opciones de transporte > Compare las opciones de transporte de PlayFab Party, incluidas la retransmisión transparente en la nube y la conectividad directa entre pares, y cómo afecta cada una a la latencia, NAT y la confiabilidad. # Configuración del comportamiento de transporte Las funcionalidades de red de PlayFab Party amplían las características del Protocolo de datagramas de usuario (UDP) de la plataforma nativa para proporcionar servicios de transporte de datagramas ideales para juegos multijugador en tiempo real. Mientras que el Protocolo de control de transmisión (TCP) proporciona secuencias confiables y UDP proporciona datagramas no confiables, puede configurar el comportamiento de red de Party datagrama a datagrama. Cuando use [PartyLocalEndpoint::SendMessage](/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_sendmessage) para transmitir un datagrama desde un punto de conexión local de Party a un punto de conexión remoto, especifique [PartySendMessageOptions](/services/playfab/multiplayer/networking/reference/enums/partysendmessageoptions) para ajustar el comportamiento de transporte deseado. Las funcionalidades incluyen: * **Entrega garantizada**: la marca `GuaranteedDelivery` garantiza que el mensaje llegue a todos los destinos, retransmitiendo los datos de forma implícita si es necesario para mitigar la pérdida de paquetes del entorno. Esta marca de opción funciona bien al enviar información de estado importante que siempre debe llegar al destino o, de lo contrario, el destino debería quitarse de la red. La opción predeterminada es `BestEffortDelivery`, que proporciona un comportamiento de tipo UDP de "enviar y olvidar". * **Entrega secuencial**: ordena la entrega del mensaje con respecto a otros mensajes enviados secuencialmente desde este punto de conexión local al punto de conexión de destino. Use esta marca de opción para enviar información de estado que deba llegar al destino en una secuencia determinada. La entrega secuencial puede dar lugar a una eficiencia de red ligeramente menor y a una espera más larga para recibir todos los paquetes cuando hay pérdida de paquetes o reordenación por parte del entorno. Usar `SequentialDelivery` con `GuaranteedDelivery` puede hacer que los mensajes se pongan en cola en el punto de conexión de destino mientras esperan a que lleguen los mensajes secuenciales enviados previamente. La puesta en cola puede aumentar la latencia percibida durante la pérdida o reordenación de paquetes del entorno, pero el punto de conexión de destino siempre ve todos los mensajes en el orden de envío. Este equilibrio de rendimiento es común en los protocolos de tipo TCP y a veces se denomina [bloqueo de cabeza de línea](https://wikipedia.org/wiki/Head-of-line_blocking). * **Combinación**: la biblioteca de Party fragmenta y reensambla automáticamente los mensajes grandes que superan el tamaño máximo admitido por el entorno, por lo que los autores de las llamadas no tienen que administrar la fragmentación. Si envía muchos datagramas pequeños, la combinación los agrupa en un único paquete para mejorar la eficiencia del ancho de banda a costa de una posible latencia adicional. El envío con la marca `CoalesceOpportunistically` (la predeterminada) combina el mensaje con otros mensajes en cola si hay alguno disponible, pero no espera a que haya más si el mensaje puede transmitirse de inmediato. El envío con la marca `AlwaysCoalesceUntilFlushed` retrasa la transmisión hasta que se llama a `PartyLocalEndpoint::FlushMessages`, momento en el que los mensajes en cola se combinan y se transmiten. Opciones de transporte de Party ## Combinación de opciones de entrega y secuenciación Las opciones `GuaranteedDelivery`/`BestEffortDelivery` y `SequentialDelivery`/`NonsequentialDelivery` son independientes y se pueden combinar libremente. Cada combinación produce un comportamiento distinto: | Entrega | Secuenciación | Comportamiento | | -------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GuaranteedDelivery` | `SequentialDelivery` | Confiable y ordenada. Todos los mensajes llegan en el orden de envío. Si un mensaje se pierde en tránsito, los mensajes secuenciales posteriores se ponen en cola en el receptor hasta que el mensaje que falta se retransmite y se entrega. Es la combinación más susceptible al bloqueo de cabeza de línea. | | `GuaranteedDelivery` | `NonsequentialDelivery` | Confiable y sin orden. Todos los mensajes llegan, pero cada uno se entrega a la aplicación en cuanto llega, independientemente del orden de envío. Sin bloqueo de cabeza de línea. | | `BestEffortDelivery` | `SequentialDelivery` | No confiable y ordenada. Los mensajes se entregan en orden, pero se permiten huecos. Si un mensaje llega después de que ya se haya entregado un mensaje secuencial posterior, el mensaje que llega tarde se descarta. La secuencia siempre avanza. | | `BestEffortDelivery` | `NonsequentialDelivery` | No confiable y sin orden (el valor predeterminado). "Enviar y olvidar": cada mensaje se entrega en cuanto llega, sin garantías de orden ni de entrega. Latencia más baja. | ### Descripción del bloqueo de cabeza de línea El bloqueo de cabeza de línea se produce cuando un mensaje situado al principio de una secuencia de entrega aún no está disponible. Los mensajes posteriores de la misma secuencia no se pueden entregar a la aplicación, aunque el receptor ya los tenga. La opción relevante para el bloqueo de cabeza de línea es **`SequentialDelivery`**, no `GuaranteedDelivery`. La entrega secuencial crea una secuencia ordenada en la que los mensajes anteriores bloquean a los posteriores. `GuaranteedDelivery` puede *exagerar* el impacto porque un mensaje que falta debe retransmitirse en lugar de omitirse, lo que prolonga la espera. Con `BestEffortDelivery` + `SequentialDelivery`, un hueco se omite y la secuencia avanza, por lo que la ventana de bloqueo es corta. Los mensajes `NonsequentialDelivery` nunca quedan bloqueados por mensajes secuenciales. Los dos modos de entrega no interfieren entre sí. Un mensaje secuencial garantizado en retransmisión no retrasa la entrega de un mensaje no secuencial. ### Orientación práctica Un patrón habitual en los juegos usa varias opciones de envío simultáneamente para distintos tipos de datos: * **`GuaranteedDelivery` + `SequentialDelivery`** para cambios de estado del juego en los que importan el orden y la integridad (por ejemplo, actualizaciones de inventario, transiciones de estado de la partida). * **`BestEffortDelivery` + `NonsequentialDelivery`** para estados que cambian rápidamente, en los que la baja latencia importa más que la integridad (por ejemplo, posiciones de los jugadores, dirección de la puntería). Dado que los mensajes secuenciales y no secuenciales son independientes, un mensaje de cambio de estado en retransmisión no retrasa la entrega de las actualizaciones de posición. ### Varias secuencias independientes Cada punto de conexión local representa un espacio de secuencia independiente. Todos los mensajes secuenciales enviados desde un punto de conexión local a un punto de conexión de destino determinado comparten las mismas garantías de ordenación. El bloqueo de cabeza de línea dentro de esa secuencia solo puede afectar a otros mensajes secuenciales de la misma secuencia. Si necesita varias secuencias ordenadas independientes entre los mismos dos dispositivos (por ejemplo, una secuencia por subsistema del juego), puede crear varios puntos de conexión locales en cada dispositivo (hasta el límite especificado en `PartyNetworkConfiguration.maxEndpointsPerDeviceCount` cuando se crea la red de Party). Los mensajes secuenciales enviados desde distintos puntos de conexión locales no tienen ninguna relación de orden ni de entrega entre sí. ## Estadísticas de red y puesta en cola local Según las opciones de envío de mensajes y el estado de la red, Party podría poner en cola los mensajes localmente antes de la transmisión. Esta puesta en cola local se administra cuidadosamente para evitar introducir latencia. La puesta en cola es necesaria para garantizar que Party no sature la red del jugador y que se puedan aplicar características como la combinación. [PartyNetwork::GetNetworkStatistics](/services/playfab/multiplayer/networking/reference/classes/PartyNetwork/methods/partynetwork_getnetworkstatistics) recopila datos sobre el rendimiento agregado de la red, incluida la latencia hasta el servicio de retransmisión de Party. [PartyLocalEndpoint::GetEndpointStatistics](/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_getendpointstatistics) proporciona visibilidad de las estadísticas de puesta en cola y pérdida de paquetes de un punto de conexión remoto específico. ## Related topics - [PAGE 111 · Transporte accesible para eventos de juegos](/es/build/game-principles/accessibility/page/page-111-transportation.md) - [Características de PlayFab Party](/es/services/playfab/multiplayer/networking/party-features.md) - [PAGE · Listas de comprobación de accesibilidad de planificación previa y posteriores al evento](/es/build/game-principles/accessibility/page/page-checklists.md) - [Códigos de error](/es/reference/errorcodes.md) - [Opciones de pruebas previas al lanzamiento](/es/publishing/game-publishing/publishing-processes/managed-creators/publishing-processes-prerelease.md)