L’affidabilità della rete è sempre stata una priorità nell’architettura client/server di 4D. Con 4D 21 R4, facciamo un ulteriore passo avanti: le applicazioni 4D in remoto sono ora in grado di gestire senza problemi brevi interruzioni di rete, senza chiudere la sessione dell’utente né richiedere alcun intervento manuale.

Il problema che stiamo risolvendo

Le interruzioni di rete sono una realtà inevitabile nelle implementazioni reali. Tra una workstation client 4D e un 4D Server possono esserci molti dispositivi di rete (switch, router, firewall, gateway VPN e così via) e ognuno di essi può rendere i due peer temporaneamente irraggiungibili l’uno per l’altro: il riavvio di uno switch, un cavo scollegato e ricollegato, un problema di routing transitorio da qualche parte lungo il percorso. Questi eventi in genere durano solo pochi minuti, ma possono comunque rendere i peer reciprocamente irraggiungibili.

Come funziona

Questa funzionalità si basa sul livello di trasporto QUIC che gestisce la comunicazione client/server di 4D. QUIC è per sua natura senza connessione (funziona su UDP), il che significa che può tollerare naturalmente periodi di silenzio tra i peer senza interrompere la sessione. Quando 4D Server rileva che un’applicazione 4D remota è diventata irraggiungibile, non chiude più immediatamente la sessione. Al contrario, la mantiene attiva e attende che la comunicazione riprenda.

La durata di questa finestra di attesa è controllata da un nuovo parametro del database: timeout della sessione QUIC (selettore 135). Il valore predefinito è 900 secondi (15 minuti), con un minimo di 60 secondi. Si imposta sul lato server e si applica a tutte le nuove sessioni aperte da quel momento in poi.

// 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: la modifica di questo valore ha effetto solo sulle nuove sessioni. Le sessioni esistenti mantengono il valore loro assegnato al momento dell’apertura.

Cosa succede quando un peer diventa irraggiungibile

Dal lato server, non appena il livello QUIC segnala un’applicazione 4D remota come irraggiungibile, la finestra di amministrazione del server mostra il client 4D in stato “Irraggiungibile ”. La sessione viene mantenuta attiva e un nuovo attributo unreachableSince diventa disponibile nell’oggetto Process activityoggetto .sessions[] corrispondente al client 4D irraggiungibile, che conta i secondi trascorsi dall’ultimo contatto.

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

Dal lato client, l’attributo Session.info.unreachableSince inizia a contare i secondi trascorsi dall’ultima comunicazione riuscita con il server. Solo le finestre che stanno comunicando attivamente con il server passano alla visualizzazione “Non raggiungibile”: l’interfaccia viene disattivata con un messaggio contestuale (visualizzato anche come tooltip per le finestre più piccole). Le finestre che eseguono codice locale non sono interessate dal problema e rimangono pienamente utilizzabili. Gli utenti possono continuare a lavorare sulle parti offline dell’applicazione mentre la comunicazione viene ripristinata.

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

Quando la comunicazione riprende

Se la comunicazione viene ripristinata prima della scadenza del timeout della sessione QUIC, tutto riprende in modo trasparente.

Sul lato server:

• La finestra di amministrazione del server riporta il client 4D allo stato “Online”.
• L’attributo unreachableSince viene rimosso dall’ Process activityoggetto .sessions[] corrispondente al client 4D ripristinato.

Sul lato client:

• L’attributo Session.info.unreachableSince viene rimosso.
• Tutte le finestre interessate tornano allo stato precedente.

L’utente potrebbe non accorgersi nemmeno di ciò che è accaduto.

Quando viene superato il timeout

Se i peer rimangono irraggiungibili l’uno per l’altro per un tempo superiore al timeout definito, la sessione viene chiusa in modo corretto.

Sul lato server:

• La sessione del client 4D viene rimossa.
• Viene registrata una voce di avviso nel log diagnostico a scopo di monitoraggio.

Sul lato client:

• Una finestra di dialogo spiega che la sessione è stata chiusa perché il server era irraggiungibile e offre la possibilità di riavviare o uscire.
• Viene inoltre visualizzata una notifica di sistema, in modo che l’utente sia informato anche se l’applicazione è in background. Il nome e l’icona dell’applicazione sono quelli definiti durante la creazione dell’applicazione.
  

Ciò garantisce che, anche nel peggiore dei casi, l’esperienza sia chiara e informativa.

Guardalo in azione

Il video qui sotto illustra il quadro completo. Si inizia con il comportamento legacy che utilizza ServerNet, in cui qualsiasi interruzione chiude immediatamente la sessione. Viene poi illustrato il nuovo comportamento QUIC in due scenari:

• La comunicazione viene interrotta e poi ripristinata entro il tempo di timeout.
• La comunicazione viene interrotta nuovamente, ma questa volta il timeout viene superato e la sessione viene chiusa.

Questo apporta numerosi miglioramenti per i tuoi utenti

Non è richiesta alcuna codifica. Non è necessaria alcuna configurazione. È sufficiente effettuare l’aggiornamento a 4D 21 R4 e questo comportamento sarà immediatamente disponibile per tutti gli utenti client 4D.

Non si tratta di un miglioramento di poco conto: risolve uno dei punti deboli più evidenti e di lunga data nelle implementazioni client/server di 4D. I vostri clienti se ne sono lamentati. Ora è tutto risolto.

E 4D va oltre la maggior parte delle soluzioni. Mentre le applicazioni web in genere non forniscono agli utenti alcuna indicazione della perdita di accesso al server (o richiedono un notevole sforzo di sviluppo per farlo), 4D gestisce la situazione in modo trasparente e immediato: le finestre interessate vengono disattivate con un messaggio chiaro, quelle non interessate continuano a funzionare e tutto viene ripristinato automaticamente quando la comunicazione riprende. Se la vostra soluzione è progettata correttamente per separare la logica locale da quella dipendente dal server, i vostri utenti potranno godere di un’esperienza online/offline davvero senza soluzione di continuità, senza alcuno sforzo aggiuntivo.

Questo è esattamente il motivo per cui abbiamo investito in QUIC. Per ulteriori approfondimenti, leggete il nostro post sul perché abbiamo abbandonato il livello di rete legacy e guardate il video che mostra la resilienza di QUIC rispetto ad altri livelli di rete. Potete anche scoprire di più sulla funzionalità di cambio del livello di rete introdotta in precedenza.

Questa funzionalità rappresenta un ottimo motivo per passare a 4D 21 R4 e utilizzare QUIC!

---

Hai domande o commenti su questa funzionalità? Lascia un commento qui sotto o contattaci sul Forum 4D.