Skip to main content

Uso de balizas de calidad de servicio (QoS) para medir la latencia de los jugadores a Azure

Puede implementar servidores multijugador de PlayFab en más de una docena de regiones de Azure. Hay dos razones para hacerlo:
  1. Las regiones adicionales proporcionan redundancia. Si una sola región de Azure falla, los jugadores pueden acceder a servidores de otras regiones.
  2. Las regiones adicionales permiten a los jugadores acceder a servidores “cercanos” y ofrecen conectividad de baja latencia.
Cuando llama a RequestMultiplayerServer, especifica una lista clasificada de regiones de Azure que PlayFab usa para atender la solicitud. PlayFab intentará atender la solicitud usando la región clasificada en primer lugar, pero si no hay servidores de reserva en esa región, o la región presenta algún otro error, se intentará con una región subóptima situada más abajo en la lista. Siempre que sea posible, debe usar los datos de latencia de los jugadores para fundamentar la clasificación de las regiones de Azure usadas al solicitar un servidor multijugador. PlayFab proporciona servicios y herramientas para ayudar con esta tarea.

Balizas de calidad de servicio

PlayFab opera balizas en todas las regiones de Azure en uso por los servidores multijugador de PlayFab. Estas balizas reflejan el tráfico UDP y se pueden usar para medir la latencia con transporte UDP. El uso de UDP es importante, porque la mayoría de los juegos multijugador usan transporte UDP para su tráfico de juego más crítico para el rendimiento. Los proveedores de servicios de Internet y otros elementos del ecosistema de Internet pueden ofrecer un rendimiento diferenciado para los flujos UDP, TCP e ICMP. Este es el flujo típico para usar estas balizas en el contexto de un dispositivo de jugador:
  1. Inicie sesión del jugador en PlayFab. Esto se hace normalmente con LoginWithCustomID u otra API de inicio de sesión.
  2. Llame a ListQoSServersForTitle. Esto proporciona los nombres de host de las balizas de QoS de PlayFab. Una implementación típica podría ejecutar este procedimiento en la página del menú multijugador del juego.
  3. Cree un socket UDP.
  4. Envíe un único datagrama UDP al puerto 3075 del servidor de QoS. El contenido del mensaje debe empezar por 0xFFFF (1111 1111 1111 1111).
  5. El servidor responderá con un único datagrama, con los 2 primeros bytes del contenido del mensaje “invertidos” a 0x0000 (0000 0000 0000 0000). El resto del contenido del datagrama se copiará del ping inicial.
  6. Mida el tiempo transcurrido entre el envío del mensaje UDP y la recepción de una respuesta.

Uso del SDK de calidad de servicio

El SDK de C# y el SDK multiplataforma (CPP) de PlayFab proporcionan una implementación del código de ping de QoS. Puede compilar un SDK y usarlo como biblioteca auxiliar en sus juegos para PC, hacer referencia al paquete NuGet de C# o usar el código como ejemplo para otras plataformas. Cada API devuelve un QosResult que contiene una lista ordenada de regiones junto con el tiempo medio de ping a cada región.

C#

Hay API de QoS disponibles en el SDK de C#. Hay una implementación de ejemplo, WindowsRunnerCSharpClient, disponible en el repositorio gsdkSamples. El código se encuentra en PlayFabQosApi.cs. Parámetros:
  • timeoutMs: el tiempo de espera (en milisegundos) aplicado a cada intento de ping (valor predeterminado: 250 ms).
  • pingsPerRegion: el número de intentos de ping que se realizan contra cada región (valor predeterminado: 10). Aumentar este número incrementará el tiempo de ejecución, pero reducirá la probabilidad de resultados inexactos.
  • degreeOfParallelism: el número máximo de pings que se realizan en paralelo (valor predeterminado: 4). Aumentar este número reducirá el tiempo de ejecución, pero la contención de red puede provocar resultados inexactos si este número es demasiado grande.

C++

Hay dos API de QoS disponibles en el SDK multiplataforma (CPP) de PlayFab. El código se encuentra en PlayFabQosApi.cpp. Parámetros:
  • numThreads: el número máximo de pings que se realizan en paralelo. Aumentar este número reducirá el tiempo de ejecución, pero la contención de red puede provocar resultados inexactos si este número es demasiado grande.
  • timeoutMs: el tiempo de espera (en milisegundos) aplicado a cada intento de ping (valor predeterminado: 250 ms).
Última modificación el 28 de agosto de 2026