Saltar al contenido principal

​
¿Qué es una desconexión?

Establecer una conexión con las API de streaming implica realizar una solicitud HTTPS de larga duración y procesar la respuesta de forma incremental. Al conectarte al endpoint de flujo filtrado, debes enviar una solicitud HTTPS y consumir el flujo resultante durante el mayor tiempo posible. Nuestros servidores mantendrán la conexión abierta indefinidamente, salvo que se produzca 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 streaming podría desconectarse

El stream puede desconectarse por varias razones. Revisa el mensaje de error devuelto por el stream para entender el motivo de la falla. Las posibles causas de desconexión son las siguientes:
  • Un error de Autenticación (como un token incorrecto o un método de autenticación inadecuado).
  • Se reinicia un servidor de streaming en X. Esto suele estar relacionado con un despliegue de código y, en general, debería anticiparse y considerarse en el diseño.
  • Tu cliente no alcanza a procesar el volumen de Posts que entrega el stream o lee data demasiado lentamente. Cada conexión de streaming está respaldada por una cola de mensajes que se envían al cliente. Si esta cola crece demasiado con el tiempo, la conexión se cerrará.
  • Tu cuenta superó tu cuota diaria/mensual de Posts.
  • Tienes demasiadas conexiones redundantes activas.
  • Un cliente deja de leer data de forma repentina. Si la tasa de Posts leídos del stream cae bruscamente, la conexión se cerrará.
  • Posibles problemas de red entre el servidor y el cliente.
  • Un problema temporal del lado del servidor, mantenimiento o actualizaciones programadas. (Consulta la página de estado)  

​
Los errores de desconexión más comunes incluyen:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Esta transmisión se ha desconectado en el origen por motivos operativos.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

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

​
Anticipar desconexiones y reconexiones

Al transmitir Posts, el objetivo es mantenerse conectado el mayor tiempo posible, reconociendo que pueden ocurrir desconexiones. El endpoint envía un keep-alive de 20 segundos (aparecerá como un carácter de nueva línea). Use esta señal para detectar si se está desconectando.
  1. Su código debe detectar cuándo dejan de llegar contenido nuevo y la señal de keep-alive.
  2. Si eso sucede, su código debe activar la lógica de reconexión. Algunos clientes y lenguajes permiten especificar un tiempo de espera de lectura, que puede configurar en 20 segundos.
  3. Su servicio debe detectar estas desconexiones y reconectarse lo antes posible.
Una vez que una conexión establecida se cae, intente reconectarse de inmediato. Si la reconexión falla, reduzca el ritmo de los intentos según el tipo de error experimentado:
  • Aplique backoff lineal para errores de red a nivel TCP/IP. Estos problemas suelen ser temporales y tienden a resolverse rápidamente. Aumente el retraso entre reconexiones en 250 ms en cada intento, hasta 16 segundos.
  • Aplique backoff exponencial para errores HTTP en los que sea apropiado reconectar. Comience con una espera de 5 segundos y duplíquela en cada intento, hasta 320 segundos.
  • Aplique backoff exponencial para errores HTTP 429 (límite de frecuencia excedido). Comience con una espera de 1 minuto y duplíquela en cada intento. Tenga en cuenta que cada HTTP 429 recibido aumenta el tiempo que debe esperar hasta que el límite de frecuencia deje de aplicarse a su cuenta.  

​
Recuperación de datos perdidos

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

​
Límites de frecuencia y uso

Para consultar los límites de conexión, la respuesta incluirá tres encabezados. Esto resulta útil para entender cuántas veces puedes usar el endpoint de reglas y cuántos intentos de reconexión están permitidos para el endpoint de streaming.
  • x-rate-limit-limit indica la cantidad de solicitudes asignadas que tu cliente puede realizar durante una ventana de 15 minutos.
  • x-rate-limit-remaining indica la cantidad de solicitudes realizadas hasta el momento en esa 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 flujo filtrado actualmente no reporta datos de uso. Para verificar cuántos Posts se han entregado, tu 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 cliente del flujo simplemente inserta los Posts entrantes en una cola de primero en entrar, primero en salir (FIFO), o en 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, puedes implementar un servicio que escale de manera eficiente si los volúmenes de Posts entrantes cambian drásticamente. Conceptualmente, puedes pensar en ello como descargar un archivo de longitud infinita sobre HTTP.

​
Mejores prácticas de reconexión

Pruebe estrategias de backoff Una buena manera de probar una implementación de backoff es usar credenciales de autorización no válidas y examinar los intentos de reconexión. Una buena implementación no debería recibir respuestas 429. Genere alertas ante múltiples reconexiones Si un cliente alcanza su umbral superior del tiempo entre reconexiones, debe enviarle notificaciones para que pueda investigar y priorizar los problemas que afectan su conexión. Gestione cambios de DNS Verifique que su proceso de cliente respete el TTL (Time To Live) de DNS. Algunas pilas de red almacenan en caché una dirección resuelta durante toda la ejecución del proceso y no recogen cambios de DNS dentro del TTL establecido. Un almacenamiento en caché tan agresivo provocará interrupciones del servicio en su cliente a medida que X distribuye la carga entre direcciones IP. User Agent Asegúrese de que el encabezado HTTP user-agent incluya la versión del cliente. Esto será fundamental para diagnosticar problemas del lado de X. Si su entorno impide configurar el campo user-agent, configure un encabezado x-user-agent.