Como funciona la configuración de Polling en AJAX

             

Entrando en la pestaña de Servicio dentro del propio menú de ajustes del Hub, podemos encontrar una serie da parámetros.

https://support.visiotechsecurity.com/attachments/token/pQ5EKz6ZdCmTlf0dmttpw39Lp/?name=inline562414849.png
Este parámetro significa que, tras haber confirmado la pérdida de conexión con el Hub, la nube envía un fallo del Polling, pero esperará 30 segundos antes de comunicar dicha pérdida de conexión a quienes estén conectados al Hub (usuarios básicos, usuarios PRO y CRA).
https://support.visiotechsecurity.com/attachments/token/1YH5V3c6wuTJt042iAXoDgvdl/?name=inline-1942715592.png
Este parámetro regula la determinación del fallo del Polling.

El Hub de AJAX siempre va a enviar 3 pings de Polling, y en este apartado podemos configurar el intervalo de tiempo que queremos que haya entre cada ping hacia la nube. Si transcurrido esos 3 pings no ha habido comunicación, se determina el fallo de Polling.

Entonces, si configuramos 30 segundos de retardo de alarma en el primer parámetro descrito, la nube hará lo siguiente:

- enviará 3 paquetes, 1 cada 10 segundos, para confirmar la pérdida de conexión (tal y como se configura en el segundo parámetro)

- tras el último ping enviado y sin respuesta, esperará otros 30 segundos antes de enviar la notificación de perdida de conexión (tal y como se configura en el primer parámetro). Si en ese tiempo la nube vuelve a recibir ping, NO enviará la notificación de fallo de Polling.

Por tanto, ¿cuánto tiempo se tardará en recibir el aviso de pérdida de conexión?

Con los parámetros configurados, la respuesta es: (10 x 3) + 30 = 60 segundo

El lector ya habrá entendido que en la pestaña de "Servicio" el orden de estos ajustes está como invertido, es decir, el primero que aparece es el tiempo de retraso tras la pérdida de los pings, mientras que el segundo parámetro que aparece está relacionado con el tiempo entre los pings --> cronológicamente estos tiempos se aplican al revés con respecto a su orden de aparición en el menú que acabamos de analizar.  
COMENTARIO ADICIONAL
Sabiendo todo esto queremos diferenciar esta notificación (objeto del artículo) y el evento E602; este último evento es el test periódico del Hub que confirma su correcta comunicación con la nube. 

 

Este test periódico depende del tipo de conexión que se establece entre el Hub y la CRA:

- Conexión a través de nube: 15 minutos, no configurable (solicitud de supervisión desde   Compañías de   Seguridad ).

- Conexión directa + nube: configurable desde 1 minuto hasta 24 horas en  Centro de Supervisión.

https://support.visiotechsecurity.com/attachments/token/dMJiyhY3BMOJ0nTgW4KYftBvB/?name=inline-317367977.png

El test periódico describe el estado de la comunicación del mismo Hub, y es de interés únicamente para la CRA.
Por otro lado, la señal de Polling fallido describe el estado de la conexión entre Hub y nube, y eventualmente produce una notificación que llega tanto a las apps como a la CRA (Evento E350).

 

En resumen:

- El test periódico (E602) confirma la conexión entre Hub y nube.

- La pérdida de Polling (E350) notifica la conexión fallida entre Hub y nube.