Reti di calcolatori 27/09/16

Cliente/Servitore
Servitore deve sempre essere disponibile (attivo), il cliente pu fare la richiesta ed
essere eseguita.
Il servitore conosce il cliente quando fa la richiesta.
Interazione: servitore deve essere attivo e raggiungibile dai clienti attraverso
messaggi; simmetria: il servitore una volta ricevuta la richieste dal cliente pu
rispondere senza che lo conosca prima.
Modello: molti a uno; serie di clienti che interagiscono con il servitore (asimmetrico).
Interazione sincrona/asincrona: cliente si aspetta una risposta/cliente non si aspetta
una risposta.
Bloccante/non bloccante: si applicano in locale per indicare lentit cliente; se il client
si blocca in attesa di risposta.
Asimmetrico : solo una delle due parti conosce laltra/tutte due si conoscono.
Dinamico/statico: Nome logico mutabile o no nel tempo.
Default(per noi) di interazione tra cliente e servitore:
- Binding dinamico, modello asimmetrico.
- Interazione sincrono(semantica della comunicazione), bloccante(decisione
locale, client).
- Il supporto non tenuto ad attivare il servitore automaticamente se nessuno
lha fatto, il servitore deve essere gi attivo, altrimenti invia indicazione di
errore(non in ascolto).
Il cliente aspetta una risposta, quanto aspetta?
Progettazione: servitore pi complesso, detiene i dati su cui lavora, asimmetrico,
tipicamente concorrenti.
Problemi: autenticazione clienti, chi pu fare cosa, privacy delle informazioni.
Il servitore deve essere sempre pronto a servire le richieste (server deve essere
attivo).
Bloccante: il cliente vuole ricevere una risposta, se non ce lha dopo un tempo
massimo timeout , crash di sistema oppure smaltisce il traffico precedente alla nostra
richiesta ( sistema dimensione finita di coda di processi), il cliente scatta una
eccezione (tipo di trigger), supporto indica che ci pu essere un problema, il cliente
pu ripetere loperazione, pu andare su un altro server, potrebbe chiudere tutto e
uscire, potrebbe riportare allutente e chiedere cosa fare.
Nel distribuito gestire i problemi di risposta.
Il cliente cosa pu fare quando non arriva una risposta: timeout, si ripete la richiesta
un po di volte e rinunciare se non riceve risposte.
Il servitore un demone666, modello: coda di richieste in ingresso (gestita FIFO);
server sequenziale o concorrente (dipende da quanto tempo serve per eseguire la
richiesta).
Il server deve collaborare con il cliente (deve avere STATO), tiene conto che il cliente
ripete loperazione dopo averla eseguita una volta scarta le successive.
Il servitore pu notificare al cliente (non bloccante); potrebbe coordinarsi con altri
servitori prima di rispondere (mission critical).
Pi cose fa il server pi costa.
Server sequenziale: costo minore perch pi semplice.
Server concorrente: un insieme di processi eseguiti dal server.

Accesso ad una risorsa: a polling (ripete loperazione tin tin tin). Anche con un solo
processo.
Es. Read bloccante.
Processi leggeri (costo pi basso e garantisce la concorrenza). Sincrono bloccante.
Il cliente pu ripetere le richieste e il server pu riconoscere quelle ripetute. Obiettivo:
realizzare il server in modo che dia la risposta una volta sola e correttamente. Il cliente
deve identificare le richiesta per essere riconosciute. Risultato deve essere
consistente, quando il cliente ha ricevuto le richieste.
Es. TCP vede se il messaggio gi arrivato a livello di driver. Tu mi porti suuuu e poi
mi lasci cadere!
Modello asincrono: cliente invia richiesta al servitore e non aspetta una risposta.
Modello sincrono e non bloccante: cliente invia la richiesta e aspetta la risposta ma intanto fa altro,
periodicamente si ferma e controlla se arrivata la risposta/supporto che notifica larrivo della
risposta.
Il cliente ha sempre liniziativa.
Pull: cliente si tira la risposta. Controlla sempre se c la risposta.
Push: cliente manda richiesta una sola volta, si sblocca e fa altro il server prende la responsabilit
di inviare la risposta. Modello pi simmetrico (deve conoscere il cliente). Supporto invia una
notifica. (SINCRONA NON BLOCCANTE).
Esempio:Modelli sincroni e non bloccanti
Feed RSS: registrazione su un sito per ricevere gli aggiornamenti.
(Tipo PUSH) Richiede: cliente si registra, quando riceve la notifica disaccoppiata in tempo.
(Tipo PULL) controlla sempre se la risposta arrivata.
Modello push
Nel distribuito vogliamo disaccoppiare cliente servitore non solo in tempo(attivi
contemporaneamente), anche in spazio (devono esserci entrambi perch il servizio avvenga).
Delegati (proxy) si fa carico di ricevere la risposta poi manda al cliente (pull o push). Per
disaccoppiare proxy in rete (pull). Disacc. Non in spazio proxy fisico nel client(push).
Per definire in modo applicativo quello detto fin ora
Modello a Framework: ribalta flusso di esecuzione
Registra delle funzioni invocate dal framewrok (Es. windows, processi in loop in attesa di eventi,
frame work up call man mano che si eseguono gli eventi), push per notificare lavvenuta risposta.
Eventi asincroni: nei s.o. primitive non bloccanti, riceve notifiche in modo asincrono.
Modello c/s default: implica un accoppiamento molto forte, perch in tempo e spazio (ci siano e
siano attivi allo stesso istante). Troppo vincolante.
Modelli meno accoppiati: asincroni (e-mail, possono essere perse), che domani poi un altro fiiiilm
, pi complessi da gestire, mediatore (supporto) si fa carico delle notifiche, a volte diventa frame
work.
Sincroni non bloccante: modello publish/subscribe: 3 entit: produttore di contenuti, consumatore
esprimono la volont di voler ricevere un contenuto, gestore. Liste di sottoscrizione.
Mandare i contenuti a diversi consumatori.
Disaccoppiamento ancora maggiore, lunico che conosce i consumatori il server di notifica.
Modello a eventi: produttori e consumatori di contenuti, linterazione a push verso i consumatori.
Modello nel distribuito, flusso di computazione separato tra gestore, produttore e consumatore.
(Es. quotazione di borsa). Canali informativi.
Gestore degli eventi pu essere una macchina fisica oppure replicata (dipende
dallimplementazione).

A default non molto flessibile (no molti a molti), Multicast(IP) e Broadcast(TCP).

Altri modelli pi evoluti
Minimo accoppiamento tra le entit (no spazio e tempo), server di notifica o gestore di eventi. Modi
di interazione Multicast e broadcast (a livello applicativo collego su canali dove posso mandare
contenuti, a livello di rete si ha una rete di router multi cast i produttori possono inviare su questi
supporti i contenuti).
Costo multi cast e broadcast: molto costosa da mantenere in ambienti vicini.
Filtro in Unix
Programma che riceve uno standard input(flusso di byte) e produce almeno unuscita sullo stdout e
uno su stderr.
Es. programma che filtra per un file di txt solo le righe che iniziano per una vocale.
Filtri collegati con il piping facile comporre comandi che lavorano con la stessa logica a filtri.
Deve consumare tutte le stringhe di ingresso fino a quando non arriva allEOF. E portare in uscita il
risultato.