Temas avanzados de las sesiones multijugador - XBOX Game Development Documentation

Use este tema para obtener información sobre conceptos avanzados de las sesiones multijugador. Este tema abarca lo siguiente:

Información general de las sesiones
Propiedades de los miembros
Funcionalidades de la sesión
Tamaño de la sesión
Estados de usuario de la sesión
Visibilidad y posibilidad de unión
Tiempos de espera de la sesión
Varios usuarios con sesión iniciada en una sola consola
Administración del ciclo de vida del proceso
Limpieza de sesiones inactivas
Árbitro de la sesión

Información general de las sesiones

Una sesión del Directorio de sesiones multijugador (MPSD) tiene un nombre de sesión y se identifica como una instancia de una plantilla de sesión. Una plantilla de sesión es un documento JSON que proporciona la configuración predeterminada de la sesión. La plantilla de sesión forma parte de una configuración de servicio con un identificador de configuración de servicio (SCID), que es un GUID. La plantilla de sesión se encuentra en Partner Center. Las configuraciones de servicio son los recursos orientados al desarrollador que se usan para la ingesta, la administración y las directivas de seguridad. Cuando se accede a una sesión a través de MPSD, la autorización de la entidad de seguridad se realiza contra la configuración de servicio según las directivas de acceso establecidas por el desarrollador a través de Partner Center. Las comprobaciones de acceso secundarias, como la validación de la pertenencia a la sesión, se realizan en el nivel de sesión cuando la sesión se carga después de que se haya autorizado el acceso a la configuración de servicio.

La funcionalidad que se establece a través de una plantilla no puede cambiarse mediante escrituras en MPSD. Para cambiar los valores, debe crear y enviar una nueva plantilla con los cambios necesarios. Cualquier elemento que no se establezca a través de una plantilla puede cambiarse mediante escrituras en MPSD.

Número de versión del contrato

En este tema se supone que su plantilla usa la versión de contrato 107, que es la versión que usa el MPSD actual para XBOX One (o posterior).

Referencia de sesión

Cada sesión de MPSD se identifica de forma única mediante una referencia de sesión, representada en la API de multijugador por la estructura XblMultiplayerSessionReference. La referencia de sesión contiene los siguientes valores de cadena.

Identificador de configuración de servicio (SCID)
Nombre de la plantilla de sesión
Nombre de la sesión

La referencia de sesión se asigna al URI para identificar sesiones, como se muestra a continuación. En la siguiente asignación de ejemplo, authority es sessiondirectory.xboxlive.com.

https://{authority}/serviceconfigs/{service-config-id}/sessiontemplates/{session-template-name}/sessions/{session-name}

Elementos de una sesión

Cada sesión contiene grupos de elementos que aplican reglas de mutabilidad y seguridad. Varían según el elemento de la sesión, junto con información de mantenimiento de solo lectura (metadatos). En esta sección se describen los grupos de elementos de sesión que se incluyen en los archivos JSON para configurar la sesión, y en el archivo JSON de la plantilla que elija.

Si usa contenedores personalizados para una implementación HTTP/REST, la sesión y la plantilla deben definir objetos JSON que reflejen con precisión la funcionalidad de la implementación.

Dentro de cada uno de los grupos de elementos hay dos objetos internos.

Objetos del sistema: Estos objetos tienen un esquema fijo que MPSD aplica e interpreta. Se validan y combinan. Dado que MPSD los define y sabe lo que significan, puede actuar sobre ellos. Para ver la definición completa de cada uno de los objetos del sistema, consulte las referencias tanto del prefijo XblMultiplayerSession como de los URI del Directorio de sesiones.
Objetos personalizados: Estos objetos son opcionales y no tienen esquema. Se usan para almacenar metadatos relacionados con un juego multijugador. Dado que MPSD no puede interpretar estos datos, no actúa sobre ellos. Los datos del juego o la información guardada deben almacenarse en Title-Managed Storage (TMS). Para obtener más información sobre TMS, consulte Información general del almacenamiento de títulos de los servicios XBOX.

Este es un ejemplo de un objeto JSON personalizado.

    "custom": {
      "myField1": true,
      "myField2": "string",
      "myField3": 5.5,
      "myField4": { "myObject": null },
      "myField5": [ "my", "array" ]
    }

Constantes de sesión

Las constantes de sesión solo las establece el creador o la plantilla de sesión en el momento de la creación. El objeto /constants/system se usa para definir las constantes del sistema multijugador tal como lo conoce MPSD. El contenedor asociado a este objeto está representado por la estructura XblMultiplayerSessionConstants. El objeto /constants/system puede definir varios elementos. Entre ellos se incluyen un objeto capabilities, un objeto metrics, un objeto managedInitialization (versión de contrato de plantilla 104 o 105) o memberInitialization (versión de contrato 107), un objeto peerToPeerRequirements, un objeto peerToHostRequirements y un objeto measurementsServerAddresses.

