Saltar al contenido principal

​
¿Qué es una desconexión?

Establecer una conexión con las APIs de streaming implica realizar una solicitud HTTPS de muy larga duración y analizar la respuesta de forma incremental. Al conectarte al endpoint powerstream, debes realizar una solicitud HTTPS y consumir el flujo resultante durante tanto tiempo como sea práctico. Nuestros servidores mantendrán la conexión abierta indefinidamente, salvo error del lado del servidor, 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 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

Tu stream puede desconectarse por varios motivos. Revisa el mensaje de error devuelto por el stream para entender la causa del fallo. Los posibles motivos de desconexión son los siguientes:
  • Un error de autenticación (como usar 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, debe esperarse y contemplarse en el diseño.
  • Tu cliente no puede mantenerse al ritmo del 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 enviarán al cliente. Si esta cola crece demasiado con el tiempo, la conexión se cerrará.
  • Tu cuenta superó tu cuota diaria/mensual de Publicaciones.
  • Tienes demasiadas conexiones redundantes activas.
  • Un cliente deja de leer datos de repente. Si la tasa de Publicaciones que se leen del stream cae de forma repentina, la conexión se cerrará.
  • Posibles problemas de red entre el servidor y el cliente.
  • Un problema temporal del lado del servidor, tareas de mantenimiento programadas y actualizaciones. (Consulta la página de estado)

​
Anticiparse a las desconexiones y reconectarse

Al transmitir Publicaciones en streaming, el objetivo es permanecer conectado el mayor tiempo posible, reconociendo que pueden producirse desconexiones. El endpoint proporciona una señal de keep-alive 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 tanto contenido nuevo como la señal de keep-alive.
  2. Si eso sucede, tu código debe activar una lógica de reconexión. Algunos clientes y lenguajes te permiten especificar un tiempo de espera de lectura (read timeout), que puedes configurar en 20 segundos.
  3. Tu servicio debe detectar estas desconexiones y reconectarse tan pronto como sea posible.
Una vez que una conexión establecida se interrumpe, intenta reconectarte inmediatamente. Si la reconexión falla, reduce la frecuencia de tus intentos de reconexión según el tipo de error experimentado:
  • Aplica un backoff lineal para los errores de red a nivel TCP/IP. Estos problemas suelen ser temporales y tienden a resolverse rápidamente. Aumenta el retraso entre reconexiones en 250 ms en cada intento, hasta 16 segundos.
  • Aplica un backoff exponencial para los errores HTTP para los cuales sea apropiado reconectar. Comienza con una espera de 5 segundos, duplicando cada intento, hasta 320 segundos.
  • Aplica un backoff exponencial para los errores HTTP 429 “Rate limit exceeded”. Comienza con una espera de 1 minuto y duplícala en cada intento. Ten en cuenta que cada HTTP 429 recibido aumenta el tiempo que debes esperar hasta que el límite de uso deje de aplicarse a tu cuenta.  

​
Recuperar datos perdidos

Si se produce 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 consultar 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 están permitidos 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 filtro de stream actualmente no informa 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.  El código que aloja el lado del cliente del stream simplemente inserta las Publicaciones entrantes en una cola FIFO (first in, first out), o en una estructura de memoria similar; un proceso/hilo separado debe consumir las Publicaciones de esa cola para analizarlas y preparar el contenido para su almacenamiento. Con este diseño, puedes implementar un servicio que pueda escalar de forma eficiente en caso de que el volumen de Publicaciones entrantes cambie drásticamente. Conceptualmente, puedes pensar en ello como descargar un archivo infinitamente largo a través de HTTP.

​
Buenas prácticas de reconexión

​
Probar estrategias de backoff

Una buena forma 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 ninguna respuesta 429.

​
Alertas de incidencias por múltiples reconexiones

Si un Client alcanza su umbral máximo de tiempo entre reconexiones, debería enviarte notificaciones para que puedas priorizar los problemas que afectan a tu conexión.

​
Gestionar cambios de DNS

Comprueba que el proceso de tu cliente respeta el valor de Time To Live (TTL) de DNS. Algunos stacks de red almacenan en caché una dirección resuelta durante toda la duración del proceso y no recogen los cambios de DNS dentro del TTL establecido. Un almacenamiento en caché tan agresivo provocará interrupciones de servicio en tu cliente cuando X redistribuya la carga entre direcciones IP.

​
User Agent

Asegúrate de que el encabezado HTTP user-agent incluya la versión del Client. Esto será fundamental para diagnosticar problemas del lado de X. Si tu entorno no permite establecer el campo user-agent, configura entonces un encabezado x-user-agent.