Terminologia da limitação de taxa refinada
Uso justo
O XBOX acredita que cada usuário deve ter a mesma experiência de alta qualidade, independentemente do jogo (ou aplicativo) que esteja usando. A limitação de taxa refinada (FGRL) resolve o seguinte cenário: O desenvolvedor A acabou de lançar um título que segue todas as práticas recomendadas dos serviços do XBOX, garantindo o uso ideal dos serviços, enquanto o desenvolvedor B também acabou de lançar um título, mas este tem um bug desconhecido. Esse bug faz com que o título e cada usuário enviem chamadas em excesso ao serviço de presença, o que coloca o serviço sob carga intensa. O serviço fica lento e, por fim, para, prejudicando a experiência dos usuários do desenvolvedor A, embora o problema tenha sido causado pelo bug do desenvolvedor B. Se a FGRL estivesse implementada, o serviço teria conseguido parar de receber requisições do título com mau comportamento, permitindo atender ao título do desenvolvedor A com sua fatia justa dos recursos.Granularidade por título e usuário
O título e o usuário foram escolhidos como chave para garantir o uso justo dos recursos do XBOX. Acompanhar apenas o usuário criaria um cenário em que a experiência do usuário ficaria à mercê da integração de cada título. Por exemplo, a maioria dos títulos já usa o serviço People; portanto, para fins deste exemplo, suponha que a limitação de taxa refinada tenha sido configurada no serviço People, permitindo no máximo 100 requisições em 5 minutos. Se um usuário jogasse um jogo que fizesse 100 requisições em 1 minuto, o limite seria excedido e o usuário não conseguiria fazer mais requisições ao serviço People; imagine que, nesse mesmo período, o usuário volte à tela inicial e clique na lista de amigos: como o usuário já teria excedido o limite, essa chamada da lista de amigos falharia até que o intervalo de 5 minutos passasse, mesmo que a tela inicial não tivesse sido responsável por colocar o usuário no estado limitado. Por outro lado, limitar com base apenas no título produziria um resultado igualmente injusto. Definir um limite por título ignoraria a popularidade dos títulos, e as requisições seriam atendidas por ordem de chegada até que um limite fosse atingido. O pareamento de usuário e título garante que nenhum título use mais recursos do que o adequado para o número de usuários ativos, ao mesmo tempo em que dá a cada usuário uma fatia consistente dos recursos.
- Se a requisição estiver abaixo do limite, ela será processada normalmente.
- Se a requisição estiver no limite ou acima dele, os serviços a descartarão e retornarão uma resposta 429.
Limites de pico e sustentados
Tradicionalmente, a limitação de taxa consiste em um limite por ponto de extremidade, acompanhado durante um determinado período. Esse período representa o tempo durante o qual a contagem de requisições de uma entidade é acompanhada. Ao final do período, a contagem da entidade é redefinida para 0 para recomeçar o acompanhamento. Essa abordagem funciona para a maioria das APIs; no entanto, ela não era resiliente o suficiente para jogos e aplicativos que chamam os serviços do XBOX. A solução acima pressupõe que as chamadas sejam feitas de maneira consistente, estável e previsível. No caso dos serviços do XBOX, dependendo do serviço e do título solicitante, os padrões de chamada são drasticamente diferentes. Escolher apenas um limite nesse caso exigiria fazer concessões nas duas extremidades do espectro de padrões de chamada. A solução dos serviços do XBOX usa dois períodos e dois limites. O período menor é chamado de período de pico (Burst), enquanto o maior e mais longo é conhecido como período sustentado (Sustain). O período de pico da FGRL é sempre de 15 segundos, enquanto o sustentado é sempre de 300 segundos (5 minutos). Portanto, durante um período sustentado de 5 minutos, há 20 períodos de pico. Os limites de pico e sustentado são acompanhados ao mesmo tempo e, portanto, contam as requisições ao mesmo tempo. Tanto o limite de pico quanto o sustentado são definidos no serviço, o que significa que cada serviço tem sua própria contagem de pico e sustentada. Para ajudar você a entender como esses dois limites funcionam juntos, a tabela abaixo mostra um usuário jogando um título que está fazendo várias requisições a um serviço que implementou a FGRL. Neste caso, o limite de pico é de 30 requisições em 15 segundos, e o limite sustentado é de 100 requisições em 5 minutos.
A tabela mostra que, nos primeiros 15 segundos, o usuário atinge o limite de pico ao fazer 35 requisições.
Essas 5 requisições extras são descartadas e 5 respostas 429 são enviadas.
Essas 5 requisições, embora limitadas, ainda contam para o limite sustentado.
Depois que qualquer um dos limites é atingido, nenhuma requisição é aceita, como mostrado quando ambos os limites são atingidos na marca de 45 segundos e novamente quando apenas 4 requisições são feitas na marca de 285 segundos.
Objeto de resposta HTTP 429
Quando a contagem associada ao usuário e ao título está no limite de pico ou sustentado, ou acima dele, o serviço não trata a requisição e retorna uma resposta HTTP 429. Ao usar a XSAPI, isso equivale a um HRESULT de 0x801901AD. O código HTTP 429 significa “too many requests” (requisições demais) e será acompanhado por um cabeçalho que contém um valor de “repetir após X segundos”. Um objeto de resposta 429 da FGRL contém um cabeçalho “retry after”, que especifica quanto tempo as entidades chamadoras devem aguardar antes de tentar novamente. Os desenvolvedores que usam a XSAPI não precisam se preocupar, pois a XSAPI respeita e trata o cabeçalho Retry-After. A resposta real conterá os seguintes campos:Limites implementados
Os serviços a seguir implementaram limites de FGRL, com a aplicação desses limites em vigor desde maio de 2016. Esses limites são os mesmos em todas as áreas restritas e títulos. Qualquer título publicado pela XBOX Developer Platform ou pelo Partner Center e lançado antes de maio de 2016 será considerado herdado e, portanto, isento.
A tabela acima representa a lista atual de serviços selecionados para a FGRL.
Essa lista não é definitiva, pois novos serviços e serviços existentes podem ser adicionados.
Quando um serviço for adicionado, esta tabela será atualizada e um anúncio será feito.
Os limites da tabela podem ser alterados.
À medida que os serviços mudam e evoluem, os limites também mudarão; no entanto, você será notificado e as isenções herdadas necessárias serão feitas.
Mapeamento de serviços e efeitos da limitação de taxa nos títulos
OBSERVAÇÃO: o mapeamento de API mais recente é atualizado regularmente e pode ser encontrado em Live Trace Analyzer API Mapping.