Controllo degli errori

È chiaro che il canale ha bisogno di meccanismi appositi per garantire una certa robustezza agli errori. I meccanismi previsti per rendere il canale relativamente robusto sono essenzialmente tre:

• Checksum sui messaggi

• Message - Acknowledgement Protocol (MAP) • Channel Free Control

(a) Pacchetto Singlebyte

(b) Pacchetto Multibyte

(c) Pacchetto ACK

5.3.2.1 Checksum sui messaggi

I messaggi ricevuti potrebbero subire alterazioni, dovute essenzialmente ad interferenze esterne che potrebbero indurre all'errore il ricevitore IR. Per evi- tare questo problema, il frame è sempre concluso da un byte di Checksum, calcolato come somma di tutti i byte che compongono il corpo del pacchetto (notare che sono coinvolti nel conto solo i byte di messaggio, non i loro com- plementi, altrimenti la somma è chiaramente nulla). Il livello di sicurezza introdotto da questo meccanismo non è ovviamente altissimo, ma ha il pre- gio di essere estremamente semplice dal punto di vista computazionale (una somma per ogni byte inviato o ricevuto). Altri meccanismi più complessi si trovano proposti in letteratura, ma sono troppo pesanti, visto quanto detto in precedenza.

5.3.2.2 Message - Acknowledgement Protocol

In alcuni casi è necessario, per il mittente, avere la sicurezza che il messaggio inviato sia giunto correttamente a destinazione. Per questo ad ogni messaggio il ricevente deve rispondere con un messaggio di acknowledgement (detto ACK). Il mittente dunque invia il messaggio ed attende la ricezione dell'ACK. Se questo arriva entro il timeout previsto, il Data Link Layer comunica che la trasmissione è andata a buon ne, se invece il timeout è raggiunto senza che l'ACK sia ricevuto, il Data Link Layer avvisa del problema. Viene invocata in entrambi i casi la conrm, ma con parametro diverso (vedi Figura 5.4 A). Poiché non sempre il ricevente ha la necessità della sicurezza sulla ricezione, si è scelto di poter selezionare, in fase di congurazione del sistema, se il Data Link Layer deve procedere o meno all'invio dell'ACK. Se questo non è richiesto, la trasmissione si considera conclusa correttamente alla ne della trasmissione dell'ultimo byte del pacchetto, ed è a questo punto che viene invocata la conrm. Si nota che alla ne della trasmissione viene sempre invocata la conrm, sia che la trasmissione si sia conclusa correttamente, sia che si siano vericati errori (vedi Figura 5.5).

request timeout confirm(OK) indication timeout stopped request timeout confirm(ERR) indication ALL OK ACK ERROR request timeout confirm(ERR) TX ERROR

request confirm(OK) indication ALL OK request confirm(OK) TX ERROR

Figura 5.5: Scenari del DLL senza il protocollo MAP

Si mette in evidenza che il protocollo descritto è uguale al classico pro- tocollo Stop&Wait, ma con una dierenza: le trame non sono etichettate. Questa scelta è dovuta al fatto che nel caso specico si è ritenuto inutile tale meccanismo. La sua utilità infatti è legata al fatto che grazie all'eti- chetta il ricevente può riconoscere i messaggi nuovi da quelli che sono copie di messaggi precedenti, ed è particolarmente utile quando la ritrasmissione è automatica. In questo caso, invece, la ritrasmissione non è automatica, solo i livelli superiori decidono o meno per la ritrasmissione. Inoltre poiché il siste- ma di comunicazione è pensato essenzialmente per applicazioni di controllo, non sarà frequente il caso in cui due messaggi uguali uno di seguito all'altro possano essere dannosi. Si preferisce quindi snellire il sistema ed omettere questo aspetto del classico protocollo Stop&Wait.

5.3.2.3 Channel Free Control

Per quanto detto in precedenza riguardo alla funzione conrm, è possibile evitare la sovrapposizione delle richieste di invio semplicemente attendendo la conrm per eettuare una nuova richiesta. Può capitare invece che ven- ga eettuata una richiesta di trasmissione quando il canale è occupato da una ricezione. Poiché il canale è half-duplex, è inutile e dannoso iniziare la trasmissione, in quanto non solo la trasmissione non sarà eettuata corret- tamente, ma anche la ricezione sarà probabilmente perduta (in eetti può darsi che la ricezione sia in fase di conclusione, e quindi arrivi a termine, ma la trasmissione non sarà sicuramente ricevuta dall'altra entità, che non ha il tempo necessario per riabilitare la ricezione). Per evitare questo problema, prima di eettuare una trasmissione, il Data Link Layer verica la disponi- bilità del canale. In sostanza se il Data Link Layer ha iniziato una ricezione, non accetta le trasmissioni no alla ne della ricezione (fatto che libera il canale). In base alle impostazioni di congurazione il comportamento può essere di tre tipi:

• la trasmissione richiesta è scartata, e viene invocata la conrm, con un parametro che indica che il canale è occupato;

• la trasmissione è ritardata per un certo periodo nella speranza che il canale si liberi; se il canale si libera entro il timeout previsto, la trasmissione è eettuata, altrimenti viene scartata e come nel primo caso viene invocata la conrm, con lo stesso parametro;

• la trasmissione è ritardata no a quando il canale non si libera.

Il sistema migliore è forse il primo, perché si ottiene una risposta rapida e non si sfruttano troppo le risorse (in particolare la CPU), ma ha il difetto di co- stringere l'applicazione al polling dell'interfaccia infrarossa se la trasmissione deve essere eettuata. Il secondo caso è un compromesso tra sfruttamento

delle risorse e polling dell'applicazione: per un certo periodo il sistema man- tiene il controllo dell'interfaccia, tentando di eettuare la trasmissione, per cui le risorse, specialmente il processore, sono usate più che nel primo caso, però durante quel periodo di tempo l'applicazione non ha bisogno di fare polling sul canale. D'altra parte questo tipo di comportamento ore anche delle garanzie sul tempo di risposta, anche se ovviamente i tempi di attesa saranno più lunghi che nel primo caso. Il terzo tipo di comportamento è sicuramente quello peggiore dal punto di vista Real-Time, perché non ore nessun tipo di garanzia, ed è assolutamente imprevedibile, ma in certi casi puó essere utile, basti considerare che di fatto è il sistema che ore tempi minori, rimanendo in attesa di poter inviare, ed eettuando la trasmissione appena il canale si libera.