CITAZIONE (Encio @ 5 Apr 2006 - 21:23) 
Piuttosto mi sa che ci becchiamo martedì pomeriggio a Reti di TLC! 
c'eri poi oggi?!
come ti sembra il prof?!
la mia impressione è che la materia sia abbastanza brensa, che il prof ne sappia di sicuro a pacchi, che però non sia un gran parlatore, per cui la spiegazione è un po' ardua! concordi?!
PS so che Piero Campa sta seguendo un corso simile ad ING, sarebbe carino scambiarci info utili (es Appunti, Materiale, Dispense...)
per quanto mi riguarda ecco gli appunti della prima lezione:
lezione1
email: michele.michelotto@pd.infn.it
libro: Computer Networks by Tanenbaum 4a Ed 2002 C'è anche ver ITA della 3a Ed
un motivo x usare i pc in rete è che i piccoli pc collegati in rete tra loro costano meno di grossi pc isolati.
Metcalf ha inventato ethernet: il val di una rete cresce col quadrato del num di nodi. Se ho un pc lo uso solo come pc, se già ho 2 pc posso metterli in comunicazione, se ne ho 4 ognuno messaggia cn gli altri 3. Altri sostengono che questa dicitura è sopravvalutata, ogni nodo non ha lo stesso val, il val cresce come nlogn; ci sono però articoli che invece supportano la tesi di Metcalf
Reti classificabili secondo vari aspetti
MODI D'USO
wirless mobile
No No PC in ufficio, edifici cablati
No Si Notebook in albergo via modem ad es
Si No areoporto, edifici non cablati
Si Si PDA, schede GPRS
mobilità la ottengo con palmari o telefonini
HARDWARE
Reti broadcast: canale di comunciazione condiviso a tutte le macchine della rete; ho dei pacchetti da una macchina a tutte le altre, però devono contenere l'indirizzo del destinatario (ES "il sig Rossi venga qua"); una sua variante è il Multicast, in questo caso mando pacchetto a sottoinsieme di tutte le maccchine (usato in lan per streamare audio o video)
Reti punto a punto (Unicast): diverse connessioni tra coppie di macchine, il pacchetto può passare x macchine intermedie e seguire percorsi diversi. C'è host che deve spedire pacchetto, lo inietta nella rete in cui ci sono router che instraano il pacchetto, C lo manda a E e non a D (esempio) e infine il pacch arriva a destinazione
SCALA
personal area network (collega il portatile ai dispositivi tipo telefonino &co)
reti interne: posso avere 10 pc collegati tra loro (rete interna, multicomputer, matrice di switch): non indicata la ethernet, perchè lenta.
local area network: tra 10m e 1km
metropolitan area network: intorno ai 10km, non molto diffusa in Italia, a Pisa c'è
wide area network che mi collega a varie lan: da decine di km a 10000km (intercontinentali), anche le università sono collegate da una rete di ricerca (GAR), che ha stabilito un wan per ogni campo (anche le banche)
internet che mi collega tutte le wan: pianeta
DIMENSIONI della rete
le reti piccole di solito sono broadcast (ethernet è broadcast, la stazione ricevente deve conoscere proprio indirizzo); invece le reti geografiche sono punto a punto, ci sono eccezioni tipo le reti satellitari
WAN: collega macchine (host) oppure collega delle LAN su cui stanno gli host, che sono connessi da SUBNET (divisa in linea di trasmissione (rame, fibra, radio..) e elem di commutazione tra varie linee (router); la subnet non va confusa con quella dell'ip) se 2 router nn condividono linea di trasmissione si devono servire di router intermedi (store e forward, packet switched).
ASPETTI SOFTWARE
si cerca di organizzare le reti a livelli, uno sopra l'altro, ma tra le varie tecnologie, i livelli e le funz di ogni liv cambiano da rete a rete. In pratica un livello è una macchina visrtuale che fornisce servizi al liv superiore; è come la programmazione ad oggetti. Un protocollo è di livello X dove X è il num di livelli. Le info vanno dal livello 5 al mezzo fisico (cavo, fibra, onde), poi le info passano all'host 2 e risalgono le interfacce fino ad arrivare all'host2.
Il livello N di una macchina parla col liv N dell'altra. Il protocollo è un insieme di regole che regolano questa conversazione, è un "accordo"; ad esempio i rapporti umani sociali.. diamo la mano, baciamano.. regole formali, non codificate nell'uomo, ma codificate per le reti: protocolli!
Protocollo tra computer: linea tratteggiata: comunciazione virtuale; linea fisa: comunic reale; ad ogni livello si aggiunge un header; il messaggio può anche venire dimezzato per poi essere riunito.
La comunicazione a livello logico avviene tra pari (PEER), ad es peer di liv 4 parla col peer dell'host2. A liv reale la comunic avviene solo al livello inferiore. Questa astrazione separa il progetto dell'intera rete in tanti progetti + semplici, i singoli layer.
INTERFACCIA: è definita per ogni coppia di layer; definisce le operazioni "primitive" e i servizi che il liv inferiore fornisce al superiore. E' il modo con cui accedo al servizio, è come il metodo in object.oriented
_____
PROGETTO DI UN PROTOCOLLO:
decidere quanti layer (livelli) vanno messi? + ne metto + è pulito, ma aumento anche overhead, rete + lenta perchè devo passare le info da layer a layer.. Cosa deve fare ogni layer? Devo cercare interfaccia pulita, ogni layer deve fare insieme ben definito di funzioni; devo quindi minimizzare le info da layer a layer.. si può rimpiazzare un layer con implementazione diversa.. ad es passando da eternet a wireless si cambia solo l'interfaccia da 802.3 a 802.11.. è semplice come cambiamento.
INDIRIZZAMENTO: ogni layer deve avere un modo x identificare mittente e ricevente; in una rete ho tanti pc e ognuno ha il suo indirizzo, ma ha anche vari processi che girano; ho un processo che vuole parlare via rete che vuole parlare con un altro processo di un altra macchina, vuole anch'esso il suo indirizzo. Serve anche la PORTA, per specificare il processo che gira e con cui il mio processo vuole comunicare.
TRASFERIMENTO DATI: simplex: dati in ununica direzione; half duplex: in entrambe le direzioni ma non contemporaneamente; full duplex: dati in entrambe le direzioni contemporaneamente (ethernet switchata perchè nn ho collisioni).
Quanti canali logici voglio mettere sullo stesso cavo fisico? ad es uno x dati normali e uno per dati urgenti o per gestione diritto di comunicazione.
CONTROLLO ERRORI: i cavi possono venire pestati, interferenze e così via.. devo quindi tenere conto degli errori; si possono rilevare gli errori e anche correggerli. Entrambe le parti devono concordare il metodo da usare, deve esserci un modo x dire al mittente che ciò che è stato ricevuto non è arrivato bene (corrotto, parziale)
ORDINE DEI MESSAGGI: il canale di trasmissione potrebbe nn garantire che l'info spedita è arrivata nello stesso ordine con cui era stata spedita; ad es nella rete IP ci sono tanti cammini possibili, di cui uno magari è corto del primo; le info quindi potrebbero arrivare disordinate. Devo quindi assegnare ad ogni pacchetto un numero sequenziale che mi permetta di riassemblare tutto alla fine; i messaggi fuori sequenza, cosa ne faccio? li butto, li bufferizzo e poi riassemblo...evo decidere
CONTROLLO DI FLUSSO: serve x evitare che una macchina veloce intasi una macchina lenta. Dobbiamo prevedere un feedback: esplicito, cioè il ricev manda un mess al mitte "stai spedendo tr velocemente"; implicito: messaggi di errore, il mittente si accorge che nn tutto è arrivato al ricevente.. c'è contrattazione tra i due di un rate di trasmissione adeguato; per cui prima del rtasf si mettono d'accordo sul rate e il mittente x la durata della trasmissione tenta di tenerlo x tutta la trasmissione.
LUNGHEZZA DEI MESSAGGI: ad ogni layer devo decidere la lunghezza max deel msg gestibile dal layer, quindi nel progetto del layer devo pensare a meccanismi x disassemblare i pacchetti, trasmetterli e poi riassemblarli alla fine. Oppure potrebbe essere inefficiente mandare dei msg tr corti, servono meccanismi x raggruppare quindi i msg e spedirli tutti alla destinazione comune e poi dividerli alla fine. Questo è molto delicato..
MULTIPLEX-DEMULTIPLEX: bisogna capire se conviene per ogni coppia di processi stabilire una connessione separata, o no. Ad es quando uso modem da casa, è una connessione unica per quello, quelle per la posta ecc vengono multiplexate su questa. E' un'operazione che il livello superiore non deve sapere, esso deve solo mettere il pacchetto! A livello fisico invece è una cosa che va definita
INTERFACCE E SERVIZI (differenze): gli elementi attivi nel layer sono detti entities; possono essere sia software che hardware (un chip di I/O intelligente); sono rappresentati con i rettangoli nel disegno dei layer e vi sono contenuti. Le entities di livello N implementano un servizio a favore dell'N+1, è un service provider per il service user (N+1 = utente). Gli access point di livello N sono i posti in cui il liv n+1 accede ai servizi offerti; ogni SAP ha un indirizzo che lo identifica.
ROUTING: se ho vari cammini mittente/destinatario ne devo scegliere uno; a volte una decisione viene presa a liv alto e poi modificata; ad es a livello IP se un link è particolarmente trafficato, può cambiare strada. Un router è un qualcosa che instrada il traffico.
SERIVIZI E CONNESSIONI: servizio connection.oriented: come al telefono, lo alzo, faccio il numero; funziona come un tubo, viene creato un tubo tra il mio tel e l'altro; io semplicemente infilo gli oggetti nel tubo ed escono nello stesso ordine dall'altra parte. servizio connectionless: come le poste, ogni msg ha l'indirizzo del destinatario, ogni mes viaggia per la sua strada, dati 2 msg da un mitt a un destin può sucedere che entrambi arrivano o uno sì uno no, o uno molto in ritardo risp all'altro; è una cosa che devo gestire.
Sembra + comodo il primo modo, ma ad es IP funziona nel secondo
QUALITY OF SERVICE : si obbliga il ricevente a dare una ricevuta (acknowledgement), questo mi assicura che tutto è arrivato, non si perdono i dati. In realtà quando gestisco ricevuto ho overhead e ritardi; questo può elevare il tempo della comunicazione, ma è un modo veramente sicuro (file transfer)
2 varianti: dimensioni messaggi mantenute (message sequences); oppure (byte stream) non si pulò sapere se msg dimezzati o raggruppati
SERVIZI NN AFFIDABILI: tra virgolette, nel senso che ad es il traffico voce (una telefonata su skype) non importa se perdo qualcosa, se sento un rumore.. l'importante è che nn ci siano i ritardi, qualche problema nei pixel, ma non si blocca.. voglio spedire msg che ha altà probabilità di essere consegnato, ma non ho la ricevuta (è ciò che definisce un servizio non affidabile).
SERVIZI CONNECTIONLESS AFFIDABILI a volte non conviene stabilire conness x nn perdere tempo, però deve essere affidabile, cioè ci deve essere la ricevuta
REQUEST-REPLY: un mittente manda un datagram che contiene la richiesta di avere un reply
CHI vuole servizi Unreliable (nn affidabili)? ad es se ho solo ethernet, i cui pacchetti potrebbero rovinarsi ad es se c'è collisione, allora uso questi servizi e poi i protocolli superiore affinano un po' l'affidabilità. Oppure un altro caso è se ho problemi di ritardi nn accettabili (real time, multimedia).
OPERAZIONI DI ACCESSO: le primitives sono un insieme di operazioni disponibili all'utente; sono chiamate di sistema se lo stack del protocollo è in un sistema operativo;
se voglio implementare byte stream mi serve una chiamata di sistema sulla B per mettermi in ascolto ed attendere una connessione, poi sulla macchina A faccio la connect, poi la receive, che fa attendere in lettura un mesaggio, la send manda il messaggio al peer, poi ci vuole la disconnect che interrompe la connessione
1 server esegue la listen, il processo si blocca e aspetta 2 il client fa la connect con un parametro per indirizzo del server 3 il SO manda un pacchetto al peer chiedendo la connessione, attendendo una risp dal server 4 pacchetto arriva al server, viene gestito da SO lo identifica come richiesta di connessione, controlla se c'è processo in ascolto 5se c'è lo blocca e ritorna l'acknowledgement 6 7 il server esegue subito una receive bloccando il server 8 client fa send e una receive 9 l'arrivo del pacchetto sblocca il server 10 l0arrivo sblocca il client 11 se client ha altre richieste le fa altrimenti manda un disconnect (di tipo blocking,cioè aspetta che l'altro dà l'ok di disconnessione) 12 server riceve pacchetto, fa disconnect e chiude 13 il server va avanti
può andare storto qcosa se connect viene fatta prima della listen. oppure si perdono i pèacchetti.
connectionless useremmo 2 pacchetti invece di 6, ma ci sono spesso errori, perdite, e grossi mesaggi; non abbiamo problemi di economia di pacchetti..
SERVIZI E PROTOCOLLI: sono due cose diverse; i servizi indicano le operazioni che uin liv fornisce al liv superiore, quali operazioni il layer fornisce agli utenti, ma non specifica come queste operazioni vanno implementate; il protocollo invece decide le regole, il formato e significato dei pacchetti che le peer entities si scambiano; le entities possono cambiare significato ma se non cambiano i servizi, l'utente non se ne accorge. Puoi cambiare come fai le operazioni e tutto continua a funzionare. E' come un oggetto che nasconde l'implementazione dei metodi, si possono aggiungere nuove implementazioni del metodo, e l'oggetto che lo chiama non ha nessun problema perchè nn sa e nn vuol sapere l'implementazione, ma solo usufruire del servizio. Il protocollo va in orizzontale, i servizi in verticale
