Spolehlivost sítě byla v architektuře klient/server systému 4D vždy prioritou. Ve verzi 4D 21 R4 jdeme ještě o krok dál: vzdálená aplikace 4D nyní dokáže plynule zvládat krátkodobá přerušení připojení k síti, aniž by došlo k ukončení relace uživatele nebo k nutnosti jakéhokoli ručního zásahu.

Problém, který řešíme

Výpadky sítě jsou v reálných nasazeních běžnou součástí provozu. Mezi klientskou pracovní stanicí 4D a serverem 4D může být mnoho síťových zařízení (přepínače, směrovače, brány firewall, brány VPN atd.) a kterékoli z nich může způsobit, že se oba uzly dočasně stanou navzájem nedostupnými: restart přepínače, odpojení a opětovné připojení kabelu, přechodný problém se směrováním někde na trase. Tyto události obvykle trvají jen několik minut, ale i tak mohou způsobit, že se uzly navzájem stanou nedostupnými.

Jak to funguje

Tato funkce je postavena na transportní vrstvě QUIC, která zajišťuje komunikaci mezi klientem a serverem 4D. QUIC je ze své podstaty bezpřipojovací (běží přes UDP), což znamená, že přirozeně snáší období nečinnosti mezi partnery, aniž by došlo k ukončení relace. Když 4D Server zjistí, že vzdálená aplikace 4D je nedostupná, již relaci okamžitě neukončí. Místo toho ji udržuje aktivní a čeká na obnovení komunikace.

Délka tohoto čekacího okna se řídí novým parametrem databáze: časový limit relace QUIC (selektor 135). Výchozí hodnota je 900 sekund (15 minut), přičemž minimální hodnota je 60 sekund. Nastavuje se na straně serveru a vztahuje se na všechny nové relace otevřené od tohoto okamžiku.

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

Poznámka: změna této hodnoty se týká pouze nových relací. Stávající relace si zachovají hodnotu, která jim byla přiřazena při jejich otevření.

Co se stane, když se peer stane nedostupným

unreachableSince Na straně serveru se, jakmile vrstva QUIC nahlásí vzdálenou aplikaci 4D jako nedostupnou, v okně správy serveru zobrazí klient 4D ve stavu „Nedostupný “. Relace zůstává aktivní a v objektu Process activityobjektusessions[] odpovídajícímu nedostupnému klientovi 4D, který počítá sekundy, které uplynuly od posledního kontaktu.

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

Na straně klienta začne atribut Session.info.unreachableSince počítat sekundy od poslední úspěšné komunikace se serverem. Pouze okna, která aktivně komunikují se serverem, přepnou na zobrazení „Unreachable“ (Nedosažitelné): rozhraní je zašedlé a zobrazuje kontextovou zprávu (u menších oken se zobrazuje také jako popisek). Okna spouštějící lokální kód nejsou touto změnou ovlivněna a zůstávají plně funkční. Uživatelé mohou pokračovat v práci na offline částech aplikace, zatímco se komunikace obnovuje.

// On the remote — check how long the server has been unreachable
If (Session.info.unreachableSince # Null)
ALERT ("Server je nedostupný po dobu " + String(Session.info.unreachableSince) + "s")
End if

Po obnovení komunikace

Pokud je komunikace obnovena před vypršením časového limitu relace QUIC, vše pokračuje transparentně.

Na straně serveru:

• Okno správy serveru přepne klienta 4D zpět do stavu „Online“.
• Atribut „ unreachableSince “ je odstraněn z Process activityobjektusessions[], který odpovídá obnovenému klientovi 4D.

Na straně klienta:

• Je odstraněn atribut „Session “, „info “ a „unreachableSince “.
• Všechna dotčená okna se vrátí do původního stavu.

Uživatel si možná ani nevšimne, že k něčemu došlo.

Při překročení časového limitu

Pokud jsou peerové navzájem nedostupní déle než je definovaný časový limit, relace se řádně uzavře.

Na straně serveru:

• Relace klienta 4D je odstraněna.
• Do diagnostického protokolu se pro účely monitorování zapíše varovný záznam.

Na straně klienta:

• Dialogové okno s paletou vysvětluje, že relace byla ukončena z důvodu nedostupnosti serveru, a nabízí možnost restartu nebo ukončení.
• Zobrazí se také systémové oznámení, takže uživatel je informován i v případě, že je aplikace spuštěna na pozadí. Název a ikona aplikace jsou ty, které byly definovány při vytváření aplikace.
  

Tím je zajištěno, že i v nejhorším případě bude uživatelský zážitek přehledný a informativní.

Podívejte se na to v akci

Níže uvedené video vás provede celým procesem. Začíná starším chováním využívajícím ServerNet, kdy jakékoli přerušení okamžitě uzavře relaci. Poté demonstruje nové chování QUIC ve dvou scénářích:

• Komunikace je přerušena a poté obnovena v rámci časového limitu.
• Komunikace je znovu přerušena, tentokrát však dojde k překročení časového limitu a relace se uzavře.

To vašim uživatelům přináší řadu vylepšení

Není potřeba žádné programování. Není třeba provádět žádnou konfiguraci. Stačí provést upgrade na 4D 21 R4 a toto chování je k dispozici ihned po instalaci pro každého uživatele klienta 4D.

Nejedná se o drobné vylepšení: řeší to jeden z nejviditelnějších a dlouhodobých problémů v nasazeních 4D klient/server. Vaši zákazníci si na to stěžovali. Tím to končí.

A 4D jde dál než většina ostatních. Zatímco webové aplikace obvykle uživatelům nijak neoznamují, že ztratili přístup k serveru (nebo to vyžaduje značné vývojové úsilí), 4D to řeší transparentně a okamžitě: dotčená okna jsou zašedlá a zobrazuje se v nich jasná zpráva, nedotčená okna pokračují v práci a vše se automaticky obnoví, jakmile se obnoví komunikace. Pokud je vaše řešení správně navrženo tak, aby oddělovalo lokální logiku od logiky závislé na serveru, mohou vaši uživatelé dosáhnout skutečně plynulého online/offline zážitku bez jakéhokoli dodatečného úsilí.

Právě proto jsme investovali do protokolu QUIC. Pro více informací si přečtěte náš příspěvek o tom, proč jsme upustili od starší síťové vrstvy, a podívejte se na video demonstrující odolnost protokolu QUIC ve srovnání s jinými síťovými vrstvami. Můžete se také dozvědět více o funkci přepínání síťových vrstev, kterou jsme představili dříve.

Tato funkce je skvělým důvodem k upgradu na 4D 21 R4 a k používání protokolu QUIC!

---

Máte k této funkci nějaké dotazy nebo připomínky? Napište komentář níže nebo se obraťte na fórum 4D.