L’architettura del programma gestisce la sospensione delle sessioni, un meccanismo che consente di fronteggiare la perdita di connessione tra iDesk e MxServer senza subire la chiusura del processo Passepartout.

Sospendere una sessione significa chiudere il socket di comunicazione tra iDesk e MxServer. Lato client, MxDesk.exe termina così la sua esecuzione, mentre lato server il processo richiesto in esecuzione continua a girare, sapendo però di non avere più un iDesk attivo con cui colloquiare. In quest’ottica sarà possibile eseguire la riconnessione, ossia ripristinare la comunicazione tra iDesk e MxServer: con iDesk che torna attivo, l’operatore può tornare a gestire i flussi di I/O, consentendo al processo Passepartout di accettare nuovamente input e visualizzare output per le proprie funzioni applicative.

Le sospensioni involontarie o forzate avvengono secondo due filoni principali: errore di rete sul socket oppure timeout. Nel primo caso, le funzioni di sistema dei due interlocutori, server e client, intercettano un evento di errore previsto come standard dalle rispettive interfacce di comunicazione socket. Nel secondo caso, non vi sono errori di rete ma nessun pacchetto transita più sul canale, determinando un’uscita per timeout. Infatti, iDesk e MxServer si scambiano periodici segnali di controllo che consentono di mantenere attiva la connessione anche a fronte di inattività utente: se tali pacchetti non transitano più sul socket entro il tempo massimo previsto, la connessione si chiuderà per timeout. Sia iDesk sia MxServer prevedono un loro timeout, che scatta rispettivamente quando non ricevono traffico dalla controparte: per iDesk si tratta di 40 secondi, per MxServer di 30 secondi. Senza tali timeout, a pari condizioni, la connessione resterebbe attiva ma di fatto inutilizzabile.

Nel caso in cui la cornice sia aperta con più tab, si chiudono tutti e soli quelli che ritornano errore o timeout dallo strato socket. Ciò vale anche qualora la totalità dei tab aperti ritorni errore. Di seguito si descrivono alcuni possibili scenari.

In caso di timeout intercettato lato client (ovvero quest’ultimo non ha ricevuto traffico da MxServer per oltre 40 secondi), i tab visualizzano la seguente finestra modale:

Proseguendo in tale contesto, in generale appena un tab ritorna errore, sia esso l’unico tab o meno nella cornice, si presenta una finestra come segue:

La finestra è modale e impone una scelta bloccante sull’operatività della cornice: finché non si sceglie una delle opzioni, non è possibile compiere altre operazioni nella cornice di lavoro. Inoltre, tale finestra è unica anche se più tab ottengono errore di rete. Se tutti i tab hanno ottenuto errore di rete, il task principale visualizza una finestra vuota, altrimenti il fuoco torna sul tab più a sinistra tra quelli rimasti attivi.

Eseguendo “Riprova”, il task termina autonomamente chiudendo eventuali ulteriori tab rimasti aperti perché non riceventi errore, poi si riavvia altrettanto automaticamente e riconnette tutte le sessioni.

Eseguendo “Annulla”, le sessioni che hanno chiuso il socket non si riconnettono automaticamente, ma possono essere riconnesse manualmente in due modi:

• eseguendo una duplicazione MDI generica (pulsante oppure Ctrl+F10), in modo da riagganciare interattivamente tutte le sospese senza chiudere la cornice;
• sospendendo l’intera cornice e riconnettendola interamente da iDeskmanager. Se tutti i tab avevano avuto errore e si preme “Annulla”, il task termina e non avviene riconnessione automatica. In tale caso, la riconnessione dovrà avvenire manualmente ripartendo da iDeskmanager.

Le sospensioni involontarie avvengono anche quando termina forzatamente il task MxDesk.exe. In questo caso, la finestra di richiesta riconnessione non compare ed occorre eseguire manualmente la riconnessione.

In presenza di sospensioni involontarie, la riconnessione potrebbe non risultare immediatamente disponibile. Questo comportamento dipende da come lo strato socket di ciascuna controparte reagisce alla mancanza di transito pacchetti, poiché non sempre ritorna un errore all’una od all’altra controparte. Esistono casi in cui la connessione lato client è chiusa mentre lato server risulta ancora attiva. In tale casistica potrebbe avvenire che una richiesta di riconnessione da parte del client venga interpretata dal server come la richiesta per una nuova connessione e quindi non collegata alla sessione precedentemente sospesa (lato client). In tal caso, l’utente che voglia recuperare la sessione sospesa dovrà terminare la nuova sessione aperta erroneamente, attendere il tempo di timeout del server (30 secondi) e rilanciare la connessione al server tramite iDeskmanager. Il server, trascorso il tempo di timeout, avrà sicuramente sospeso la sessione e quindi la ripristinerà correttamente.

L’applicazione gestisce un caso specifico: in seguito alla finestra di “Errore di comunicazione con il server: il server non risponde”, la richiesta di riconnessione da parte dell’utente viene ritardata di 8 secondi per permettere al server di chiudere e sospendere correttamente la sessione interrotta.