Saltar al contenido principal

​
¿Qué es una desconexión?

Establecer una conexión con las API de streaming implica realizar una solicitud HTTPS de muy larga duración y procesar la respuesta de forma incremental. Al conectarte al endpoint de stream filtrado, debes realizar una solicitud HTTPS y consumir el stream resultante durante el mayor tiempo que sea práctico. Nuestros servidores mantendrán la conexión abierta indefinidamente, salvo que haya un error del lado del servidor, un retraso excesivo del lado del cliente, problemas de red, mantenimiento rutinario del servidor o inicios de sesión duplicados. Con conexiones a endpoints de streaming, es probable —y debe esperarse— que se produzcan desconexiones y que se implemente lógica de reconexión.  

​
Por qué una conexión de stream podría desconectarse

Tu stream puede desconectarse por varias razones. Revisa el mensaje de error que devuelve el stream para entender la causa de la falla. Los posibles motivos de desconexión son los siguientes:
  • Un error de autenticación (como un token incorrecto o el uso de un método de autenticación equivocado).
  • Se reinicia un servidor de stream del lado de X. Esto suele estar relacionado con un despliegue de código y, en general, debe preverse y diseñarse en consecuencia.
  • Tu cliente no mantiene el ritmo con el volumen de Posts que entrega el stream o está leyendo data demasiado lentamente. Cada conexión de stream está respaldada por una cola de mensajes que se envían al cliente. Si esta cola crece demasiado con el tiempo, se cerrará la conexión.
  • Tu cuenta superó tu cuota diaria/mensual de Posts.
  • Tienes demasiadas conexiones redundantes activas.
  • Un cliente deja de leer data de repente. Si la tasa de Posts leídos del stream cae repentinamente, se cerrará la conexión.
  • Posibles problemas de red entre el servidor y el cliente.
  • Un problema temporal del lado del servidor, mantenimiento y actualizaciones programadas. (Consulta la página de estado)  

​
Entre los errores de desconexión más comunes se incluyen:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Este stream ha sido desconectado en el origen por razones operativas.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "Este stream ha alcanzado actualmente el límite máximo de conexiones permitidas.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Anticipar desconexiones y reconectar

Al hacer streaming de Posts, el objetivo es mantener la conexión el mayor tiempo posible, reconociendo que pueden ocurrir desconexiones. El endpoint envía un keep-alive con un latido cada 20 segundos (aparecerá como un carácter de nueva línea). Usa esta señal para detectar si te estás desconectando.
  1. Tu código debe detectar cuándo dejan de llegar contenido nuevo y el latido.
  2. Si eso sucede, tu código debe activar una lógica de reconexión. Algunos clientes y lenguajes permiten especificar un tiempo de espera de lectura (read timeout), que puedes establecer en 20 segundos.
  3. Tu servicio debe detectar estas desconexiones y reconectar lo antes posible.
Una vez que una conexión establecida se interrumpe, intenta reconectar de inmediato. Si la reconexión falla, reduce la frecuencia de los intentos según el tipo de error experimentado:
  • Aplica una retirada lineal ante errores de red a nivel TCP/IP. Estos problemas suelen ser temporales y tienden a resolverse rápidamente. Incrementa el retraso entre reconexiones en 250 ms en cada intento, hasta 16 segundos.
  • Aplica una retirada exponencial ante errores HTTP para los cuales reconectar sea apropiado. Comienza con una espera de 5 segundos, duplicando cada intento, hasta 320 segundos.
  • Aplica una retirada exponencial ante errores HTTP 429 Rate limit exceeded. Comienza con una espera de 1 minuto y duplica cada intento. Ten en cuenta que cada HTTP 429 recibido aumenta el tiempo que debes esperar hasta que el límite de tasa deje de estar vigente para tu cuenta.  

​
Recuperación de datos perdidos

Si experimentas una desconexión, hay varias estrategias que puedes usar para asegurarte de recibir todos los datos que podrías haberte perdido. Hemos documentado algunos pasos clave que puedes seguir para recuperar datos perdidos en nuestra guía de integración sobre recuperación de datos.   

​
Límites de tasa y uso

Para comprobar los límites de conexión, la respuesta incluirá tres encabezados. Esto es útil para entender cuántas veces puede usar el endpoint de reglas y cuántos intentos de reconexión están permitidos para el endpoint de stream.
  • x-rate-limit-limit indica la cantidad de solicitudes permitidas que su cliente puede realizar durante la ventana de 15 minutos.
  • x-rate-limit-remaining indica la cantidad de solicitudes realizadas hasta el momento en la ventana de 15 minutos.
  • x-rate-limit-reset es una marca de tiempo UNIX que indica cuándo se reiniciará la ventana de 15 minutos, restableciendo x-rate-limit-remaining a 0.
El endpoint de stream de filtro actualmente no informa datos de uso. Para comprobar cuántos Posts se han entregado, su código puede implementar una lógica de medición, de modo que el consumo pueda medirse y pausarse si es necesario. El código que aloja el lado del cliente del stream simplemente inserta los Posts entrantes en una cola FIFO (primero en entrar, primero en salir) o una estructura de memoria similar; un proceso/hilo independiente debería consumir los Posts de esa cola para analizarlos y preparar el contenido para su almacenamiento. Con este diseño, puede implementar un servicio que escale de manera eficiente en caso de que los volúmenes de Posts entrantes cambien drásticamente. Conceptualmente, puede pensar en ello como descargar un archivo infinitamente largo a través de HTTP.

​
Mejores prácticas de reconexión

Prueba estrategias de backoff Una buena forma de probar una implementación de backoff es usar credenciales de autorización no válidas y observar los intentos de reconexión. Una implementación adecuada no debería recibir respuestas 429. Emite alertas ante múltiples reconexiones Si un cliente alcanza su umbral máximo para el tiempo entre reconexiones, debe enviarte notificaciones para que puedas evaluar y resolver los problemas que afectan tu conexión. Gestiona cambios de DNS Verifica que tu proceso de cliente respete el Time To Live (TTL) de DNS. Algunas pilas almacenarán en caché una dirección resuelta durante toda la ejecución del proceso y no detectarán cambios de DNS dentro del TTL establecido. Un almacenamiento en caché tan agresivo provocará interrupciones del servicio en tu cliente a medida que X redistribuye la carga entre direcciones IP. User Agent Asegúrate de que el encabezado HTTP user-agent incluya la versión del cliente. Esto será fundamental para diagnosticar problemas del lado de X. Si tu entorno impide configurar el campo user-agent, establece entonces un encabezado x-user-agent.
⌘I