La fiabilité du réseau a toujours été une priorité dans l’architecture client/serveur de 4D. Avec 4D 21 R4, nous allons encore plus loin : les applications 4D à distance peuvent désormais gérer de manière transparente de brèves interruptions réseau, sans fermer la session de l’utilisateur ni nécessiter aucune intervention manuelle.

Le problème que nous résolvons

Les perturbations réseau font partie intégrante des déploiements en environnement réel. Entre un poste de travail client 4D et un serveur 4D, il peut y avoir de nombreux périphériques réseau (commutateurs, routeurs, pare-feu, passerelles VPN, etc.) et n’importe lequel d’entre eux peut rendre les deux pairs temporairement inaccessibles l’un à l’autre : un commutateur qui redémarre, un câble débranché puis rebranché, un problème de routage passager quelque part sur le chemin. Ces événements ne durent généralement que quelques minutes, mais ils peuvent tout de même rendre les pairs mutuellement inaccessibles.

Fonctionnement

Cette fonctionnalité s’appuie sur la couche de transport QUIC de la communication client/serveur de 4D. QUIC est par nature sans connexion (il fonctionne sur UDP), ce qui signifie qu’il peut naturellement tolérer des périodes de silence entre les pairs sans interrompre la session. Lorsque 4D Server détecte qu’une application 4D distante est devenue inaccessible, il ne ferme plus immédiatement la session. Au lieu de cela, il la maintient active et attend que la communication reprenne.

La durée de cette fenêtre de maintien est contrôlée par un nouveau paramètre de base de données : le délai d’expiration de la session QUIC (sélecteur 135). La valeur par défaut est de 900 secondes (15 minutes), avec un minimum de 60 secondes. Vous le configurez côté serveur, et il s’applique à toutes les nouvelles sessions ouvertes à partir de ce moment-là.

// 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)

Remarque : la modification de cette valeur n’affecte que les nouvelles sessions. Les sessions existantes conservent la valeur qui leur a été attribuée lors de leur ouverture.

Que se passe-t-il lorsqu’un pair devient inaccessible ?

Du côté serveur, dès que la couche QUIC signale qu’une application 4D distante est injoignable, la fenêtre d’administration du serveur affiche le client 4D dans l’état « Injoignable ». La session est maintenue active et un nouvel attribut unreachableSince devient disponible dans l’objet Process activity.sessions[] correspondant au client 4D inaccessible, indiquant le nombre de secondes écoulées depuis le dernier contact.

// 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

Côté client, l’attribut Session.info.unreachableSince commence à compter les secondes écoulées depuis la dernière communication réussie avec le serveur. Au bout de quelques secondes, seules les fenêtres qui communiquent activement avec le serveur affichent le message « Inaccessible » : l’interface est grisée et un message contextuel s’affiche (également sous forme d’info-bulle pour les fenêtres plus petites). Les fenêtres exécutant du code local ne sont pas affectées et restent pleinement utilisables. Les utilisateurs peuvent continuer à travailler sur les parties hors ligne de l’application pendant que la communication est en cours de rétablissement.

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

Lorsque la communication reprend

Si la communication est rétablie avant l’expiration du délai d’attente de la session QUIC, tout reprend de manière transparente.

Côté serveur:

• La fenêtre d’administration du serveur remet le client 4D en état « En ligne ».
• L’attribut « unreachableSince » est supprimé de l’objet Process activity.sessions[] correspondant au client 4D rétabli.

Côté client:

• L’attribut Session.info.unreachableSince est supprimé.
• Toutes les fenêtres concernées retrouvent leur état initial.

L’utilisateur peut ne même pas remarquer qu’il s’est passé quelque chose.

Lorsque le délai d’expiration est dépassé

Si les pairs restent inaccessibles les uns aux autres pendant une durée supérieure au délai d’expiration défini, la session est fermée proprement.

Côté serveur:

• La session client 4D est supprimée.
• Une entrée d’avertissement est consignée dans le journal de diagnostic à des fins de surveillance.

Côté client:

• Une boîte de dialogue explique que la session a été fermée car le serveur était inaccessible, et propose de redémarrer ou de quitter.
• Une notification système s’affiche également, afin que l’utilisateur soit informé même si l’application est en arrière-plan. Le nom et l’icône de l’application sont ceux définis lors de la création de l’application.
  

Cela garantit que, même dans le pire des cas, l’expérience reste fluide et informative.

Découvrez-le en action

La vidéo ci-dessous présente le fonctionnement complet. Elle commence par le comportement hérité utilisant ServerNet, où toute interruption entraîne la fermeture immédiate de la session. Elle présente ensuite le nouveau comportement QUIC à travers deux scénarios :

• La communication est interrompue, puis rétablie avant l’expiration du délai.
• La communication est à nouveau interrompue, mais cette fois-ci, le délai d’expiration est dépassé et la session est fermée.

Cela apporte de nombreux avantages à vos utilisateurs

Aucun codage n’est nécessaire. Aucune configuration à déployer. Il suffit de passer à 4D 21 R4 pour que ce comportement soit disponible dès l’installation, pour tous les utilisateurs du client 4D.

Il ne s’agit pas d’une amélioration mineure : elle résout l’un des problèmes les plus visibles et les plus anciens des déploiements client/serveur 4D. Vos clients s’en sont plaints. C’est désormais terminé.

Et 4D va plus loin que la plupart des autres solutions. Alors que les applications web ne signalent généralement pas aux utilisateurs qu’ils ont perdu l’accès au serveur (ou nécessitent un effort de développement important pour le faire), 4D gère cela de manière transparente et immédiate : les fenêtres concernées sont grisées et accompagnées d’un message clair, les fenêtres non concernées continuent de fonctionner, et tout se rétablit automatiquement dès que la communication reprend. Si votre solution est correctement architecturée pour séparer la logique locale de celle dépendant du serveur, vos utilisateurs peuvent bénéficier d’une expérience en ligne/hors ligne véritablement fluide, sans aucun effort supplémentaire.

C’est exactement pour cette raison que nous avons investi dans QUIC. Pour plus de contexte, lisez notre article expliquant pourquoi nous avons abandonné la couche réseau héritée et regardez la vidéo démontrant la résilience de QUIC par rapport à d’autres couches réseau. Vous pouvez également en savoir plus sur la fonctionnalité de changement de couche réseau présentée précédemment.

Cette fonctionnalité constitue une excellente raison de passer à 4D 21 R4 et d’utiliser QUIC !

---

Vous avez des questions ou des commentaires sur cette fonctionnalité ? Laissez un commentaire ci-dessous ou rendez-vous sur le forum 4D.