La fiabilidad de la red siempre ha sido una prioridad en la arquitectura cliente/servidor de 4D. Con 4D 21 R4, vamos un paso más allá: las aplicaciones 4D remotas ahora pueden gestionar breves interrupciones de red sin problemas, sin cerrar la sesión del usuario ni requerir ninguna intervención manual.

El problema que resolvemos

Las interrupciones de red son algo habitual en las implementaciones del mundo real. Entre una estación de trabajo cliente de 4D y un servidor 4D puede haber muchos dispositivos de red (conmutadores, routers, cortafuegos, pasarelas VPN, etc.) y cualquiera de ellos puede hacer que los dos nodos se vuelvan temporalmente inaccesibles entre sí: el reinicio de un conmutador, un cable que se desconecta y se vuelve a conectar, un problema de enrutamiento transitorio en algún punto de la ruta. Estos incidentes suelen durar solo unos minutos, pero pueden hacer que los nodos se vuelvan mutuamente inaccesibles de todos modos.

Cómo funciona

Esta función se basa en la capa de transporte QUIC que sustenta la comunicación cliente/servidor de 4D. QUIC es, por naturaleza, un protocolo sin conexión (funciona sobre UDP), lo que significa que puede tolerar de forma natural períodos de silencio entre pares sin interrumpir la sesión. Cuando 4D Server detecta que una aplicación 4D remota ha dejado de ser accesible, ya no cierra la sesión de inmediato. En su lugar, la mantiene activa y espera a que se reanude la comunicación.

La duración de este intervalo de espera viene controlada por un nuevo parámetro de la base de datos: el tiempo de espera de la sesión QUIC (selector 135). El valor por defecto es de 900 segundos (15 minutos), con un mínimo de 60 segundos. Se configura en el lado del servidor y se aplica a todas las nuevas sesiones abiertas a partir de ese momento.

// Read the current timeout value
$previousTimeout:= Get database parameter(QUIC session timeout)
// Set a custom timeout window of 10 minutes

SET DATABASE PARAMETER(QUIC session timeout; 600)

Nota: cambiar este valor solo afecta a las nuevas sesiones. Las sesiones existentes conservan el valor que se les asignó al abrirse.

¿Qué ocurre cuando un par deja de ser accesible?

Del lado del servidor, tan pronto como la capa QUIC informa de que una aplicación 4D remota está inaccesible, la ventana de administración del servidor muestra el cliente 4D en estado «Inaccesible». La sesión se mantiene activa y aparece un nuevo atributo unreachableSince en el objeto Process activity.sessions[] correspondiente al cliente 4D inaccesible, que cuenta los segundos transcurridos desde el último contacto.

// On the server — inspect all remote sessions
$processActivity := Process activity(Sessions only)
For each ($session; $processActivity.sessions)
   If ($session.unreachableSince # Null)
LOG EVENT (Into 4D diagnostic log;"Remote "+$session.systemUserName+\
" unreachable for "+String($session.unreachableSince)+"s";\
Information message )
   End if

End for each

Del lado del cliente, el atributo Session.info.unreachableSince comienza a contar los segundos transcurridos desde la última comunicación satisfactoria con el servidor. Solo las ventanas que se están comunicando activamente con el servidor cambian a un estado de «Inaccesible»: la interfaz aparece en gris con un mensaje contextual (que también se muestra como información sobre herramientas en las ventanas más pequeñas). Las ventanas que ejecutan código local no se ven afectadas y siguen siendo totalmente utilizables. Los usuarios pueden seguir trabajando en las partes de la aplicación que funcionan sin conexión mientras se restablece la comunicación.

// On the remote — check how long the server has been unreachable
If (Session.info.unreachableSince # Null)
ALERT ("Servidor inaccesible durante " + String(Session.info.unreachableSince) + "s")
End if

Cuando se restablece la comunicación

Si la comunicación se restablece antes de que expire el tiempo de espera de la sesión QUIC, todo se reanuda de forma transparente.

Del lado del servidor:

• La ventana de administración del servidor vuelve a marcar el cliente 4D como «En línea».
• El atributo «unreachableSince« se elimina del objeto Process activity.sessions[] correspondiente al cliente 4D recuperado.

Del lado cliente:

• Se elimina el atributo Session.info.unreachableSince.
• Todas las ventanas afectadas recuperan su estado anterior.

Es posible que el usuario ni siquiera se dé cuenta de que ha ocurrido algo.

Cuando se supera el tiempo de espera

Si los pares permanecen inaccesibles entre sí durante más tiempo del establecido en el tiempo de espera, la sesión se cierra de forma ordenada.

Del lado del servidor:

• Se elimina la sesión del cliente 4D.
• Se registra una entrada de advertencia en el registro de diagnóstico con fines de supervisión.

Del lado del cliente:

• Un cuadro de diálogo explica que la sesión se ha cerrado porque no se ha podido contactar con el servidor, y ofrece la opción de reiniciar o salir.
• También se muestra una notificación del sistema, de modo que el usuario queda informado incluso si la aplicación se encuentra en segundo plano. El nombre y el icono de la aplicación son los definidos durante la creación de la misma.
  

Esto garantiza que, incluso en el peor de los casos, la experiencia sea clara e informativa.

Véalo en acción

El siguiente vídeo muestra el proceso completo. Comienza con el comportamiento anterior con ServerNet, en el que toda interrupción cierra inmediatamente la sesión. A continuación, muestra el nuevo comportamiento de QUIC en dos escenarios:

• La comunicación se interrumpe y luego se restablece dentro del plazo de espera.
• La comunicación se interrumpe de nuevo, pero esta vez se supera el tiempo de espera y se cierra la sesión.

Esto supone una gran mejora para Sus usuarios

No requiere programación. No hay que realizar ninguna configuración. Basta con actualizar a 4D 21 R4 y este comportamiento estará disponible de forma predeterminada para todos los usuarios del cliente 4D.

No se trata de una mejora menor: resuelve uno de los problemas más evidentes y persistentes en los despliegues cliente/servidor de 4D. Sus clientes se han quejado de ello. Esto se acaba aquí.

Y 4D va más allá que la mayoría. Mientras que las aplicaciones web no suelen indicar a los usuarios que han perdido el acceso al servidor (o requieren un esfuerzo de desarrollo significativo para hacerlo), 4D lo gestiona de forma transparente e inmediata: las ventanas afectadas se atenuaron con un mensaje claro, las no afectadas siguen funcionando y todo se restablece automáticamente cuando se reanuda la comunicación. Si su solución está bien diseñada para separar la lógica local de la que depende del servidor, sus usuarios podrán disfrutar de una experiencia en línea/fuera de línea verdaderamente fluida sin ningún esfuerzo adicional.

Esta es precisamente la razón por la que hemos invertido en QUIC. Para conocer más detalles, lea nuestra entrada sobre por qué hemos dejado atrás la capa de red heredada y mira el vídeo que muestra la resiliencia de QUIC frente a otras capas de red. También puede obtener más información sobre la función de cambio de capa de red presentada anteriormente.

Esta función es una excelente razón para actualizar a 4D 21 R4 y utilizar QUIC.

---

¿Tiene alguna pregunta o comentario sobre esta funcionalidad? Deje un comentario a continuación o contáctenos en el foro 4D.