- Resumo da revisão
- Introdução
- Terminologia usada neste documento
- O Multiplayer Session Directory
- Sessões do MPSD
- Atributos do modelo de sessão
- Atualização do esquema do contrato
- Inicialização de membros em documentos de sessão
- Sessão de tíquete de partida
- Modelos de Qualidade de Serviço (QoS)
- Detalhes da fase de QoS e da inicialização da sessão
- Sessão do XBOX Cloud Compute
- Sessão bruta e propriedades personalizadas do título
- Expiração de membros ativos
- Perguntas frequentes e solução de problemas
Resumo da revisão
As bibliotecas da XBOX Services API (XSAPI) do lado do cliente usam atualmente a versão de contrato 104 ao se comunicar com os serviços do MPSD. Esta versão do documento atualiza o esquema do modelo de sessão para a versão de contrato 107, que é a versão de contrato mais recente com suporte nos serviços do MPSD. As alterações entre as versões 104 e 107 estão resumidas na seção Atualização do esquema do contrato abaixo. Observe que os modelos escritos para a versão de contrato 104 precisarão ser atualizados se forem republicados como 107. No entanto, os serviços são compatíveis com versões anteriores, portanto você pode continuar usando as bibliotecas atuais, que serão atualizadas em uma versão futura. A revisão anterior deste documento atualizou as informações sobre sessões de servidor e adicionou uma nova seção sobre XSAPIs e chamadas de serviço RESTful. Além disso, a tabela da seção Consulta de informações de estado da sessão foi atualizada e a seção Modelos de Qualidade de Serviço (QoS) foi revisada.Introdução
Uma sessão multijogador é um documento seguro que fica na nuvem, no Multiplayer Session Directory (MPSD), e esse documento representa um grupo de pessoas jogando um jogo. Especificamente, as sessões multijogador têm as seguintes características:- Cada sessão tem um URI exclusivo.
- O documento de sessão contém os membros atuais, as configurações do jogo, os dados de inicialização e as informações do servidor de jogo.
- Os títulos criam e gerenciam suas próprias sessões.
- Uma sessão permite a conectividade entre seus membros.
Terminologia usada neste documento
O Multiplayer Session Directory
O MPSD facilita e ajuda os títulos a coordenar as informações de sessão entre jogadores online. Diferentes tipos de sessões podem ser criados para realizar diferentes tarefas do jogo multijogador. A tabela a seguir apresenta as diferenças entre como essas tarefas eram feitas no XBOX 360 e como são realizadas no XBOX One ou posterior (incluindo PC).Padrões de sessão
-
Sessões de jogo
- Sessão com os XUIDs dos jogadores, dados de endereço seguro do dispositivo e estados de propriedades. Ela é considerada a sessão de jogo propriamente dita.
- Pode ser ponto a ponto, ponto a host, ponto a servidor ou híbrida.
-
Sessões de tíquete de partida
- Uma sessão enviada ao matchmaking para encontrar outros jogadores com quem jogar. Observe que uma sessão de jogo também pode ser uma sessão de tíquete, se o jogo estiver procurando mais jogadores.
-
Sessões de servidor
- Sessões de jogo criadas e usadas por meio do processamento do XBOX Compute.
Sessões do MPSD
As sessões mantêm duas listas de entidades relacionadas:- Membros (usuários) que entraram em uma sessão ou foram convidados para ela.
- Servidores (servidores na nuvem ou servidores dedicados) que entraram na sessão.
- Valores constantes definidos no momento da criação.
- Propriedades mutáveis.
- Metadados somente leitura.
XSAPIs e chamadas de serviço RESTful
Há duas maneiras de interagir com os serviços de sessões e de matchmaking dos serviços XBOX.- Chamadas HTTPS padrão
- Wrappers da XSAPI
Usando chamadas HTTPS padrão para os serviços RESTful
No XBOX One e posteriores, a primeira maneira de interagir com os serviços de sessões e de matchmaking dos serviços XBOX é usar chamadas HTTPS padrão para os URIs RESTful dos serviços XBOX. Isso dá aos títulos flexibilidade para chamar e interagir com esses serviços, dependendo das configurações de servidor e de jogo. Para obter uma lista desses URIs, veja a Referência RESTful dos serviços XBOX.Usando os wrappers da XSAPI para serviços RESTful
A segunda maneira de interagir com os serviços de sessões e de matchmaking é usar as XSAPIs, que atuam como wrappers para os URIs dos serviços RESTful. Elas permitem uma abordagem mais tradicional de uso de APIs no código, sem precisar lidar com o tráfego HTTPS em cada chamada. Para obter mais informações sobre as XSAPIs, veja a página do xbox-live-api no GitHub. Essa documentação de referência inclui:- Referência da API de análise de JSON - Material de referência para as APIs de análise de JSON.
- Namespace Windows.Web - Membros do namespace Windows.Web.
- Referência do SDK do XBOX Compute - APIs para criar instâncias de servidor de jogo para o XBOX Compute.
Sessões e modelos do MPSD
As sessões do MPSD são criadas com modelos ingeridos por meio do Partner Center. Os modelos são documentos JSON que definem a estrutura da sessão que está sendo criada. O modelo fornece as constantes para a nova sessão. O trecho a seguir é um exemplo de configuração de modelo.
Verificando quais modelos estão configurados para o seu SCID
Modelos de sessão
A lista de modelos de sessão existentes em um SCID, bem como os detalhes de um modelo de sessão específico, pode ser recuperada do MPSD:Consulta de informações de estado da sessão
As sessões podem ser consultadas nos níveis de configuração de serviço e de modelo de sessão:
O resultado é uma matriz JSON de referências de sessão.
Alguns dados da sessão são incluídos embutidos.
Observação Toda consulta deve incluir um filtro de palavra-chave, um filtro de XUID ou ambos.
Definir private (que retorna sessões privadas) ou reservations (que retorna sessões nas quais o usuário não entrou) como true exige que o chamador tenha acesso de nível de servidor à sessão ou que a declaração de XUID do chamador corresponda ao filtro de XUID no URI.
Caso contrário, será retornado 403 Forbidden (independentemente de essas sessões existirem ou não).
O trecho de código a seguir mostra um exemplo de resposta de consulta.
Atributos do modelo de sessão
Atualização do esquema do contrato
Conforme mencionado no início deste documento, a versão de contrato de modelo de sessão mais recente é a 107, que introduz algumas alterações no esquema em relação à versão anterior, 104. Os modelos escritos para a versão de contrato 104 precisarão ser atualizados se forem republicados como 107. A seguir está um resumo das alterações.-
/constants/system/managedInitialization foi renomeado para /constants/system/memberInitialization.
- O campo autoEvaluate foi renomeado para externalEvaluation e sua polaridade mudou, exceto que false continua sendo o padrão.
- O valor padrão de membersNeededToStart mudou de 2 para 1.
- O valor padrão de joinTimeout mudou de 5 segundos para 10 segundos.
- O padrão de measurementTimeout mudou de 5 segundos para 30 segundos.
-
/constants/system/timeouts foi removido, e os tempos limite foram renomeados e realocados em /constants/system.
- O tempo limite reserved passa a ser reservedRemovalTimeout.
- O tempo limite inactive passa a ser inactiveRemovalTimeout e seu novo padrão é 0 em vez de 2 horas.
- O tempo limite ready passa a ser readyRemovalTimeout.
- O tempo limite sessionEmpty passa a ser sessionEmptyTimeout.
- /constants/system/capabilities/gameplay deve ser especificado como true em sessões que representam jogo real (em oposição a sessões auxiliares, como sessões de partida e de lobby) para habilitar os jogadores recentes e os relatórios de reputação.
Objetos do sistema
Cada um dos objetos do sistema no documento de sessão tem um esquema fixo que é imposto e interpretado pelo MPSD. No corpo das solicitações PUT, os objetos do sistema são validados e mesclados da mesma forma que os objetos personalizados. Mas, ao contrário dos objetos personalizados, depois de mesclados, os objetos do sistema são validados novamente e processados com base nesses esquemas. /constants/systemTempos limite
As sessões podem ser alteradas por temporizadores e outros eventos externos. O objeto Timeouts no MPSD fornece um mecanismo básico para gerenciar o tempo de vida e os membros da sessão. O campo nextTimer da sessão informa o horário do próximo temporizador. Os clientes podem usar essas informações para escolher um bom intervalo para a próxima sondagem. Esse valor também é retornado no cabeçalho HTTP Expires. Os tempos limite são especificados em milissegundos. Zero é permitido e significa que o tempo limite deve ser imediato. Se um determinado tempo limite não for especificado, ele será considerado infinito. Como os tempos limite têm padrões, o modelo de sessão deve especificar explicitamente “null” para um tempo limite infinito.SessionEmptyTimeout
O valor /constants/system/sessionEmptyTimeout configura o número de milissegundos após uma sessão ficar vazia para que ela seja excluída. O padrão é zero, o que significa que a sessão será excluída imediatamente. Se o valor não for especificado, as sessões vazias continuarão existindo indefinidamente.Tempos limite de membros
Os outros três tempos limite em /constants/system controlam por quanto tempo um membro pode permanecer em um determinado estado:-
reservedRemovalTimeout
- A reserva é excluída quando o tempo limite expira. O padrão é 30 segundos.
-
inactiveRemovalTimeout
- Um membro inativo é removido da sessão após duas horas, por padrão.
-
readyRemovalTimeout
- Os membros que estão “ready” voltam ao estado inativo após três minutos, por padrão.
Inicialização de membros em documentos de sessão
Inicialização de membros
O objeto memberInitialization controla os estágios de inicialização após a criação da sessão e/ou à medida que novos membros entram na sessão. Os tempos limite e os estágios de inicialização são acompanhados automaticamente pela sessão, incluindo as medições de QoS se houver métricas definidas. Esses tempos limite substituem os tempos limite de reserva e de “ready” da sessão para os membros que têm a propriedade initializationEpisode definida. Exemplo:
-
joiningTimeout
- O tempo, em milissegundos, que os usuários têm para entrar na sessão. As reservas dos membros que não conseguirem entrar são removidas.
-
measuringTimeout
- O tempo que os membros têm para enviar suas medições. Os membros que não conseguirem enviar as medições são marcados com um failureReason de “timeout”.
-
evaluationTimeout
- O tempo que um membro tem para tomar e enviar a decisão de avaliação. Se nenhuma decisão for recebida, isso contará como falha.
- O MPSD pode fazer uma avaliação automática de QoS com base nos requisitos fornecidos no modelo de sessão. A avaliação é realizada quando externalEvaluation está definido como false. externalEvaluation precisa ser true quando um evaluationTimeout é definido. Se houver dois requisitos ponto a ponto ou ponto a host, você ainda deverá definir externalEvaluation como false para que a sessão conclua a inicialização automaticamente.
- É o número mínimo de reservas de membros que precisam existir com “initialize”:“true” e passar no QoS para que a avaliação automática seja bem-sucedida.
Episódios de inicialização
Quando o objeto memberInitialization é definido, o MPSD avança as fases de inicialização por episódio. O primeiro episódio é iniciado quando a sessão é criada e incluirá todas as fases definidas no modelo. Todos os novos membros convidados ou que entrarem enquanto um episódio já estiver em andamento serão marcados para o próximo episódio. O status de um episódio ou do memberInitialization em geral pode ser recuperado do objeto initializing da sessão. Observação Esteja ciente de que esse objeto é removido após a conclusão da inicialização. Exemplo:Match ticket session
Quando uma sessão do MPSD está sendo usada como sessão de tíquete de partida, algumas propriedades e constantes especiais da sessão são usadas. /members//constants/systemModelos de Qualidade de Serviço (QoS)
Para modelos de sessão de jogo, podem ser adicionados valores que informam ao MPSD que ele deve se coordenar com a camada de rede e com os recursos sociais do console. O objetivo dessa coordenação é validar a qualidade do estado da conexão antes que uma sessão seja criada e antes que um usuário seja informado de que o jogo está pronto para receber entradas. O trecho de código a seguir é um exemplo de modelo de sessão de jogo ponto a host com QoS:Atributos do modelo de sessão com QoS
Se um objeto memberInitialization estiver definido, a sessão esperará que o sistema cliente ou o título realize a inicialização após a criação da sessão e/ou à medida que novos membros entrarem na sessão. Os tempos limite e os estágios de inicialização são acompanhados automaticamente pela sessão, incluindo as medições de QoS se houver métricas definidas. Esses tempos limite substituem os tempos limite de reserva e de “ready” da sessão para os membros que têm a propriedade initializationEpisode definida.Detalhes da fase de QoS e da inicialização da sessão
O MPSD acompanhará e relatará os resultados de QoS para a criação do jogo depois que o modelo concluir a inicialização de membros. O progresso dessa operação será representado por um objeto initializing no documento de sessão, conforme descrito na seção Inicialização de membros acima. O objeto initializing tem um atributo stage, que representa o estágio atual da inicialização. O estágio avança de joining para measuring e para evaluating.- Se o episódio de inicialização #1 falhar, o estágio será definido como failed e a sessão não poderá ser inicializada. Caso contrário, quando um episódio de inicialização for concluído, o objeto “initializing” será removido. Se externalEvaluation estiver definido como false, o estágio evaluating será ignorado. Se nem metrics nem measurementServerAddresses estiverem definidos, o estágio measuring será ignorado.
- Os candidatos a host são tokens de dispositivo listados em ordem de preferência. Eles são definidos após o estágio measuring do episódio de inicialização #1 se peerToHostRequirements estiver definido e /properties/system/host não estiver. Eles são limpos depois que um objeto /properties/system/host é definido.
- O atributo gamertag só será definido se o membro tiver aceitado e se uma declaração de gamertag tiver sido encontrada para esse membro.
- O atributo deviceToken é definido quando o membro envia um endereço seguro do dispositivo. É uma cadeia de caracteres que não diferencia maiúsculas de minúsculas e pode ser usada para comparações de igualdade.
- O valor reserved é removido depois que o usuário executa sua primeira solicitação PUT para o documento de sessão. Quando os jogadores estão reservados, isso significa que foram convidados para a sessão de jogo, mas ainda não aceitaram nem tiveram suas conexões avaliadas.
- Se o membro estiver ativo, activeTitleId será o título no qual o membro está ativo, em decimal.
- Esse atributo se refere ao horário em que o usuário entrou na sessão. Se reserved for true, joinTime será o horário em que a reserva foi feita.
- Presente se esse membro estiver na matriz properties/system/turn; caso contrário, ausente.
- O atributo initializationFailure é definido no objeto do membro na transição para fora do estágio joining ou measuring se o membro não tiver passado no estágio com êxito. Em ordem de precedência, ele pode ser definido como timeout, latency, bandwidthdown, bandwidthup, network, group ou episode. O valor network significa que a configuração e/ou as condições de rede (como conflitos de conversão de endereços de rede [NATs]) impediram a medição das métricas de QoS. O único valor possível ao final de joining é group. (Ao atingir o tempo limite em joining, a reserva é removida.) O valor episode é definido após uma falha no estágio “evaluation” em todos os membros do episódio de inicialização que não falharam durante joining ou measuring.
- Se memberInitialization estiver definido e o membro tiver sido adicionado com “initialize”: true, isso será definido como o episódio de inicialização do qual o membro participará. O valor 1 é usado para os membros adicionados a uma nova sessão no momento da criação. É removido quando o episódio de inicialização termina.
- O atributo next representa o valor de índice do próximo membro na sessão. Ele terá o mesmo valor do atributo next no objeto membersInfo abaixo se não houver mais membros a adicionar.
Sessão do XBOX Cloud Compute (preterida)
Uma sessão do XBOX Cloud Compute contém a lista ordenada de cadeias de conexão, sem diferenciação de maiúsculas e minúsculas, que a sessão pode usar para se conectar a um servidor de jogo. Geralmente, os títulos devem usar a primeira cadeia da lista, mas títulos sofisticados podem usar um mecanismo personalizado para escolher uma das outras (por exemplo, com base na carga).Sessão bruta e propriedades personalizadas do título
Uma sessão pode ser usada para armazenar informações administrativas personalizadas (metadados) sobre um jogo multijogador. Os dados do jogo ou as informações salvas devem ser armazenados no TMS++.Recipientes de propriedades
Cada um dos objetos acima marcados como recipiente de propriedades consiste em dois objetos internos opcionais, system e custom. Os objetos custom podem conter qualquer JSON.Expiração de membros ativos
Os membros ativos são marcados automaticamente como inativos quando o MPSD detecta que o usuário não está mais envolvido com o título. Isso pode acontecer, por exemplo, se a Presença atingir o tempo limite do registro do usuário. Esse mecanismo é apenas uma salvaguarda; ou seja, os títulos ainda são obrigados a marcar proativamente os membros como inativos (ou removê-los da sessão) quando os membros saem ou alternam para fora do título, se desconectam ou deixam de estar envolvidos de alguma outra forma.Perguntas frequentes e solução de problemas
Como faço para chamar o MPSD?
Usando autenticação por certificado: client-sessiondirectory.xboxlive.com Exemplo:Como descubro qual SCID, modelo de sessão e sandbox devo usar?
Essas informações podem ser encontradas no Partner Center para o seu título. Se você ainda não tiver acesso ao Partner Center, entre em contato com seu gerente de conta de desenvolvedor, que poderá ajudar a obter as informações para você.Existe um exemplo de corpo de solicitação com o qual eu possa comparar o meu?
Estou recebendo um erro 404 ao chamar o MPSD.
Colete rastreamentos do Fiddler para obter mais informações e, em seguida, faça o seguinte:-
Verifique a mensagem retornada como parte do corpo de HttpResponse em busca de mensagens 404 comuns:
- The requested service config is either invalid or not configured for sessions. Verifique se o SCID que está sendo usado está correto.
- The requested session wasn’t found. Verifique se a sessão foi criada e se o modelo de sessão está correto antes de recuperá-la. Você pode criar uma sessão com uma chamada PUT.
- Verifique o URI que você está usando.
- Reinicie o console e/ou tente novamente com um novo usuário.
Estou recebendo um erro 403 ao chamar o MPSD.
Geralmente, isso é um problema de permissões ou de escopo. Colete rastreamentos do Fiddler para obter mais informações e, em seguida, faça o seguinte:- Verifique as mensagens retornadas como parte do corpo de HttpResponse em busca de mensagens 403 comuns:
-
*The requested service config cannot be accessed. *
- Verifique se você está usando uma conta que tem acesso à sandbox.
- Verifique se você está na sandbox correta.
- Se você estiver usando autenticação por certificado e receber esse erro, entre em contato com seu DAM.
-
The requested session cannot be accessed. Private Sessions can only be read by members of the session.
- Você está tentando acessar uma sessão com visibilidade “private”. Somente os membros da sessão podem ler o documento de sessão.
-
The request body can’t contain existing member references unless the authentication principal includes a server.
- Você não pode fazer outro usuário entrar em uma sessão em nome de um usuário. Você só pode convidar. Defina o índice como “
reserve_<number>” para convidar um jogador.
- Você não pode fazer outro usuário entrar em uma sessão em nome de um usuário. Você só pode convidar. Defina o índice como “
