Saltar al contenido principal

​
¿Qué es una desconexión?

Establecer una conexión con las APIs de streaming implica realizar una solicitud HTTPS de larga duración y procesar la respuesta de forma incremental. Al conectarte al endpoint de filtered stream, 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 error del lado del servidor, una latencia excesiva del lado del cliente, problemas de red, mantenimiento rutinario del servidor o inicios de sesión duplicados. Con las conexiones a endpoints de streaming, es probable, y es de esperar, que se produzcan desconexiones y que se implemente lógica de reconexión.  

​
Por qué una conexión de streaming puede desconectarse

Tu stream puede desconectarse por varias razones. Revisa el mensaje de error que devuelve el stream para entender el motivo del fallo. Las posibles razones de desconexión son las siguientes:
  • Un error de autenticación (como un token incorrecto o un método de autenticación equivocado).
  • Se reinicia un servidor de streaming en el lado de X. Esto suele estar relacionado con un despliegue de código y, en general, debería esperarse y contemplarse en el diseño.
  • Tu cliente no está manteniendo el ritmo con el volumen de Publicaciones que el stream está entregando o está leyendo los datos 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 excedió tu cuota diaria/mensual de Publicaciones.
  • Tienes demasiadas conexiones redundantes activas.
  • Un cliente deja de leer datos de forma repentina. Si la tasa de Publicaciones que se leen del stream cae de repente, la conexión se cerrará.
  • Posibles problemas de red entre el servidor y el cliente.
  • Un problema temporal del lado del servidor, mantenimiento programado y actualizaciones. (Consulta la página de estado)  

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

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "This stream has been disconnected upstream for operational reasons.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "This stream is currently at the maximum allowed connection limit.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Anticipar desconexiones y volver a conectar

Cuando transmites Publicaciones, el objetivo es permanecer conectado el mayor tiempo posible, reconociendo que pueden producirse desconexiones. El endpoint proporciona una señal de keep-alive de 20 segundos (aparecerá como un carácter de nueva línea). Usa esta señal para detectar si estás siendo desconectado.
  1. Tu código debe detectar cuándo dejan de llegar contenido nuevo y la señal de keep-alive.
  2. Si eso ocurre, tu código debe activar una lógica de reconexión. Algunos clientes y lenguajes te permiten especificar un tiempo de espera de lectura, que puedes configurar en 20 segundos.
  3. Tu servicio debe detectar estas desconexiones y volver a conectar tan pronto como sea posible.
Una vez que una conexión establecida se interrumpe, intenta reconectar de inmediato. Si la reconexión falla, reduce la frecuencia de tus intentos de reconexión según el tipo de error experimentado:
  • Aumenta el intervalo de forma lineal para 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.
  • Aumenta el intervalo de forma exponencial para los errores HTTP para los que sea apropiado volver a conectar. Comienza con una espera de 5 segundos, duplicando en cada intento, hasta 320 segundos.
  • Aumenta el intervalo de forma exponencial para errores HTTP 429 (Rate limit exceeded). Comienza con una espera de 1 minuto y duplica en cada intento. Ten en cuenta que cada HTTP 429 recibido incrementa el tiempo que debes esperar hasta que el límite de frecuencia deje de estar en efecto para tu cuenta.  

​
Recuperar datos perdidos

Si llegas a experimentar una desconexión, hay distintas estrategias que puedes usar para asegurarte de recibir todos los datos que es posible que te hayas perdido. Hemos documentado algunos pasos clave que puedes seguir para recuperar esos datos en nuestra guía de integración sobre la 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 puedes usar el endpoint de reglas y cuántos intentos de reconexión se permiten para el endpoint de streaming.
  • x-rate-limit-limit indica el número de solicitudes asignadas que tu cliente puede realizar durante la ventana de 15 minutos.
  • x-rate-limit-remaining indica el número 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 filtrado actualmente no expone datos de uso. Para comprobar cuántas Publicaciones 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.  Tu código que aloja el lado del cliente del stream simplemente inserta las Publicaciones entrantes en una cola FIFO (primero en entrar, primero en salir) o una estructura de memoria similar; un proceso/hilo separado debería consumir Publicaciones de esa cola para analizarlas y preparar el contenido para su almacenamiento. Con este diseño, puedes implementar un servicio que escale de forma eficiente en caso de que los volúmenes de Publicaciones entrantes varíen drásticamente. Conceptualmente, puedes pensar en ello como descargar un archivo infinitamente largo a través de HTTP.

​
Mejores prácticas de reconexión

Pruebe las estrategias de backoff Una buena manera de probar una implementación de backoff es usar credenciales de autorización inválidas y examinar los intentos de reconexión. Una buena implementación no debería recibir respuestas 429. Genere alertas para múltiples reconexiones Si un cliente alcanza su umbral máximo de tiempo entre reconexiones, debería enviarle notificaciones para que pueda evaluar los problemas que afectan su conexión. Gestione los cambios de DNS Pruebe que el proceso de su cliente respete el valor de Time To Live (TTL) de DNS. Algunas pilas almacenarán en caché una dirección resuelta durante toda la vida del proceso y no aplicarán los cambios de DNS dentro del TTL establecido. Un almacenamiento en caché tan agresivo provocará interrupciones del servicio en su cliente a medida que X redistribuya la carga entre direcciones IP. User Agent Asegúrese de que su 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, entonces establezca un encabezado x-user-agent.