Propiedades de sesión

Use el objeto /properties/system para definir las propiedades de sesión para MPSD. El contenedor asociado a este objeto es la estructura XblMultiplayerSessionProperties. Los miembros de la sesión pueden escribir en las propiedades de sesión en cualquier momento. Algunos ejemplos de propiedades de sesión en formato JSON son joinRestriction, initializationSucceeded y el objeto matchmaking. Para ver un ejemplo del uso de este grupo de elementos, consulte Inicialización de la sesión de destino y QoS.

Constantes de miembro

Establezca las constantes de miembro en el momento de la unión para cada miembro de la sesión. El objeto JSON es /members/{index}/constants/system. La clase contenedora que representa a un miembro de la sesión es la estructura XblMultiplayerSessionMember. Volver al principio de este tema.

Propiedades de los miembros

En las propiedades de los miembros solo puede escribir un miembro de la sesión. Se establecen en el objeto /members/{index}/properties/system y reflejan los elementos de la estructura XblMultiplayerSessionMember. Este es un ejemplo.

    {
      // These flags control the member status and "activeTitle" and are mutually exclusive (it's an error to set both to true).
      // For each, false is the same as not present. The default status is "inactive"; that is, neither present.
      "ready": true,
      "active": false,

      // Base-64 blob, or not present. An empty string is the same as not present.
      "secureDeviceAddress": "ryY=",

      // During member initialization, if any members in the list fail, this member will also fail.
      // Can't be set on large sessions.
      "initializationGroup": [ 5 ],

      // List of the groups I'm in and the encounters I just had.
      // An encounter is a brief interaction with a group. When an encounter is reported, it counts as retroactively joining the group 30 seconds ago and just now leaving.
      // Group names use the session name validation rules (like case-insensitive).
      // On large sessions, groups are used to report who played with whom (rather than just session membership). Members
      // who are active in at least one group together at the same time are counted as playing together.
      // Empty lists are the same as no value specified.
      // The set of encounters is a point-in-time property, so it's immediately consumed and will never appear on a response.
      "groups": [ "team-buzz", "posse.99" ],
      "encounters": [ "CoffeeShop-757093D8-E41F-49D0-BB13-17A49B20C6B9" ],

      // Optional list of role preferences that the player has specified for role-based game modes.
      // All role names have to match across all members in the session. Role weights are
      // defined from 0-100.
      "RolePreference": { "medic": 75, "sniper": 25, "assault": 50, "support": 100 },

      // Quality of Service (QoS) measurements by lowercase device token.
      // Like all fields, "measurements" must be updated as a whole. It should be set once when measurement is complete, not incrementally.
      // Metrics can be omitted if they weren't successfully measured; that is, the peer is unreachable.
      // If a "measurements" object is set, it can't contain an entry for the member's own address.
      "measurements": {
        "e69c43a8": {
          "bandwidthDown": 19342,  // Kilobits per second.
          "bandwidthUp": 944,  // Kilobits per second.
          "custom": { }
        }

      // QoS measurements by game-server connection string. Like all fields, "serverMeasurements" must be updated as a whole, so it should be set once when measurement is complete.
      // If empty, it means that none of the measurements were completed within the "serverMeasurementTimeout".
      "serverMeasurements": {
        "server farm a": {
          "latency": 233  // Milliseconds.
        }
      },

      // Subscriptions for shoulder taps on session changes. The "profile" indicates which session changes to tap and other properties of the registration like the minimum time between taps.
      // The subscription is named with a title-generated GUID that's also sent back with the tap as a context ID.
      // Subscriptions can be added and removed individually, without affecting other subscriptions in the "subscriptions" object.
      // To remove a subscription, set its context ID to null.
      // (Like the "ready" and "active" flags, the "subscriptions" data is copied out and maintained internally, so the normal replace-all rule on system fields doesn't apply to "subscriptions".)
      // Can't be set on large sessions.
      "subscriptions": {
        "961dc162-3a8c-4982-b58b-0347ed086bc9": {
          "profile": "party",  // Or "matchmaking", "initialization", "roster", "queuehost", or "queue".
          "onBehalfOfTitleId": "3948320593",  // Optional decimal title ID of the registered channel. If not set, the title ID is taken from the token.
        },
        "709fef70-4638-4b94-905b-24cb02706eb5": null
      }
    }

Elementos de servidor

Los servidores son entidades que no son usuarios y que se han unido a una sesión o han sido invitadas a ella. Los objetos JSON asociados son /servers/{server-name}/constants/system y /servers/{server-name}/properties/system. En estos objetos solo pueden escribir los servidores.

El objeto /servers/{server-name}/constants/system no se usa actualmente.

Configuración de la sesión

Puede controlar la configuración de las sesiones de las siguientes maneras.

Use plantillas de sesión ingeridas a través de Partner Center.
Use llamadas a las API de multijugador y de emparejamiento o a las API de REST. Debe seguir usando una plantilla, pero no es necesario que contenga los valores que quiere configurar. Tenga en cuenta que su título no puede invalidar las constantes que ya están establecidas en la plantilla.

Se proporciona un documento JSON independiente para definir la propia sesión. Además, debe implementar cualquier funcionalidad de contenedor necesaria para un título determinado. El contenido de los documentos JSON y cualquier código contenedor deben reflejarse mutuamente con precisión y deben reflejar la versión de contrato de plantilla más reciente. El esquema de una sesión se versiona con la versión de la sesión (versión principal) y la revisión del protocolo (versión secundaria). Las versiones se combinan en el encabezado X-Xbl-Contract-Version como “100 * principal + secundaria”. Por ejemplo, un título v1.7 incluye el siguiente encabezado en cada solicitud REST, suponiendo la versión de contrato de plantilla más reciente, la 107: X-Xbl-Contract-Version: 107.

Recomendamos que la mayoría de los títulos (que usan la API de servicios XBOX (XSAPI)) usen la versión de contrato 105 y la versión de plantilla de sesión 107.

Plantillas de sesión

Cada plantilla de sesión es un documento JSON, parte de la configuración de servicio, que define el marco de la sesión que se crea y proporciona constantes para la nueva sesión. Para obtener más información, consulte Plantillas de sesión multijugador. Volver al principio de este tema.

Funcionalidades de la sesión

Las funcionalidades son constantes de la sesión de MPSD que configuran el comportamiento que MPSD debe aplicar a esa sesión. Lo más habitual es usar Partner Center para establecer las funcionalidades en la plantilla de sesión. Las funcionalidades se establecen en el objeto /constants/system/capabilities. Si no se necesita ninguna funcionalidad, use un objeto capabilities vacío.

Los títulos casi nunca cambian ni acceden a las funcionalidades de la sesión mediante la API de multijugador o la API de emparejamiento.

Las funcionalidades de la sesión están representadas por la estructura XblMultiplayerSessionCapabilities. Son valores booleanos que indican lo que la sesión puede admitir.

Conectividad
Juego
Tamaño grande
Conexión requerida para los miembros activos

La estructura XblMultiplayerSessionConstants contiene un miembro SessionCapabilities (que es de tipo XblMultiplayerSessionCapabilities) que define las siguientes propiedades relacionadas con las funcionalidades de la sesión.

CapabilitiesConnectivity
CapabilitiesGameplay
CapabilitiesLarge

Si el título define una funcionalidad de sesión dinámica, la propiedad correspondiente se establece en true para las constantes de sesión.

Volver al principio de este tema.

Tamaño de la sesión

El tamaño de una sesión de MPSD viene determinado por el número de miembros de esa sesión.

Tamaño máximo de la sesión

El tamaño máximo de una sesión es el número máximo de miembros de sesión que puede acomodar. Está representado por la propiedad XblMultiplayerSessionConstants::MaxMembersInSession. El tamaño máximo de miembros se establece en el objeto /constants/system. El tamaño máximo de la sesión está entre 1 y 100 miembros de sesión, y el valor predeterminado es 100 si no se establece en el momento de la creación. Si el tamaño necesario supera los 100, la sesión se denomina sesión “grande” y se configura de una forma especial.

Desconexión

Establecer un tamaño máximo para una sesión puede provocar que una plaza libre aparezca como ocupada durante determinados escenarios de desconexión. Por ejemplo, si un jugador se desconecta como resultado de un error de red o de energía, el retraso no se refleja inmediatamente en la sesión. El miembro se establece en Inactivo mediante la característica de detección de desconexiones. Para obtener más información, consulte la sección Control de notificaciones de cambios y detección de desconexiones de MPSD del tema de información general del Directorio de sesiones multijugador. En comparación, una malla del mismo nivel que usa un latido para detectar una desconexión suele detectar una desconexión en dos o tres segundos y puede liberar la plaza del jugador inmediatamente. Sin embargo, el árbitro no puede quitar a otros miembros.

Sesiones grandes

Una sesión grande de MPSD puede tener hasta 1000 miembros, pero tiene algunas características de sesión deshabilitadas, como la obtención de una lista de todos los miembros. El carácter grande de la sesión está representado por la propiedad XblMultiplayerSessionCapabilities::Large. Esta propiedad se establece en true para indicar una sesión grande. La funcionalidad “large” se indica en el objeto /constants/system/capabilities. Para obtener más información, consulte Funcionalidades de la sesión. Volver al principio de este tema.

Estados de usuario de la sesión

MPSD define un estado de usuario como el estado de un usuario que se ha agregado a una sesión. Los estados de usuario posibles se definen mediante la enumeración XblMultiplayerSessionStatus. También se considera que el usuario tiene un estado de “disponible” antes de agregarse a una sesión. Puede usar XblMultiplayerSessionCurrentUserSetStatus para cambiar el estado de usuario de la sesión. Realice este cambio para REST estableciendo correctamente /members/{index}/properties/system en el documento JSON de la sesión de juego.

Estado de usuario Reservado

El usuario se coloca en el estado de usuario Reservado cuando el árbitro ha seleccionado al usuario para ocupar una de las plazas libres de la sesión. En este estado, el usuario aún no ha aceptado oficialmente la invitación a la sesión ni se ha unido a la sesión para empezar a conectarse con los pares.

Estado de usuario Activo

Cuando un usuario está en el estado Activo, el título se ha unido a la sesión en nombre del usuario, y el usuario participa activamente en la sesión. El usuario continúa en este estado mientras esté jugando. Cuando un título se inicia por primera vez, debe comprobar si el usuario ya es miembro de alguna sesión, normalmente comprobando el estado de la sesión. Si el usuario es miembro de una sesión, el título puede entrar directamente en el juego y establecer los miembros locales participantes en el estado de usuario Activo. Un usuario debe permanecer en el estado Activo mientras juega en la sesión. Si un usuario abandona la sesión mediante la interfaz de usuario del juego, debe quitarse de la sesión mediante una llamada a XblMultiplayerSessionLeave. Si el usuario solo está temporalmente ausente del juego, como cuando el título está restringido, este debe mantener al usuario en el estado Activo durante un período de tiempo razonable. Es apropiado cambiar el estado del usuario a Inactivo si el usuario no ha regresado después de un período de tiempo especificado por el título.

Estado de usuario Inactivo

En el estado Inactivo, el usuario no está participando actualmente en el juego, pero todavía tiene una plaza guardada en la sesión. En otras palabras, el usuario “no está activo”. Es la propia consola del usuario la responsable de establecerlo en el estado de usuario Inactivo en la sesión. El árbitro no puede hacerlo. Algunos escenarios de ejemplo en los que un usuario se coloca en el estado Inactivo son los siguientes:

El título recibe un evento Suspending.
El usuario ha estado inactivo (sin entrada ni respuesta del mando) durante un período de tiempo definido por el título. Recomendamos dos minutos para un juego multijugador competitivo.
El título ha estado en modo restringido durante más de dos minutos o durante un período de tiempo definido por el título. Este período de tiempo de espera del modo restringido es la cantidad de tiempo prevista que un usuario podría estar ausente del título por usar una aplicación relacionada u otra experiencia relacionada con el título.
El usuario se ha desconectado de forma no ordenada de la sesión. Para obtener más información, consulte la sección Control de notificaciones de cambios y detección de desconexiones de MPSD del tema de información general del Directorio de sesiones multijugador.

Si el título se inicia y el estado de usuario de un miembro de sesión determinado está establecido en Inactivo, el título se ha suspendido o el usuario ha estado inactivo demasiado tiempo en la sesión. Dado que el título se está iniciando de nuevo, la indicación es que el usuario quiere continuar con la sesión de juego a la que pertenece. Si el estado del usuario es Activo cuando se inicia el título, esta situación probablemente se deba a una desconexión de red o a otro escenario en el que el título no pudo establecer al usuario en Inactivo antes de ser interrumpido. En ambos casos, su título debe intentar volver a conectar al usuario con el juego y permitir que los demás usuarios sigan jugando, o quitar al usuario de la sesión.

Estado de usuario cuando finaliza la sesión

Cuando finaliza la sesión, el juego se interrumpe. El título debe permitir que todos los usuarios se quiten a sí mismos mediante XblMultiplayerSessionLeave. Las actividades de sesión que estaban asociadas a los usuarios se borran automáticamente cuando abandonan la sesión. Volver al principio de este tema.

Visibilidad y posibilidad de unión

El acceso a la sesión se controla en el nivel de MPSD mediante dos opciones de configuración: la visibilidad de la sesión y la posibilidad de unión de la sesión. Las recomendaciones de visibilidad y posibilidad de unión que hacemos en este tema se aplican a los escenarios de título más comunes. Los títulos deben seguir estas configuraciones, si es posible. Deben usar lógica dentro del título para tomar la determinación final y autoritativa de si se admite a un nuevo jugador en una sesión.

Visibilidad de la sesión

La visibilidad de la sesión está representada por una constante que se establece al crear la sesión. Normalmente se define en la plantilla de sesión y determina qué tipos de usuarios tienen acceso de lectura y escritura a una sesión. Los valores posibles de la visibilidad de la sesión se definen mediante XblMultiplayerSearchHandleGetVisibility. Los valores permitidos para la constante de visibilidad en un archivo JSON son open, visible y private.

Visibilidad de sesión de juego recomendada: abierta

Las sesiones de juego abiertas no requieren reservas de jugadores, lo que simplifica el proceso de invitación. El árbitro no reserva jugadores en MPSD después de que se haya enviado una invitación, sino que solo realiza un seguimiento local de los jugadores invitados. Como resultado, los jugadores pueden conectarse inmediatamente al árbitro y determinar si deben unirse a una sesión, si son rechazados o si deben esperar (si se admiten jugadores en espera). El árbitro es la máxima autoridad. Responde e indica al nuevo miembro que permanezca en la sesión o que la abandone. El uso de la visibilidad de sesión de juego abierta requiere que el jugador invitado inicie un título y se conecte al árbitro antes de que se haya tomado la decisión final. Puede mostrar un mensaje de error al usuario si una sesión está llena o si se ha rechazado una invitación. Para establecer una conexión con el árbitro, se requiere una dirección de dispositivo segura. La propiedad XblMultiplayerSessionProperties::HostDeviceToken se usa para averiguar qué miembro de la sesión es el árbitro actual de una sesión y qué dirección de dispositivo segura debe usar un jugador invitado para la conexión.

Posibilidad de unión de la sesión

La posibilidad de unión de la sesión determina qué tipos de usuarios pueden unirse a una sesión. Puede establecerse dinámicamente durante una sesión. Los valores posibles de la posibilidad de unión de la sesión son los siguientes.

None (predeterminado): No hay restricciones sobre quién puede unirse a la sesión.
Local: Solo los usuarios locales pueden unirse a la sesión.
Followed: Solo los usuarios locales y los usuarios seguidos por otros miembros de la sesión pueden unirse a la sesión sin una reserva.

Un árbitro de la sesión puede crear una sesión privada mediante la configuración de posibilidad de unión. Establecer la posibilidad de unión en local o followed restringe el acceso a la sesión y la convierte en privada. El árbitro también debe realizar un seguimiento de la posibilidad de unión de la sesión, de modo que las invitaciones de sesión antiguas puedan rechazarse en el nivel del host si es necesario. Por ejemplo, si algún jugador invitado no ha llegado a unirse a una sesión hasta que la sesión ya está llena, el árbitro puede indicar a los jugadores que se unen que la sesión se ha bloqueado y que deben abandonarla automáticamente. Volver al principio de este tema.

Tiempos de espera de la sesión

Las sesiones pueden cambiarse mediante temporizadores y otros eventos externos. Los tiempos de espera de la sesión definen los períodos durante los cuales los miembros de la sesión pueden permanecer en estados específicos antes de que se les establezca automáticamente como inactivos o se les quite de la sesión. MPSD también admite tiempos de espera para administrar la duración de la sesión.

La configuración de los tiempos de espera se realiza en /constants/system/timeouts, o dentro del objeto de inicialización administrada, para la versión de contrato de plantilla 104 o 105. Para la versión 107 o posterior, la configuración se realiza individualmente en /constants/system o dentro del objeto de inicialización administrada.

Cuando expira un temporizador, MPSD no actualiza automáticamente la sesión ni notifica al árbitro en ese instante los cambios. Los estados de la sesión y de los tiempos de espera solo se actualizan inmediatamente antes de que se envíe una solicitud de lectura o escritura. La actualización inmediata garantiza que los datos devueltos sean los más actualizados.

Los tiempos de espera de la sesión no se apilan. Solo se aplica uno para una transición de estado contra cada miembro de la sesión en una actualización.

Tiempos de espera definidos actualmente

En esta sección se describen los tiempos de espera que MPSD define actualmente.

Todos los tiempos de espera se especifican en milisegundos.
Se permite un valor de 0, que indica un tiempo de espera inmediato.
Un tiempo de espera sin valor se considera infinito.

Dado que los tiempos de espera tienen valores predeterminados, debe especificar explícitamente null para un tiempo de espera infinito.

evaluationTimeout

Este tiempo de espera indica la cantidad de tiempo de que dispone un miembro de la sesión para tomar y cargar la decisión de evaluación. Si no se recibe ninguna decisión, la decisión se cuenta como un error. Este tiempo de espera se coloca en el objeto de inicialización administrada.

inactiveRemovalTimeout

Este tiempo de espera se establece para un miembro de sesión que se ha unido a una sesión pero que no está participando actualmente en el juego. De forma predeterminada, el miembro se quita de la sesión después de dos horas.

Este tiempo de espera se denomina tiempo de espera de inactividad para la versión de contrato de plantilla 104 o 105.

En muchos casos, recomendamos establecer el tiempo de espera de inactividad en 0. Esto hace que cualquier usuario que se establezca en el estado Inactivo se quite inmediatamente de la sesión y que se libere la plaza correspondiente. Este comportamiento es deseable para la mayoría de los juegos multijugador competitivos, de modo que, si un usuario ha pasado a estar inactivo o ha alcanzado un estado Inactivo, se pueda agregar rápidamente un nuevo jugador. Para diseños cooperativos u otros diseños multijugador, es posible que quiera que su título permita a los usuarios más tiempo para volver a conectarse si se desconectan o no participan en el título durante períodos de tiempo. Tenga en cuenta que ninguna solución única se adapta a todos los escenarios de diseño.

joinTimeout

Este tiempo de espera indica el número de milisegundos de que dispone un usuario para unirse a la sesión. Las reservas se quitan para los usuarios que no logran unirse a la sesión. Este tiempo de espera se coloca en el objeto de inicialización administrada.

measurementTimeout

Este tiempo de espera indica la cantidad de tiempo de que dispone un miembro de la sesión para cargar las mediciones. Un miembro que no logra cargar las mediciones se marca con un motivo de error de “timeout”. Este tiempo de espera se coloca en el objeto de inicialización administrada.

Durante el emparejamiento, se aplica un tiempo de espera de 45 segundos para las mediciones de QoS. Como resultado, recomendamos que use un tiempo de espera de medición menor o igual que 30 segundos durante el emparejamiento.

readyRemovalTimeout

Este tiempo de espera se establece para un miembro de sesión que se ha unido a la sesión y está intentando entrar en el juego. Esto suele significar que el shell ha unido al usuario en nombre del título y que este se está iniciando. De forma predeterminada, el miembro se quita de la sesión y se coloca en el estado Inactivo después de tres minutos.

Este tiempo de espera se denomina tiempo de espera de preparación para la versión de contrato 104 o 105.

reservedRemovalTimeout

Este tiempo de espera se establece para un miembro de sesión que otra persona ha agregado a la sesión pero que aún no se ha unido a ella. La reserva se elimina y el miembro se considera inactivo cuando expira el tiempo de espera. El valor predeterminado es 30 segundos.

Este tiempo de espera se denomina tiempo de espera de reserva para la versión de contrato 104 o 105.

sessionEmptyTimeout

Este tiempo de espera indica el número de milisegundos tras los cuales una sesión que queda vacía se elimina. El valor predeterminado es 0.

Este tiempo de espera se denomina tiempo de espera sessionEmpty para la versión de contrato 104 o 105.

Ejemplo de tiempo de espera de sesión

Se inicia una sesión con cuatro jugadores.
Dos jugadores, A y B, se desconectan debido a un error de energía. Su estado en el juego sigue siendo Activo.
Los otros dos jugadores, C y D, salen correctamente mediante XblMultiplayerSessionLeave.
La sesión permanece abierta. Los jugadores A y B están desconectados, pero siguen en el estado Activo.
Unos días después, el jugador A regresa e inicia el juego.
El juego del jugador A comprueba las sesiones de las que el jugador A es miembro (realiza una lectura) y encuentra la sesión huérfana de hace unos días.
La sesión realiza una comprobación de presencia contra los dos jugadores que todavía están en la sesión (A y B).
1. Dado que el jugador A está ejecutando el título, la comprobación de presencia contra el jugador A se realiza correctamente. El estado Activo del jugador en la partida se mantiene igual.
2. El jugador B no está ejecutando el título. Como resultado, la comprobación de presencia del jugador B falla. El servicio establece el estado del jugador B en Inactivo. En este momento, comienza el tiempo de espera de inactividad para el jugador B.
El jugador A sale de la sesión correctamente mediante el método XblMultiplayerSessionLeave.
El tiempo de espera de inactividad expira para el jugador B, que se quita de la sesión en la siguiente lectura o escritura que realice cualquiera.
La sesión ahora tiene cero miembros y se quita del servicio.

Si el tiempo de espera de inactividad de la sesión del ejemplo se establece en 0, el jugador B agota el tiempo de espera inmediatamente después de la comprobación de presencia del paso 7.1 y probablemente se quita mediante la escritura de la sesión. En este caso, la sesión se cierra sin necesidad de una lectura o escritura adicional en la sesión. Volver al principio de este tema.

Varios usuarios con sesión iniciada en una sola consola

Cuando varios usuarios han iniciado sesión en la misma consola, es posible que algunos usuarios estén en una sesión de juego mientras que otros no estén en la sesión o no estén activos en el título actual. También pueden recibirse y aceptarse invitaciones de juego para varios usuarios, lo que afecta a la pertenencia a la sesión de juego. Tenga en cuenta esta información para su título, de modo que pueda controlar correctamente todos los escenarios de pertenencia a sesiones. En un escenario común, un nuevo jugador inicia sesión, pasa a estar activo en el juego y debe agregarse a una sesión de juego existente. Al igual que al crear una nueva sesión de juego, un título solo debe agregar a un usuario cuando sea apropiado durante el juego. Con varios usuarios con sesión iniciada, uno o varios usuarios también pueden recibir invitaciones a otra sesión de juego. Los títulos no necesitan controlar estos escenarios de ninguna manera específica. El estado de la sesión y los eventos de miembros notifican al título cualquier actualización de la sesión de juego y de la pertenencia de los usuarios. Para controlar varios usuarios con sesión iniciada en una sesión en línea, el título se suscribe a los toques de aviso (shoulder taps) de todos los usuarios, usando un objeto XboxLiveContext Class independiente para cada usuario. El título usa la propiedad XblMultiplayerSessionInfo::ChangeNumber para determinar cambios concretos en la sesión y omitir los toques de aviso duplicados. Volver al principio de este tema.

Administración del ciclo de vida del proceso

Al igual que un título que no es multijugador, un título en una sesión multijugador puede encontrarse con eventos de ciclo de vida del proceso de suspensión y finalización del título. Como resultado, el árbitro de la sesión debe guardar periódicamente el estado de la sesión. En caso de que el árbitro se suspenda, el título debe intentar la migración del árbitro y guardar el estado del juego según corresponda. Un nuevo árbitro puede entonces restaurar el estado de la sesión. De este modo, es posible suspender una sesión multijugador completa y reanudarla más tarde si la sesión sigue siendo válida en MPSD. Solo un par designado, normalmente el host del juego, debe actualizar el estado global del juego.

Almacenamiento de metadatos del juego

Un título almacena los metadatos del juego en la sesión de MPSD. Los metadatos del juego son la información necesaria para mostrar los datos de la sesión y permitir que el título encuentre la sesión de juego y se una a ella. El título almacena los metadatos específicos del jugador en la sección de propiedades personalizadas del miembro de la sesión. Por ejemplo, el color del jugador y el arma preferida del jugador para la sesión. Los metadatos de toda la sesión, como el mapa actual, se almacenan en la sección de propiedades personalizadas globales de la sesión de MPSD.

Almacenamiento del estado del juego

El estado del juego se almacena en TMS mediante el servicio de almacenamiento de títulos. El almacenamiento en esta ubicación permite que un título migre el árbitro sin problemas de permisos. Para obtener más información, consulte Migración de un árbitro.

El título no debe intentar guardar el estado del juego en TMS con más frecuencia que una vez cada cinco minutos, a menos que se esté suspendiendo.

Volver al principio de este tema.

Limpieza de sesiones inactivas

Si sessionEmptyTimeout se establece en 0, una sesión de MPSD se elimina automáticamente cuando el último jugador abandona la sesión. Para aprender a evitar que una sesión sin usar contenga jugadores después de un bloqueo o una desconexión, consulte la sección Control de notificaciones de cambios y detección de desconexiones de MPSD del tema de información general del Directorio de sesiones multijugador. Un control incorrecto de las sesiones sin usar después de un bloqueo o una desconexión puede causar problemas cuando un título consulta las sesiones de un jugador. Recomendamos que limpie las sesiones inactivas haciendo que el título consulte todas las sesiones de un usuario determinado mediante una llamada a XblMultiplayerGetSessionAsync y evaluando después las sesiones. Cuando el título encuentra una sesión obsoleta, llama a XblMultiplayerSessionLeave para todos los jugadores locales de la sesión. Esta llamada acaba reduciendo el recuento de miembros a 0 y limpia las sesiones. Volver al principio de este tema.

Árbitro de la sesión

Algunos métodos multijugador solo debe llamarlos un cliente dentro de una sesión de juego. Este cliente es una de las consolas que participan en la sesión, denominada árbitro, o host. Si al menos un miembro de la sesión está en una partida, la sesión debe tener un árbitro para supervisar las uniones en curso.

Establecimiento del árbitro

Cuando el cliente crea una sesión, designa una consola como árbitro. Para obtener más información, consulte la sección Establecer un árbitro para una sesión de MPSD del tema de tareas multijugador.

Guardado del estado de la sesión

Como se describe en la sección Administración del ciclo de vida del proceso, el árbitro debe guardar periódicamente el estado de la sesión. Un nuevo árbitro debe poder restaurar el estado de la sesión en caso de que el título realice una migración del árbitro. Para obtener más información, consulte Migración de un árbitro.

Administración de los miembros de la sesión de juego y de las uniones en curso

El rol más importante del árbitro de la sesión es administrar a los usuarios que entran en la sesión de juego para jugar. Esto incluye controlar las invitaciones al juego, notificar a los jugadores en espera y trabajar con los jugadores que abandonan la partida.

Recepción de notificaciones

El árbitro debe escuchar a los nuevos jugadores que quieren unirse a la sesión de juego mediante XblMultiplayerSessionChangedHandler.

Búsqueda de jugadores para ocupar las plazas vacías de la sesión de juego

El árbitro busca jugadores para ocupar las plazas vacías de la sesión de juego mediante una de las siguientes operaciones.

Si su título usa una sesión de sala de espera u otro mecanismo para permitir uniones diferidas, busque nuevos miembros de sesión mediante ese mecanismo.
Cree otra sesión de vale de partida.

Para obtener más información, consulte la sección Ocupar plazas de sesión libres durante el emparejamiento del tema de tareas multijugador.

Control de los miembros de sesión invitados

El árbitro debe supervisar a los miembros de sesión invitados y aplicar un intervalo mínimo entre las invitaciones a un mismo usuario. Para obtener más información, consulte la sección Enviar invitaciones al juego del tema de tareas multijugador.

Última modificación el 28 de agosto de 2026

Temas relacionados

Conceptos del Directorio de sesiones multijugador (MPSD)Información general sobre el multijugador de los servicios de XBOX Plantillas de sesión multijugador Información general de Multiplayer Session Directory Conceptos

⌘I

​Información general de las sesiones

​Número de versión del contrato

​Referencia de sesión

​Elementos de una sesión

​Constantes de sesión

​Propiedades de sesión

​Constantes de miembro

​Propiedades de los miembros

​Elementos de servidor

​Configuración de la sesión

​Plantillas de sesión

​Funcionalidades de la sesión

​Tamaño de la sesión

​Tamaño máximo de la sesión

​Desconexión

​Sesiones grandes

​Estados de usuario de la sesión

​Estado de usuario Reservado

​Estado de usuario Activo

​Estado de usuario Inactivo

​Estado de usuario cuando finaliza la sesión

​Visibilidad y posibilidad de unión

​Visibilidad de la sesión

​Visibilidad de sesión de juego recomendada: abierta

​Posibilidad de unión de la sesión

​Tiempos de espera de la sesión

​Tiempos de espera definidos actualmente

​evaluationTimeout

​inactiveRemovalTimeout

​joinTimeout

​measurementTimeout

​readyRemovalTimeout

​reservedRemovalTimeout

​sessionEmptyTimeout

​Ejemplo de tiempo de espera de sesión

​Varios usuarios con sesión iniciada en una sola consola

​Administración del ciclo de vida del proceso

​Almacenamiento de metadatos del juego

​Almacenamiento del estado del juego

​Limpieza de sesiones inactivas

​Árbitro de la sesión

​Establecimiento del árbitro

​Guardado del estado de la sesión

​Administración de los miembros de la sesión de juego y de las uniones en curso

​Recepción de notificaciones

​Búsqueda de jugadores para ocupar las plazas vacías de la sesión de juego

​Control de los miembros de sesión invitados

Información general de las sesiones

Número de versión del contrato

Referencia de sesión

Elementos de una sesión

Constantes de sesión

Propiedades de sesión

Constantes de miembro

Propiedades de los miembros

Elementos de servidor

Configuración de la sesión

Plantillas de sesión

Funcionalidades de la sesión

Tamaño de la sesión

Tamaño máximo de la sesión

Desconexión

Sesiones grandes

Estados de usuario de la sesión

Estado de usuario Reservado

Estado de usuario Activo

Estado de usuario Inactivo

Estado de usuario cuando finaliza la sesión

Visibilidad y posibilidad de unión

Visibilidad de la sesión

Visibilidad de sesión de juego recomendada: abierta

Posibilidad de unión de la sesión

Tiempos de espera de la sesión

Tiempos de espera definidos actualmente

evaluationTimeout

inactiveRemovalTimeout

joinTimeout

measurementTimeout

readyRemovalTimeout

reservedRemovalTimeout

sessionEmptyTimeout

Ejemplo de tiempo de espera de sesión

Varios usuarios con sesión iniciada en una sola consola

Administración del ciclo de vida del proceso

Almacenamiento de metadatos del juego

Almacenamiento del estado del juego

Limpieza de sesiones inactivas

Árbitro de la sesión

Establecimiento del árbitro

Guardado del estado de la sesión

Administración de los miembros de la sesión de juego y de las uniones en curso

Recepción de notificaciones

Búsqueda de jugadores para ocupar las plazas vacías de la sesión de juego

Control de los miembros de sesión invitados