Telematica di Base. Il livello di trasporto

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "Telematica di Base. Il livello di trasporto"

Marianna Zanella
5 anni fa
Visualizzazioni

1 Telematica di Base Il livello di trasporto

2 Trasporto: Servizi e Protocolli Fornisce un servizio di communicazione logica tra applicazioni di rete I protocolli di trasporto sono in esecuzione sugli host application transport logical end-end transport application transport 16/03/06 2

3 Trasporto: Servizi e Protocolli transport vs layer: traferimento di dati tra host transport layer: trasferimento di dati tra processi Si basa sui servizi forniti dal livello application transport logical end-end transport application transport 16/03/06 3

4 Transport-layer: Protocolli Quali sono i servizi di trasporto su Internet: Affidabile (unicast delivery -TCP) Non affidabile ( besteffort ), unordered unicast o multicast delivery: UDP Servizi non disponibili: real-time bandwidth reliable multicast application transport logical end-end transport application transport 16/03/06 4

5 Un primo servizio Network = trasferimento di dati tra host della rete Host identificato in modo univoco da un indirizzo IP Come si fa a traferire i dati ricevuti ai processi che li hanno richiesti? Indirizzi del livello di trasporto (Multiplexing demultiplexing) 16/03/06 5

6 Porte e processi Porta identifica in modo univoco un processo in esecuzione su di un host Porte di sistema (riservate): FTP 21, HTTP 80, RFC 1700 Applicazioni di rete Porte maggiori di /03/06 6

7 Indirizzo a livello del trasporto Definire la nozione di destinazione finale del livello di trasporto Indirizzo IP = indirizzo dell host di destinazione finale Numero della porta = indirizzo del processo sull host di destinazione finale 16/03/06 7

8 Multiplexing/demultiplexing host A source port: x dest. port: 23 server B Web client host C source port:23 dest. port: x telnet app Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web client host A Source IP: A Dest IP: B source port: x dest. port: 80 Web server Web server B 16/03/06 8

9 UDP: User Datagram Protocol [RFC 768] Protocollo di trasporto essenziale: servizio di tipo best effort perdite senza ordine connectionless: ogni segmento UDP è gestito in modo totalmente independente dagli altri segmenti Quando è necessario utilizzare UDP? Non c è la necessità di stabile una connessione Applicazioni semplici: non abbiamo bisogno di informazioni di stato Nessun controllo per evitare i problemi di congestione 16/03/06 9

10 UDP Multimedia Possono permettersi una perdita di informazione Chi utilizza UDP DNS Aggiungere un meccanismo di affidabilità ad UDP error recover al livello delle applicazioni Length, in bytes of UDP segment, including header 32 bits source port # dest port # length Application data (message) checksum UDP segment format 16/03/06 10

11 Trasferimento affidabile Punto importante nei livelli app., transport, link. Una delle problematiche piu importanti del ing 16/03/06 11

12 Reliable data transfer: RDT rdt_send(): invocata dal livello delle applicazioni deliver_data(): invia i dati ai livelli superiori send side receive side udt_send(): trasferire pacchetti su di un canale non affidabile rdt_rcv(): chiamata al momento della recezione dei pacchetti 16/03/06 12

13 Reliable data transfer: Esempio Trasferimento di dati (unidirezionale) Sender e receiver sono specificati da automi a stati finiti. event causing state transition actions taken on state transition state: when in this state next state uniquely determined by next event state 1 event actions state 2 16/03/06 13

14 Rdt1.0 Il canale di trasmissione è affidabile no bit errors no loss of packets Sender e receiver (fanno le ovvie cose!!) 16/03/06 14

15 Rdt2.0: errori di trasmissione Il canale può modificare il valore dei bit presenti nei pacchetti Come vengono determinati questi errori di trasmissione: acknowledgements (ACKs): receiver invia al sender un messaggio di recezione (senza errori) del pacchetto negative acknowledgements (NAKs): receiver invia al sender un messaggio di errore Sender trasmette nuovamente il pacchetto quando riceve un messaggio NAK 16/03/06 15

16 rdt2.0 sender FSM receiver FSM 16/03/06 16

17 rdt2.0: in action (no errors) sender FSM receiver FSM 16/03/06 17

18 rdt2.0: in action (error scenario) sender FSM receiver FSM 16/03/06 18

19 ACK/NACK corrotti sender non è in grado di sapere cosa è successo al receiver si possono duplicare i messaggi trasmessi sender aggiunge ad ogni pacchetto il sequence number Come rimediare? 16/03/06 19

20 rdt2.1: sender 16/03/06 20

21 rdt2.1: receiver 16/03/06 21

22 rdt2.1 Sender: Pacchetti con numero di sequenza (basta un solo bit di informazione) Stati: In ogni stato si deve ricordare il numero di sequenza (0 o 1) Receiver: Deve controllare se il pacchetto è duplicato Ogni stato mantiene informazione su quale numero di sequenza si attende 16/03/06 22

23 rdt2.2: Protocollo NAK-free rdt2.1 + soli ACK receiver deve esplicitamente inviare il numero di sequenza. ACK duplicati = NAK! sender FSM 16/03/06 23

24 rdt3.0: Canali con errori e perdita di pacchetti Ipotesi aggiuntive: Il canale di trasmissione può perdere pacchetti (dati o ACK) checksum, seq. #, ACK, sono sufficienti? Come si gestisce la perdita di pacchetti? sender attende un certo periodo di tempo prima di trasmettere nuovamente l informazione Una possibile soluzione: sender rimane in attesa per un periodo di tempo ragionevole I pkt vengono trasmessi nuovamente se non viene ricevuto un ACK in questo periodo di tempo Se la consegna del pkt (ACK) è solo ritardata (non avviene perdita) Duplicazione: gestita tramite il # di sequenza receiver specifica il # di sequenza del pkt ricevuto 16/03/06 24

25 rdt3.0 sender 16/03/06 25

26 rdt3.0: Il comportamento 16/03/06 26

27 rdt3.0: Il comportamento 16/03/06 27

28 Errori di trasmissione e perdita di pacchetti Feedback ACK -- NACK Coordinamento sender-receiver Numeri di sequenza Timer Controllo perdita di pacchetti 16/03/06 28

29 Stop-and-wait vs Pipeline Pipelining: il mittente invia un certo numero di pacchetti senza attendere il relativo ACK Operare correttamente con i # di sequenza Buffer (mittente e destinatario) 16/03/06 29

30 Sender, receiver windows 16/03/06 30

31 Selective repeat sender data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq # receiver pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, inorder pkts), advance window to next not-yetreceived pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore 16/03/06 31

32 Selective repeat 16/03/06 32

Documenti analoghi

Argomenti: ! Servizi dello strato di trasporto! multiplexing/demultiplexing! Servizio senza connessione: UDP

Argomenti: ! Servizi dello strato di trasporto! multiplexing/demultiplexing! Servizio senza connessione: UDP Strato di trasporto Obiettivi:! Comprendere i principi dei servizi dello strato di trasporto: " multiplexing/demultipl exing " Trasferimento affidabile dei dati " Controllo di flusso " Controllo di congestione!