LABORATORIO di Reti di Calcolatori

Transcript

1 LABORATORIO di Reti di Calcolatori Strumenti di specifica di protocolli e algoritmi di rete 1 of 44 v slide della docente Bibliografia v testo di supporto: D. Maggiorini, Introduzione alla programmazione client-server, Pearson Ed., 2009 q cap.3 (tutto) 2 of 44 1

2 v protocollo: insieme di regole per la comunicazione tra entità peer q per superare problemi di differente linguaggio dovuto a sistemi eterogenei v esistono organismi standardizzatori: q IEEE, OSI, IETF... Specifica di protocolli q definizione precisa delle regole v specifica = sintassi del linguaggio di comunicazione q chiunque può implementare protocollo standard autonomamente, con le politiche interne preferite, purchè l'interfaccia di comunicazione sia aderente alla specifica 3 of 44 v serve per vincolare l'implementazione q garantisce che tutte le implementazioni di dato protocollo possono inter-operare v serve per derivare formalmente proprietà del protocollo q dimostrazioni di correttezza del protocollo rispetto ai requisiti di servizio da fornire ai livelli superiori v strumenti diversi; livelli di dettaglio diversi v diagrammi temporali Specifica di protocolli q catturano parallelismo, ma pochi dettagli 4 of 44 2

3 v Automi a Stati Finiti (ASF) q descrizione a colpo d'occhio, ma di difficile rappresentazione se protocollo complesso v tabelle stati-eventi Strumenti di specifica q arricchimento degli AFS usati in documenti standard (e.g. specifica TCP v pseudo-codice ad alto livello delle operazioni eseguite dal protocollo q non si vede parallelismo tra entità di protocollo q può essere di difficile lettura, ma porta subito a implementazione reale 5 of 44 Diagrammi temporali v a differenza del precedente si vedono interazioni tra peer v scarso livello dettaglio operazioni v utile per dimostrazioni su proprietà per concorrenza S Msg 1 Msg 2 Msg2 - response D set timer 6 of 44 3

4 v stati rilevanti in cui si trova un processo v attende evento: q ricezione di un messaggio, arrivo di interrupt, scadenza timer... v al verificarsi di evento, processo può q cambiare valore variabili interne q produrre evento esterno (invio msg) q evolvere in nuovo stato con comportamento differente v rappresentazione: Automi a Stati Finiti IN, act, OUT current state INevent, action, OUTevent new state 7 of 44 Automi a Stati Finiti: esempio v protocollo dummy: q proc parte quando riceve Msg1 e set timer; q se riceve Msg2 prima di timeout risponde, altrimenti no q in ogni caso fa re-set timer q quando riceve Msg3, il processo termina Msg2 && timer not expired; set timer; response to Msg2 idle state Msg1; set timer; --- Msg3; exit; --- state_1 Msg2 && timer expired; set timer; 8 of 44 4

5 v dettagliano ASF tabella definizione q eventi in ingresso: ricezione messaggio di tipo xxx q eventi in uscita: invio messaggio di tipo yyy q stati del processo Tabelle stati-eventi q predicati: asserzione il cui valore di verità controlla l'evoluzione del protocollo P0: il contenuto del messaggio è corretto q stato del processo: variabili timer T, contatore C... q azioni eseguite dal protocollo reset valore T; incrementa C... 9 of 44 Primitive di servizio Confirm source Request Indication destination Response v comunicazione via buffer e interrupt v entità richiede (Request) invio messaggio v a dest: arrivo msg segnalato a dest (Indication) v se servizio confermato: q dest invia risposta/conferma ricezione (Response)... q... segnalata a sorgente (Confirm) v esempio servizio confermato? con ricevuta 10 of 44 5

6 Tabelle stati-eventi (cont.) P0: timer expired [1] : set timer stato evento Msg1.Ind Msg2.Ind Msg3.Ind idle-state [1]; state_ P0: Msg2.Resp; [1]; state_1 --- state_1 init-state P0: [1]; state_1 11 of 44 Pseudo-codice v da esempio precedente: define maxtime 100 procedure initialization {! timer 0; expired_timer False; } procedure idle_state {! when (received Msg1) do! timer maxtime;! }! procedure P0 {! if (expired_timer) then return(true);! else return(false); }! 12 of 44 6

7 Pseudo-codice (cont.) procedure state_1 {! while (True) do! when (timeout) do expired_timer True;! when (received Msg2) do! if ( P0) then send response to Msg2;! timer maxtime;! expired_timer False; when (received Msg3) do exit;! }! procedure Main {! initialization();! idle_state();! state_1()! }! 13 of 44 Esempio: silly stop&wait v sender: 1. quando riceve msg da applicazione lo invia a peer 2. attende la ricezione di un acknowledgment 3. dopo ricezione ack torna al punto 1 v receiver: 1. quando riceve msg da peer gli invia ack v quanti stati per il sender? e per il receiver? 14 of 44 7

8 SS&W: diagramma temporale S D arrivo msg da appl. msg ack to msg deliver msg to dest appl. 15 of 44 SS&W: automi a stati finiti v ASF for sender: msg from appl; ---; send msg idle state ack to msg; ---; --- wait state v ASF for receiver: unique state msg from peer; deliver to dest appl.; send ack to msg 16 of 44 8

