Eserciziario di Reti di Calcolatori
Università degli Studi di Padova, a.a. 2004-05, prof. Satta
Testo:
Il mittente di una connessione TCP che riceva la comunicazione di una finestra di dimensione zero stimola periodicamente il ricevitore per scoprire se la finestra ha assunto dimensione diversa da zero. Perché il ricevitore avrebbe bisogno di un temporizzatore supplementare nel caso in cui avesse il compito di segnalare al mittente che la propria finestra è diventata di dimensione diversa da zero (cioè se il mittente non stimolasse il ricevitore)?
Risoluzione:
Ogni qual volta l'entità ricevente pubblicizza una finestra di dimensione zero, la parte mittente continua ad inviare periodicamente un segmento con un byte di dati, pur sapendo che probabilmente questi dati non verranno accettati; ma ci prova comunque perchè ognuno di questi segmenti richiede una risposta che contiene la finestra attualmente pubblicizzata. Prima o poi uno di questi byte darà luogo ad una risposta che porta la finestra ad una dimensione diversa da zero.
Se il mittente non stimolasse periodicamente il ricevitore, non avrebbe modo di sapere che la finestra non ha più dimensione zero. Quindi in tal caso sarebbe necessario introdurre un temporizzatore nel ricevente; scaduto il tempo viene inviato un messaggio al mittente, comunicando che se la finestra ha una dimensione diversa da zero. La prima soluzione è conosciuta come "regola del mittente intelligente e del ricevitore stupido"; nel secondo caso è il ricevitore a dover farsi carico della comunicazione.
Testo:
Il campo del numero di sequenza nell'intestazione TCP è lungo 32 bit, una dimensione sufficiente a gestire più di 4 miliardi di byte di dati. Come mai il numero di sequenza può comunque passare dal numero di sequenza 232 - 1 al valore 0, anche se lungo una singola connessione non è mai stato trasferito un numero di byte così elevato?
Risoluzione:
La quantità di dati necessaria per far passare il SeqNumber da 232 - 1 a 0, se non vi è un trasferiento di dati di almeno 232 - 1 byte, può avvenire solamente se il punto di inizio da cui cominciare a conteggiare i SeqNum non è 0 ma un numero maggiore di 0. Questo può realmente accadere perché il protocollo di trasmissione TCP attraverso il three-way handshake prevede che gli host che vogliano comunicare fra loro, al momento dell'instaurazione della connessione si accordino su un insieme di parametri, tra i quali i numeri iniziali di sequenza. Il SeqNumber iniziale da cui cominciare a conteggiare i segmenti viene selezionato random, alfine di evitare conflitti, cioè per proteggere il protocollo dal fatto che due successive incarnazioni della stessa connessione utilizzino troppo presto gli stessi sequence number, mentre c'è ancora la possibilità che un segmento di una precedente incarnazione della connessione possa interferire con l'incarnazione successiva.
Testo:
Vi è stato assegnato il compito di progettare un protocollo affidabile a flusso di byte che usi l'algoritmo slding window (come TCP). Il protocollo verrà eseguito in una rete a 100 Mbps, con RTT di 100 ms e MSL di 60 secondi.
a) Quanti bit inserireste nei campi AdvertisedWindow e SequenceNum dell'intestazione del vostro protocollo?
b) Come determinereste i numeri forniti al punto precedente e quali valori sarebbero più incerti?
Risoluzione:
a) Il modo per scegliere l'ampiezza della AdvertisedWindow è semplice: visto che bisogna tenere il canale pieno, trasmetto al massimo della sua capacità non aspettando l'Ack di ogni pacchetto per trasmettere il successivo. Quindi:
Capacità = Banda x RTT = 100 x 100 = 10 Mb = 1,25 MB
MaxBufferSize = 1,25 MB.
1,25 MB si può esprimere con 221 = 2,1 MB quindi bastano 21 bit nel campo AdvertisedWindow del segmento TCP.
Il campo SequenceNum deve essere ampio abbastanza da consentire di esprimere i numeri di sequenza necessari alla trasmissione senza incorrere nel problema del wraparound (ritorno al valore iniziale).
Se pensassimo a due host point-to-point e non considerassimo il valore di MSL, che esprime quanto rimane attivo un segmento nella rete prima di essere eliminato, il calcolo del massimo numero di sequenza si otterrebbe semplicemente dai vincoli imposti dall'algoritmo di sliding window:
(MaxSequenceNum + 1) / 2 > SenderWindowSize
nel nostro caso:
AdvertisedWindow = SenderWindowSize
quindi deve valere almeno:
2 x AdvertisedWindow = MaxSequenceNum
2 x 221 = 222
quindi ci servirebbero solo 22 bit nel campo SequenceNum.
Nel nostro caso, invece, i due host non sono point-to-point e quindi è necessario considerare il MSL.
Calcoliamo in un MSL quanti byte posso inoltrare nella rete:
Banda x MSL = QntDati
100 x 60 = 6 Gb = 750 MB
Nel momento in cui muore un pacchetto ho altri 750 MB; quindi devo fare in modo che non ci sia superamento di sequence number. Per la quantità di dati trasmessa bastano 30 bit, infatti 230 = 1024 MB > 750 MB.
In definitiva saranno quindi necessari 30 bit nel campo SequenceNum.
b) Uno dei valori più incerti è il tempo di vita di un pacchetto, perché per determinarlo si utilizzerà probabilmente un TimeStamp. Ma i Router non sono sincronizzati e quindi un router non sa quanti secondi sono effettivamente già passati.