Die Netzwerkzuverlässigkeit hatte in der Client/Server-Architektur von 4D schon immer höchste Priorität. Mit 4D 21 R4 gehen wir noch einen Schritt weiter: 4D-Anwendungen, die remote ausgeführt werden, können nun kurze Netzwerkunterbrechungen nahtlos bewältigen, ohne dass die Sitzung des Benutzers geschlossen wird oder ein manuelles Eingreifen erforderlich ist.

Das Problem, das wir lösen

Netzwerkstörungen gehören in realen Einsatzumgebungen einfach dazu. Zwischen einer 4D-Client-Workstation und einem 4D-Server können sich zahlreiche Netzwerkgeräte befinden (Switches, Router, Firewalls, VPN-Gateways usw.), und jedes einzelne davon kann dazu führen, dass die beiden Peers vorübergehend nicht mehr miteinander kommunizieren können: ein Switch, der neu gestartet wird, ein Kabel, das abgezogen und wieder eingesteckt wird, ein vorübergehendes Routing-Problem irgendwo auf dem Weg. Diese Ereignisse dauern in der Regel nur wenige Minuten, können aber dennoch dazu führen, dass die Peers gegenseitig nicht erreichbar sind.

So funktioniert es

Diese Funktion basiert auf der QUIC-Transportschicht, die die Client-Server-Kommunikation von 4D ermöglicht. QUIC ist von Natur aus verbindungslos (es läuft über UDP), was bedeutet, dass es Pausen in der Kommunikation zwischen den Peers problemlos tolerieren kann, ohne die Sitzung zu beenden. Wenn 4D Server feststellt, dass eine entfernte 4D-Anwendung nicht mehr erreichbar ist, schließt er die Sitzung nicht mehr sofort. Stattdessen hält er sie aufrecht und wartet darauf, dass die Kommunikation wieder aufgenommen wird.

Die Dauer dieses Wartefensters wird durch einen neuen Datenbankparameter gesteuert: QUIC-Sitzungszeitlimit (Selektor 135). Der Standardwert beträgt 900 Sekunden (15 Minuten), bei einem Minimum von 60 Sekunden. Sie legen diesen Wert auf der Serverseite fest, und er gilt für alle neuen Sitzungen, die ab diesem Zeitpunkt eröffnet werden.

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

Hinweis: Eine Änderung dieses Werts wirkt sich nur auf neue Sitzungen aus. Bestehende Sitzungen behalten den Wert bei, der ihnen bei ihrer Eröffnung zugewiesen wurde.

Was passiert, wenn ein Peer nicht mehr erreichbar ist

unreachableSince Sobald die QUIC-Schicht auf der Serverseite eine entfernte 4D-Anwendung als nicht erreichbar meldet, zeigt das Server-Verwaltungsfenster den 4D-Client im Status „Nicht erreichbar“ an. Die Sitzung bleibt aktiv, und im Process activityObjekt `sessions[]`, das dem nicht erreichbaren 4D-Client entspricht, und zählt die seit dem letzten Kontakt verstrichenen Sekunden.

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

Auf der Client-Seite beginnt das Attribut „Session.info.unreachableSince “ damit, die Sekunden seit der letzten erfolgreichen Kommunikation mit dem Server zu zählen. Nur die Fenster, die aktiv mit dem Server kommunizieren, wechseln zu einer „Unreachable“-Anzeige: Die Benutzeroberfläche wird ausgegraut und es wird eine kontextbezogene Meldung angezeigt (bei kleineren Fenstern auch als Tooltip). Fenster, in denen lokaler Code ausgeführt wird, sind davon nicht betroffen und bleiben voll funktionsfähig. Benutzer können weiterhin an den Offline-Teilen der Anwendung arbeiten, während die Kommunikation wiederhergestellt wird.

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

Wenn die Kommunikation wiederhergestellt wird

Wird die Kommunikation wiederhergestellt, bevor das Zeitlimit der QUIC-Sitzung abläuft, wird der Vorgang transparent fortgesetzt.

Auf der Serverseite:

