Realizzato da Roberto Savino 3-1 Il livello di trasporto r Dobbiamo assumere di avere a che fare con un canale di comunicazione molto particolare 1. Inaffidabile.

Presentazione sul tema: "Realizzato da Roberto Savino 3-1 Il livello di trasporto r Dobbiamo assumere di avere a che fare con un canale di comunicazione molto particolare 1. Inaffidabile."— Transcript della presentazione:

1 Realizzato da Roberto Savino 3-1 Il livello di trasporto r Dobbiamo assumere di avere a che fare con un canale di comunicazione molto particolare 1. Inaffidabile r I pacchetti possono morire, per tre possibili motivi: rCongestione della rete, congestione della destinazione, corruzione dei pacchetti 2. Ciò che parte non arriva sempre nello stesso ordine

2 Realizzato da Roberto Savino 3-2 UDP UDP Risolve solo i problemi di corruzione dei pacchetti, e vi da la possibilità di differenziare il traffico per numero di porta. DNS usa UDP.

3 Realizzato da Roberto Savino 3-3 ICMP r E un protocollo senza numero di porta r I suoi pacchetti vengono intercettati e processati prima di essere smistati a un socket r Ping fa uso di ICMP, per misurare il round trip time, ma anche, in teoria, per controllare altri parametri di TCP. E un protocollo di servizio r I pacchetti ICMP contengono un codice messaggio, una checksum ed eventuali dati.

4 Realizzato da Roberto Savino 3-4 Come è connesso TCP/UDP/ICMP allo strato applicazione r Sullo strato applicazione ci sono funzioni di libreria per aprire, chiudere, scrivere e leggere da socket r Sul livello trasporto cè una libreria del sistema operativo (detta STACK TCP/IP) che si occupa di sbucciare e smistare i messaggi in base ai numeri di porta e al protocollo utilizzato.

5 Realizzato da Roberto Savino 3-5 Comunicazione TCP: Passo 1 r Due interlocutori, messi in comunicazione con un canale inaffidabile (i pacchetti possono sparire o arrivare corrotti, o addirittura in ritardo)

6 Realizzato da Roberto Savino 3-6 Stop & Wait r Prima soluzione: protocollo stop & wait m Conferma di ogni pacchetto m La mancata conferma viene rilevata tramite time-out m Numeri di sequenza m Inefficiente

7 Realizzato da Roberto Savino 3-7 Comunicazione TCP: passo 2 r Protocolli a finestra scorrevole r Go Back N, Selective Repeat r Finestra dinamica r Esempio sul sito : m http://pippo.com/aw/aw_kurose_network_2/ap plets/go-back-n/go-back-n.html m http://www.pluto.it/~kjt/software/comms/jasp er/SWP5.html

8 Realizzato da Roberto Savino 3-8 Protocolli pipeline (a finestra scorrevole) Pipelining: ci possono essere più pacchetti in volo, ancora da essere confermati m Più complesso m Gestione dei buffer sofisticata r Due forme di protocolli sliding window: go-Back-N, selective repeat

9 Realizzato da Roberto Savino 3-9 Ripetizione selettiva r I pacchetti corretti sono confermati INDIVIDUALMENTE m I pacchetti sono conservati in attesa che possano essere rilasciati in ordine r Il mittente rimanda solo I pacchetti non confermati m Cè un timer per ogni pacchetto in volo r Finestra del mittente m Range di numeri attivi

10 Realizzato da Roberto Savino 3-10 Ripetizione selettiva Ci sono dati nel buffer: r Mandali Timeout(n): r Rimanda il pacchetto n ACK(n) in [sendbase,sendbase+N]: r marca n come OK r Nel caso sposta la finestra in avanti di 1 sender pkt n in [rcvbase, rcvbase+N-1] r manda ACK(n) r Fuori ordine? Conserva r In ordine: consegna e sposta la finestra in avanti pkt n in [rcvbase-N,rcvbase-1] r ACK(n) (duplicato che non sembra confermato) altrimenti: r ignora receiver

11 Realizzato da Roberto Savino 3-11 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used Options (variable length) URG: Dati urgenti (non usato) ACK: Questo segmento trasporta un ACK PSH: dati ad alta priorità RST, SYN, FIN: Gestione Connessione Numero di byte che si è disposti ad accettare al massimo valori espressi in byte (non in numero di segmento) Checksum (come in UDP)

12 Realizzato da Roberto Savino 3-12 TCP Connection Management TCP necessità di aprire una connessione prima di trasmettere r Bisogna inizializzare le variabili: m Numeri di sequenza m Allocare I buffer, e la finestra di ricezione r client: colui che apre la connessione Socket clientSocket = new Socket("hostname","port number"); r server: colui che è contattato Socket connectionSocket = welcomeSocket.accept(); Handshake a tre vie: Step 1: Il client manda un TCP SYN al server m Indica il suo numero di seq. iniziale m no dati Step 2: Il server riceve la richiesta, replica con un pacchetto SYN/ACK m Specifica il suo numero di partenza m Alloca I suoi buffer (per sfortuna) Step 3: Il client riceve SYN/ACK, risponde con un ACK, che può contenere dati

13 Realizzato da Roberto Savino 3-13 Diagramma a stati TCP client lifecycle TCP server lifecycle

14 Realizzato da Roberto Savino 3-14 Come TCP decide il tempo di time- out D: come impostare questo valore? r deve essere più grande di RTT, ma non troppo m ma RTT varia r troppo corto: troppi falsi time-out m inutili ritrasmissioni r troppo lungo: reazione lenta alla perdita di un segmento D: Come stimare RTT? SampleRTT : tempo misurato di volta in volta tra una trasmissione e la ricezione dellACK corrispondente m Calcolato senza considerare casi di ritrasmissione SampleRTT è molto variabile è preferibile farne una media, senza usare solo il SampleRTT corrente.

15 Realizzato da Roberto Savino 3-15 Controllo di flusso r Ogni ricevitore ha un buffer di ricezione: r Lo svuotamento può essere più lento del flusso di arrivo Il mittente si controlla per non affogare il destinatario flow control

16 Realizzato da Roberto Savino 3-16 Come funziona il controllo di flusso (Per comodità supponiamo i segmenti fuori ordine non vengano conservati) Spazio libero nel buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] r Il ricevitore comunica lo spazio libero usando il campo RcvWindow Il mittente non eccede mai il numero di byte in volo rispetto al valore di RcvWindow m Il buffer di ricezione non andrà mai in overflow