Autenticación S2S de MPSD
La autenticación de las llamadas S2S al servicio multijugador de los servicios de XBOX difiere de la de otros servicios de XBOX. Las llamadas con un tokenDelegation no se admiten, y solo las llamadas con autenticación de servicio son funcionales. Este tipo de autenticación habilita la funcionalidad S2S adicional de MPSD.
Como en otras llamadas S2S, se requiere un certificado de socio comercial (Business Partner Certificate). Debe existir una directiva Multiplayer.Manage de acceso completo. Esto es necesario para que el servicio web bajo el que se creó el certificado de socio comercial pueda proporcionar el nivel de acceso correcto para las llamadas S2S.
Para la autenticación de servicio se usa el siguiente flujo de autenticación.
-
Llame al servicio de autorización de XBOX para servicios (XBOX Authorization Service for Services) con el certificado de socio comercial para recuperar un token
S. -
Llame al servicio de tokens seguros de XBOX (XSTS) con este token
Sy unSandboxIdpara recibir un tokenX. En este paso no debe usarse un tokenDelegationni un tokenUser. ElSandboxIdespecificado en este flujo también debe estar en el conjunto de sandboxes que especificó durante la creación del certificado de socio comercial. Los certificados de socio comercial sin un sandbox específico no se admiten y provocan errores de autenticación que indican que falta un sandbox. -
Llame al servicio de MPSD con el token
Xy los encabezados (tal como se especifica en la sección siguiente).
Encabezados S2S de MPSD
Encabezado de título
Para actuar como el título correcto, se requiere el encabezadoX-Xbl-OnBehalfOf-Title con el siguiente formato.
Ejemplo
Encabezado de usuario
Para actuar como un usuario específico o un conjunto de usuarios, se requiere el encabezadoX-Xbl-OnBehalfOf-Users con el siguiente formato.
Ejemplo
priv=multiplayer. Indica que el usuario tiene el privilegio multijugador.
Al usar el encabezado X-Xbl-OnBehalfOf-Users, es como si el usuario identificado en el encabezado estuviera realizando la llamada directamente desde su consola. Como resultado, el servicio que realiza la llamada debe mantener la seguridad del usuario.
- Solo se pueden usar XUID reales.
- Los privilegios declarados para el usuario deben ser correctos.
- El usuario debe haber dado su consentimiento a cualquier acción que se haya realizado en su nombre.
Encabezado Deny-Scope
La directiva de accesoMultiplayer.Manage invalida los permisos de acceso del usuario en las llamadas S2S al servicio de MPSD. Por lo tanto, el acceso a las sesiones no se restringe en función de los permisos del usuario. Para volver a habilitar las comprobaciones de permisos de usuario, puede usar el encabezado X-Xbl-Deny-Scope, como se muestra a continuación.
Ejemplo
Multiplayer.Manage no se use como invalidación al comprobar el acceso de un usuario (del encabezado de usuario) a una sesión. Puede usarse para asegurarse de que un usuario tiene el acceso correcto a una sesión y de que el acceso del servidor no está invalidando otros bloqueos debidos a restricciones de visibilidad o de unión.
Cuando establezca este encabezado, también debe conceder acceso
Multiplayer.Runtime al servicio web como reserva. Esto permite el acceso incluso cuando se deniegan los permisos de usuario. De lo contrario, en un escenario de error no se concede ningún acceso al servicio y se devuelve un estado 403. El acceso Multiplayer.Runtime requiere un usuario que actúe. El encabezado X-Xbl-Deny-Scope solo funciona junto con X-Xbl-OnBehalfOf-Users o una notificación de usuario obtenida de una notificación DelegationToken.Administración de miembros de sesión
Puede optimizar la administración de miembros de sesión en las llamadas S2S dirigiéndose a varios usuarios en una sola llamada. Cuando especifica el encabezado de usuario, no se puede usar el miembro estándar “me” en el cuerpo del documento de sesión. En su lugar, están disponibles las siguientes opciones.Adición de miembros de sesión
Puede agregar o modificar miembros de sesión usando uno de los patrones mencionados anteriormente. En general, la operación mínima para agregar un jugador es establecer una propiedad o constante, normalmente la propiedad de estado activo del miembro.Los miembros que no están establecidos como activos son eliminados automáticamente por el servicio en función del valor de
InactiveTimeout de la sesión de MPSD.Ejemplo
Eliminación de miembros de sesión
Puede quitar miembros de sesión estableciendo la sección del miembro ennull.
Ejemplo
Reservas de miembros
En general, las reservas para miembros de sesión no son necesarias si toda la administración de la sesión la realiza el servicio del título. En este escenario, puede agregar y quitar miembros de sesión directamente sin necesidad de reservas. Las reservas de miembros de sesión solo deben usarse si las sesiones creadas también son administradas después por el cliente. Puede agregar reservas a la sesión para varios usuarios en el orden de usuarios especificado en el encabezadoon-behalf-of-user. El siguiente patrón solo es válido al crear una sesión nueva.
Ejemplo
Las sesiones grandes no admiten reservas. No se admite mezclar reservas con la adición o eliminación de miembros de sesión.
Estado de los miembros de sesión
Un servicio de título puede realizar el seguimiento y establecer el estado de un miembro de sesión mediante propiedades del sistema. Esto permite un control total del estado y la información del miembro.Estado activo del miembro
El estado activo de un miembro marca al jugador como activo en la sesión. Esto evita su eliminación por parte del sistema según lo definido en la configuración de sesióninactiveRemovalTimeout, como se muestra a continuación.
active cuando se agregan a la sesión. Solo debe usar miembros inactivos en flujos en los que los miembros de sesión deban permanecer temporalmente en la sesión, incluso si están desconectados. En los flujos S2S, esto también puede administrarse directamente en el servidor del título.
Estado de reserva del miembro
Puede determinar el estado de reserva de un miembro de sesión mediante la propiedadreserved member. Si esta propiedad está establecida en true, el miembro de sesión está en estado de reserva y aún no está activo en la sesión.
A continuación se muestra un documento de sesión de ejemplo.
reservedRemovalTimeout.
Limitaciones de las sesiones grandes
Las sesiones de MPSD con la capacidad large habilitada admiten más de 100 jugadores. Estas sesiones funcionan de forma diferente a las sesiones normales. Para obtener más información, consulte Habilitar sesiones grandes para multijugador. Las operaciones en sesiones grandes siempre se realizan como un solo usuario. Como resultado, las llamadas S2S a sesiones grandes solo deben incluir un único usuario en el encabezadoX-Xbl-OnBehalfOf-Users. No se admiten operaciones con varios usuarios. Debe agregar o quitar usuarios mediante llamadas individuales para cada usuario. Realice estas llamadas S2S de forma secuencial para evitar la congestión de bloqueos en el documento de sesión subyacente. Las operaciones en paralelo sobre el mismo documento producen tiempos de llamada más largos y no aceleran el tiempo total de la operación.
Los resultados de las llamadas S2S tampoco proporcionan acceso a la lista completa de miembros de una sesión grande. Solo se devuelven los datos del miembro correspondiente al usuario especificado en la llamada.
Como resultado, los servicios de título deben realizar el seguimiento de la información de los miembros de las sesiones grandes con su propia lógica y usar la pertenencia de MPSD para cumplir correctamente los requisitos de XBOX (XR).
Encuentros y grupos
Las sesiones con la capacidad large no actualizan automáticamente la lista de jugadores recientes. En su lugar, los demás jugadores se agregan directamente a la lista de jugadores recientes mediante encuentros (Encounters) y grupos (Groups). Para obtener más detalles, consulte Habilitar sesiones grandes para multijugador. Use el siguiente patrón para marcar miembros de sesión como parte de un encuentro.Ejemplo
Para capturar correctamente un encuentro, la propiedad
encounters debe escribirse en todos los miembros de sesión participantes en menos de 30 segundos. El conjunto de encuentros es una propiedad de un momento dado. Se consume inmediatamente y no es visible en una respuesta.Ejemplo
groups. Una operación de escritura con una lista vacía elimina todas las pertenencias a grupos.
La propiedad
groups es persistente y es visible en las respuestas de un miembro.Administración de la sesión de actividad
El identificador (handle) de actividad de MPSD de un usuario determina qué sesión se usa para las invitaciones de la plataforma y la unión a una partida en curso. Este identificador no puede establecerse mediante llamadas S2S y solo está disponible a través de las API de cliente. Un servidor del título puede compartir el nombre de la sesión con un cliente para permitir la creación del identificador de actividad de una sesión S2S. Para obtener más información sobre los identificadores, consulte lo siguiente:- La sección Session handles del tema de información general sobre conceptos de multijugador
- La sección MPSD handles to sessions del tema de información general de Multiplayer Session Directory
Procedimientos recomendados
Al realizar llamadas S2S a MPSD, los títulos deben seguir los siguientes procedimientos recomendados para evitar problemas y mejorar el rendimiento.- Combine las operaciones para varios usuarios Siempre que sea posible, las llamadas S2S a MPSD deben realizarse como operaciones por lotes para varios usuarios. Esto mejora el rendimiento y reduce el tráfico de red. Un enfoque eficiente para reducir las llamadas es poner en cola las operaciones de MPSD en el servidor del título y combinar todas las solicitudes en intervalos de cinco segundos. Esto proporciona un equilibrio entre eficiencia y latencia.
- Combine varias operaciones de sesión y de miembros Los títulos deben asegurarse de combinar las operaciones de usuario tanto como sea posible. La adición de miembros de sesión siempre debe combinarse con el establecimiento de todas las propiedades relevantes del miembro al mismo tiempo.
- Realice de forma secuencial las llamadas S2S al mismo documento Todas las llamadas al mismo documento de MPSD deben realizarse siempre de forma secuencial. Realizar operaciones en paralelo puede causar congestión de bloqueos en el documento de MPSD subyacente y provocar un rendimiento más lento y solicitudes con error.
- Responda a las operaciones de identificadores de actividad en el cliente Los identificadores de actividad de MPSD solo se admiten a través de las API de cliente. Un servicio de título debe usar un cliente para crear estos identificadores compartiendo el nombre de la sesión y usando las API de cliente pertinentes.
- Las suscripciones de sesión del cliente y la conectividad no son necesarias Para todas las sesiones de MPSD que se administran completamente mediante llamadas S2S, la capacidad de conectividad no es necesaria. En los flujos de llamada S2S, no se necesitan conexiones WebSocket con el cliente. En su lugar, el servicio del título debe encargarse por completo de agregar o quitar directamente los miembros de sesión.
-
Operaciones de sesiones grandes
La lógica S2S para sesiones grandes debe manejarse de forma diferente a la de las sesiones pequeñas, porque las operaciones con varios miembros no están disponibles. Los servicios de título deben realizar de forma secuencial todas las operaciones sobre el mismo documento de sesión, incluida la adición o eliminación de miembros. Con un gran número de miembros, esto puede producir retrasos en la operación de miembros. Estos retrasos son aceptables y no infringen los requisitos de la plataforma.
Para simplificar la lógica de miembros en las sesiones grandes, un título puede usar la sesión de MPSD solo para realizar el seguimiento de la pertenencia de los jugadores y manejar internamente todos los demás datos de los jugadores.
Lo más sencillo es crear la sesión grande de MPSD para un servidor del título en el momento del inicio del servidor, incluso sin jugadores en ella. Esto requiere la configuración de
sessionEmptyTimeouten las constantes de la sesión de MPSD, como se muestra en los ejemplos siguientes. - Unión a una partida en curso o invitaciones en sesiones grandes Las sesiones grandes admiten la unión a una partida en curso y las invitaciones a través de los servicios de XBOX. En la mayoría de los escenarios, es más sencillo usar una sesión normal para admitir esta funcionalidad. Esta sesión puede ser controlada por el servidor del título o por el cliente, y debe contener información para unirse a la sesión grande correspondiente.
-
Encuentros en sesiones grandes
Para garantizar que los encuentros en sesiones grandes se capturen correctamente, todas las propiedades de miembro
encountersdeben escribirse en menos de 30 segundos. Un servicio de título siempre debe intentar agrupar en una sola llamada de servicio las actualizaciones de la propiedadencountersde todos los miembros participantes. Los encuentros deben usar un identificador único. Se recomienda usar un GUID.