• Das Server-Verwaltungsfenster schaltet den 4D-Client wieder auf „Online“ um .
• Das Attribut „ unreachableSince “ wird aus dem Process activity.sessions[] -Objekts entfernt, das dem wiederhergestellten 4D-Client entspricht.

Auf der Client-Seite:

• Das Attribut „Session.info.unreachableSince “ wird entfernt.
• Alle betroffenen Fenster kehren in ihren vorherigen Zustand zurück.

Der Benutzer bemerkt möglicherweise gar nicht, dass etwas passiert ist.

Wenn das Timeout überschritten wird

Wenn die Peers länger als das festgelegte Timeout für einander unerreichbar bleiben, wird die Sitzung ordnungsgemäß beendet.

Auf der Serverseite:

• Die 4D-Client-Sitzung wird beendet.
• Zu Überwachungszwecken wird ein Warneintrag in das Diagnoseprotokoll geschrieben.

Auf der Client-Seite:

• Ein Palettendialog erklärt, dass die Sitzung geschlossen wurde, weil der Server nicht erreichbar war, und bietet die Möglichkeit zum Neustart oder zum Beenden an.
• Zudem wird eine Systembenachrichtigung angezeigt, sodass der Benutzer auch dann informiert wird, wenn die Anwendung im Hintergrund läuft. Anwendungsname und Symbol entsprechen den bei der Anwendungserstellung festgelegten Angaben.
  

Dadurch wird sichergestellt, dass die Benutzererfahrung selbst im schlimmsten Fall übersichtlich und informativ bleibt.

Sehen Sie es in Aktion

Das folgende Video führt Sie durch den gesamten Ablauf. Es beginnt mit dem bisherigen Verhalten unter Verwendung von ServerNet, bei dem jede Unterbrechung sofort zum Schließen der Sitzung führt. Anschließend wird das neue QUIC-Verhalten anhand von zwei Szenarien demonstriert:

• Die Kommunikation wird unterbrochen und dann innerhalb des Timeout-Fensters wiederhergestellt.
• Die Kommunikation wird erneut unterbrochen, doch diesmal wird das Zeitlimit überschritten und die Sitzung geschlossen.

Das bringt Ihren Benutzern zahlreiche Vorteile

Keine Programmierung erforderlich. Keine Konfiguration für die Bereitstellung. Führen Sie einfach ein Upgrade auf 4D 21 R4 durch, und dieses Verhalten ist sofort einsatzbereit – für jeden 4D-Client-Benutzer.

Dies ist keine geringfügige Verbesserung: Sie löst eines der auffälligsten und seit langem bestehenden Probleme bei 4D-Client/Server-Bereitstellungen. Ihre Kunden haben sich darüber beschwert. Damit ist Schluss.

Und 4D geht weiter als die meisten anderen. Während Webanwendungen den Benutzern in der Regel keinen Hinweis darauf geben, dass sie den Serverzugriff verloren haben (oder dies nur mit erheblichem Entwicklungsaufwand möglich ist), handhabt 4D dies transparent und sofort: Betroffene Fenster werden mit einer klaren Meldung ausgegraut, nicht betroffene Fenster funktionieren weiter, und alles wird automatisch wiederhergestellt, sobald die Kommunikation wiederhergestellt ist. Wenn Ihre Lösung so konzipiert ist, dass lokale und serverabhängige Logik voneinander getrennt sind, können Ihre Benutzer ohne zusätzlichen Aufwand ein wirklich nahtloses Online-/Offline-Erlebnis genießen.

Genau aus diesem Grund haben wir in QUIC investiert. Weitere Informationen finden Sie in unserem Beitrag darüber, warum wir uns von der veralteten Netzwerkschicht verabschiedet haben, sowie in dem Video, das die Ausfallsicherheit von QUIC im Vergleich zu anderen Netzwerkschichten demonstriert. Außerdem können Sie mehr über die bereits vorgestellte Funktion zum Wechseln der Netzwerkschicht erfahren.

Diese Funktion ist ein guter Grund, auf 4D 21 R4 zu aktualisieren und QUIC zu nutzen!

---

Haben Sie Fragen oder Feedback zu dieser Funktion? Hinterlassen Sie unten einen Kommentar oder wenden Sie sich an das 4D-Forum.