Timeout, ritrasmissioni e politiche di priorità

Una volta che un nodo inserisce nel sistema una determinata attività non si ha alcuna garanzia del fatto che questa venga eseguita. I motivi per cui questo potrebbe succedere sono molteplici e di seguito se ne riportano alcuni a titolo d’esempio:

• problemi di rete nelle comunicazione fra nodo e nodo (ad esempio troppi pacchetti TCP persi);

• nodi momentaneamente fuori servizio per malfunzionamenti dell’hardware, o per blocchi al software;

• saturazione di un nodo a causa di troppe attività da gestire.

In linea generale un’attività può essere abortita per due differenti tipologie di guasti: • temporanei, quando il disservizio dura una frazione di secondo o al massimo

qualche decina di secondi (es. problemi di comunicazione);

• permanenti, quando il guasto richiede l’intervento di un tecnico per poter essere risolto e la durata del disservizio supera qualche decina di secondi (es. guasto hardware).

42 4.2. STRUTTURA DELL’APPLICAZIONE

Per come è strutturato URC i guasti (di qualsiasi tipo) che non permettono di por-tare a compimento le varie attività rappresentano un problema serio, in quanto un disservizio ad un nodo collocato ai livelli superiori dell’albero può compromettere l’utilizzo di una grossa parte del sistema. Per questo risulta importante implementa-re delle politiche di gestione delle attività che implementa-rendano il sistema tollerante ai guasti. Chiaramente se ciò non può essere fatto per i disservizi permanenti, nel caso di interruzioni temporanee si può fare in modo che le attività non vengano abortite prematuramente.

Per questo motivo URC adotta due tipologie di timeout sulle attività, unite a delle politiche di gestione delle ritrasmissioni. Il sistema prevede, inoltre, dei meccanismi di gestione delle priorità, per evitare che un nodo saturi le proprie capacità operative in seguito all’esecuzione di troppe attività onerose in termini di risorse.

Timeout globale dell’attività All’aggiunta di una determinata attività nel da-tabase di appoggio viene inserito anche un apposito valore di timeout. Tale valore, che a livello implementativo è un numero intero, rappresenta il numero di secondi entro il quale l’attività deve essere portata a termine; se il timeout dovesse scadere l’attività verrebbe automaticamente abortita.

Questo accorgimento permette di evitare che in nodo rimanga in attesa di rice-vere una risposta dai propri figli bloccando l’esecuzione dell’attività a tutti i livelli dell’albero.

Chiaramente, essendo il servizio di sistema identico in tutti i nodi server e con-siderando che le attività vengono gestite in modo indipendente dai diversi nodi, tale meccanismo viene applicato a tutti i livelli dell’albero.

Timeout sulle singole sotto-attività (retry-limit) Come per il timeout globale dell’attività madre, anche ogni sotto-attività è legata ad uno specifico timeout il cui valore, però, ha un significato differente.

Mentre nel caso precedente il valore intero rappresenta una soglia temporale en-tro cui l’attività dev’essere compiuta, in questo caso il timeout identifica il numero di tentativi che un nodo ha a disposizione per cercare di eseguire il comando. Que-sto tipo di timeout è stato denominato retry-limit. Se la procedura di esecuzione dell’attività (ovvero il dialogo con un nodo figlio o con uno dei bridge) non può es-sere avviata, o dovesse terminare prematuramnte a causa di un disservizio, il nodo ripeterà da capo la procedura di esecuzione. Ad ogni tentativo il servizio di sistema provvederà a decrementare il valore di timeout retry-limit, fino a che non si raggiun-gerà lo zero. In questo caso l’attività verrà considerata non compiuta e verrà abortita definitivamente.

Va evidenziato che non vi è alcuna relazione fra i due tipi di timeout e che la loro scadenza reciproca è arbitraria e dipende dal caso specifico che si viene a creare.

Quello che è certo è che il timeout che scade per primo è quello che determina la fine dell’attività.

4. IL SERVIZIO DI SISTEMA 43

Priorità di esecuzione delle sotto-attività Alcune delle attività viste alla se-zione 2.3 risultano più “impegnative” di altre, sia in termini di risorse, sia per quanto concerne il tempo dedicato alla loro esecuzione.

Ad esempio, la procedura di aggiornamento del firmware è probabile che impegni i nodi server a diretto contatto con i forni per molto tempo, soprattutto nel caso in cui un singolo nodo sia collegato ad un numero elevato di bridge. Considerando ad esempio un firmware di 200-300 kByte e tenendo in considerazione le limitate capacità computazionali dell’hardware interno al bridge, è probabile che il nodo server impieghi qualche decina di secondi per effettuare il trasferimento dell’intera attività. Se il nodo server che esegue l’attività dovesse effettuare la stessa operazione in 20 forni diversi, l’attività di aggiornamento nel complesso potrebbe impiegare anche più di 10 minuti.

Per tale motivo, supponendo che un nodo server possa gestire un numero limita-to di attività simultanee, è necessario implementare delle politiche di gestione delle priorità per l’esecuzione delle diverse attività. Se ciò non viene fatto, nel caso del-l’esempio precedente, si corre il rischio che nuove attività che vengono assegnate al nodo, in seguito all’avvio dell’aggiornamento del firmware vengano abortite per il sopraggiungere del timeout globale.

URC per la gestione delle attività prevede due livelli di priorità: alta priorità e bassa priorità. L’attribuzione dei due livelli di priorità viene riportata in Tabella 4.1.

Attività Priorità

Aggiornamento firmware Bassa

Programmi di cottura Alta

Parametri di funzionamento Alta

Log HACCP Bassa

Log programmi di cottura avviati Bassa

Warning e allarmi Alta

Risultati dei programmi di autodiagnosi Bassa

Tabella 4.1: elenco delle attività con il relativo grado di priorità

In pratica, supponendo che ogni nodo server possa eseguire 10 attività simul-tanee1, la logica interna al servizio di sistema prevede che possano essere gestite simultaneamente al massimo 5 attività a bassa priorità (attività più onerose). In sostanza il sistema riserva (almeno) 5 “posizioni” per l’esecuzione di attività ad alta priorità, per fare in modo che anche in presenza di molte attività onerose queste non possano compromettere l’operatività del sistema.

Inoltre il sistema mette in atto una seconda politica di priorità, basata sulla profondità di origine delle attività. In sostanza ogni qualvolta un nodo deve avviare l’esecuzione di una determinata attività dà priorità ai comandi che provengono dai livelli più alti. Questo meccanismo fa sì che richieste più “profonde” vengano gestite più velocemente man mano che il numero di nodi interessati aumenta, consentendo di liberare più rapidamente le risorse occupate di ogni livello.