9 SS&W: tabella stati-eventi stato evento unique state msg.indication msg.response; [1] unique state receiver [1]: deliver msg to dest appl. stato evento msg in queue from appl msg.confirm idle state msg.request; wait state --- sender wait state skip; wait state idle state 17 of 44 SS&W: pseudo-codice SENDER! procedure init { }! procedure idle_state {! when (received Msg) do! send Msg;! }! procedure wait_state {! when (received ack to Msg) do skip;! }! procedure Main{!! init();! while (True) do! idle_state();! wait_state();! }! RECEIVER! procedure init { }! procedure unique_state {! when (received Msg) do! send ack to Msg;! deliver msg to appl;! }! procedure Main{!! init();! while (True) do! unique_state();! }! 18 of 44 9

10 Commenti v non esiste specifica univoca q nel primo esempio si possono usare 2 stati al posto di state_1, e passare da uno all'altro in funzione dello stato del timer... v provare a ridisegnare per homework... J v per homework, specificare diagramma temporale, ASF, tabella stati-eventi e pseudocodice per sender nel primo esempio q ipotizzando che Msg2 venga inviato quando ricevuto da applicazione q attenzione che può anche ricevere risposta a Msg2 come Msg2.Confirm 19 of 44 Server iterativo: diagramma temp. C service.req IDLE S service.req C service.resp waiting talking talking interazioni client server service.resp close.req close.resp 20 of 44 10

11 Server concorrente: diagr. temp. C IDLE S service.req C interleaving nei tempi morti service.req service.resp service.resp talking talking talking talking close.req close.resp 21 of 44 Server multiprocesso: diagr. temp. C service.req IDLE S service.req C service.resp talking talking S S service.resp talking talking close.req close.req END END close.resp 22 of 44 11

12 Confronto modelli servizio v cosa succede se interazione con server è di 1 messaggio? q server iterativo è molto simile a quello concorrente q allora: scelta server può dipendere da modalità interazione v concorrenza di server multi-processo è reale? q beh con una sola CPU J q server figli gestiscono unico client, quindi non sono né iterativi né concorrenti! v server concorrente è il più difficile da implementare q in ogni istante può ricevere messaggi di qualunque tipo q si vede negli automi! 23 of 44 Server iterativo: ASF idle state service.ind; --; service.resp data.ind; --; data.resp close.ind; --; close.resp work state v esce da Idle quando riceve service.req v quando vi entra, ne esce immediatamente se esistono altre service.req in coda q cioè in attesa all interfaccia con livello inferiore v lo ASF del client è sempre uguale è esercizio! 24 of 44 12

13 idle state Server concorrente: ASF service.ind; --; service.resp work state data.ind; --; data.resp close.ind no other clients; --; close.resp service.ind; --; close.ind other clients; --; close.resp service.resp v serve ancora la coda? beh, è quella con livello inferioreà SI v abbiamo messo tutte le transizioni possibili? q può ricevere service.req mentre Idle? dipende ritrasmissioni, messaggi in ritardo forse si! q attenzione a gestire anche situazioni anomale dovute a caratteristiche livelli inferiori à gestione eccezioni (o segmentation fault!) 25 of 44 esercizi v costruire tabella stati-eventi per: 1. client 2. server iterativo 3. server concorrente 4. server multi-processo? J v nel caso 3, la possibile presenza di situazioni anomale è rivelata da caselle vuote nella tabella q devono proprio essere così? da accertare 26 of 44 13

14 Specifica idle RQ v Primary manda frame e si blocca in attesa di ACK q se scadenza timer ritrasmissione, ritrasmette stesso frame v Secondary in attesa di ricezione q se riceve frame danneggiato fa drop q se riceve frame corretto manda ACK q se frame corretto è quello atteso, consegna a Network Layer 27 of 44 idle RQ: ASF per Primary Specific actions: [1] = start timer [4] = increment RetxCount [2] = increment Vs [5] = Increment ErrorCount [3] = stop timer [6] = Reset RetxCount to zero 28 of 44 14

15 Primary : tabella stati - eventi 29 of 44 Primary : tabella stati - eventi 30 of 44 15

16 Primary : tabella stati - eventi trasmette frame; set timer; incrementa #seq 31 of 44 Primary : tabella stati - eventi incrementa contatore errori 32 of 44 16

17 Primary : tabella stati - eventi non fa nulla 33 of 44 Primary : tabella stati - eventi se riceve ACK per frame outstanding, con CRC corretto: ferma timer; reset contatore ritrasmissioni 34 of 44 17

18 Primary : tabella stati - eventi se riceve ACK per frame outstanding, ma CRC errato: ritrasmette; fa ripartire timer; incrementa counter ritrasmissioni 35 of 44 Primary : tabella stati - eventi se riceve frame che non è ACK ed è errato: incrementa counter errori 36 of 44 18

19 Primary : pseudo-codice v implementazione sulla falsariga della specifica: q tipi enumerativi per eventi e stati q variabili di stato q procedure per eventi in output e azioni q funzioni per controllo predicati 37 of 44 Primary : pseudo-codice 38 of 44 19

20 Secondary: ASF 39 of 44 Secondary: tabella stati - eventi 40 of 44 20

21 Secondary: tabella stati - eventi 41 of 44 Secondary: tabella stati - eventi se CRC errato: chiedi ritrasmissione frame atteso; incrementa contatore errori 42 of 44 21

22 Secondary: tabella stati - eventi se CRC corretto e frame già ricevuto in precedenza: invia ACK 43 of 44 Secondary: tabella stati - eventi se CRC corretto e frame atteso: consegna frame; invia ACK; aggiorna #seq atteso 44 of 44 22