Pular para o conteúdo principal

​
O que é uma desconexão?

Estabelecer uma conexão com as APIs de streaming significa fazer uma requisição HTTPS de longa duração e processar a resposta de forma incremental. Ao se conectar ao endpoint do stream filtrado, você deve enviar uma requisição HTTPS e consumir o stream resultante pelo maior tempo possível. Nossos servidores manterão a conexão aberta indefinidamente, salvo erro no servidor, atraso excessivo do lado do cliente, problemas de rede, manutenção rotineira do servidor ou logins duplicados. Em conexões com endpoints de streaming, é provável — e deve ser esperado — que ocorram desconexões, sendo necessário implementar lógica de reconexão.  

​
Por que uma conexão de streaming pode ser desconectada

Seu stream pode se desconectar por vários motivos. Verifique a mensagem de erro retornada pelo stream para entender a causa da falha. Possíveis motivos para desconexões incluem:
  • Erro de autenticação (como um token incorreto ou o uso de um método de autenticação incorreto).
  • Reinício de um servidor de streaming no lado da X. Isso geralmente está relacionado a uma implantação de código e, em geral, deve ser esperado e considerado no design da solução.
  • Seu cliente não está acompanhando o volume de Posts que o stream está entregando ou está lendo dados muito lentamente. Toda conexão de streaming é sustentada por uma fila de mensagens a serem enviadas ao cliente. Se essa fila crescer demais ao longo do tempo, a conexão será encerrada.
  • Sua conta excedeu sua cota diária/mensal de Posts.
  • Há muitas conexões redundantes ativas.
  • O cliente para de ler dados de repente. Se a taxa de Posts lidos do stream cair repentinamente, a conexão será encerrada.
  • Possíveis problemas de rede entre servidor e cliente.
  • Um problema temporário no lado do servidor, manutenção ou atualizações programadas. (Verifique a página de status)  

​
Erros de desconexão comuns incluem:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Este stream foi desconectado upstream por razões operacionais.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "Este stream está atualmente no limite máximo de conexões permitidas.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Antecipando desconexões e reconexões

Ao fazer stream de Posts, o objetivo é permanecer conectado pelo maior tempo possível, reconhecendo que desconexões podem ocorrer. O endpoint fornece um sinal de keep-alive a cada 20 segundos (aparece como um caractere de nova linha). Use esse sinal para detectar se você está sendo desconectado.
  1. Seu código deve detectar quando o conteúdo novo e o keep-alive deixam de chegar.
  2. Se isso acontecer, seu código deve acionar a lógica de reconexão. Alguns clientes e linguagens permitem definir um tempo limite de leitura, que você pode configurar para 20 segundos.
  3. Seu serviço deve detectar essas desconexões e se reconectar assim que possível.
Quando uma conexão estabelecida cair, tente reconectar imediatamente. Se a reconexão falhar, reduza a frequência das tentativas conforme o tipo de erro encontrado:
  • Faça backoff linear para erros de rede no nível TCP/IP. Esses problemas geralmente são temporários e tendem a se resolver rapidamente. Aumente o atraso entre reconexões em 250 ms a cada tentativa, até 16 segundos.
  • Faça backoff exponencial para erros HTTP em que a reconexão seja apropriada. Comece com uma espera de 5 segundos, dobrando a cada tentativa, até 320 segundos.
  • Faça backoff exponencial para erros HTTP 429 (Rate limit exceeded). Comece com uma espera de 1 minuto e dobre a cada tentativa. Observe que cada HTTP 429 recebido aumenta o tempo que você deve aguardar até que o limite de taxa deixe de vigorar para sua conta.  

​
Recuperando dados perdidos

Se você passar por uma desconexão, há diferentes estratégias que podem ajudar a garantir que você receba todos os dados que possam ter sido perdidos. Documentamos etapas essenciais para recuperar dados perdidos no nosso guia de integração sobre recuperação de dados.   

​
Limites de requisições e uso

Para verificar os limites de conexão, a resposta retornará três cabeçalhos. Isso é útil para entender quantas vezes você pode usar o endpoint de regras e quantas tentativas de reconexão são permitidas para o endpoint de streaming.
  • x-rate-limit-limit indica o número de requisições alocadas que seu cliente pode fazer durante a janela de 15 minutos.
  • x-rate-limit-remaining indica o número de requisições restantes na janela de 15 minutos até o momento.
  • x-rate-limit-reset é um carimbo de data/hora UNIX indicando quando a janela de 15 minutos será reiniciada, redefinindo x-rate-limit-remaining para 0.
O endpoint de stream de filtro atualmente não reporta dados de uso. Para verificar quantos Posts foram entregues, seu código pode implementar uma lógica de medição, de modo que o consumo possa ser mensurado e pausado, se necessário. O código que hospeda o lado cliente do stream simplesmente insere os Posts recebidos em uma fila first in, first out (FIFO) ou em estrutura de memória similar; um processo/thread separado deve consumir os Posts dessa fila para analisar e preparar o conteúdo para armazenamento. Com esse design, você pode implementar um serviço que escale com eficiência caso os volumes de Posts recebidos mudem drasticamente. Conceitualmente, você pode pensar nisso como baixar um arquivo infinitamente longo via HTTP.

​
Melhores práticas de reconexão

Teste estratégias de backoff Uma boa maneira de testar uma implementação de backoff é usar credenciais de autorização inválidas e analisar as tentativas de reconexão. Uma boa implementação não deve receber respostas 429. Emita alertas para múltiplas reconexões Se um cliente atingir o limite máximo do intervalo entre reconexões, ele deve enviar notificações para que você possa priorizar e tratar os problemas que afetam sua conexão. Trate alterações de DNS Teste se o processo do seu cliente respeita o Time To Live (TTL) do DNS. Algumas stacks vão armazenar em cache um endereço resolvido por toda a duração do processo e não captarão alterações de DNS dentro do TTL estabelecido. Esse cache agressivo levará a interrupções de serviço no seu cliente à medida que a X distribui a carga entre endereços IP. User Agent Garanta que o cabeçalho HTTP user-agent inclua a versão do cliente. Isso será crucial para diagnosticar problemas no lado da X. Se o seu ambiente impedir a definição do campo user-agent, então defina um cabeçalho x-user-agent.
⌘I