Article on other languages:
 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
Il controllo di flusso oltre il controllo della congestione è un tipo di controllo che viene effettuato da alcuni protocolli di comunicazione, come ad esempio TCP. Tale controllo viene effettuato per evitare che un mittente invii una eccessiva quantità di dati che potrebbero, in alcune situazioni, mandare in overflow il buffer di ricezione del destinatario. Questo controllo risulta essere particolarmente utile per il mantenimento delle prestazioni della connessione
Funzionamento
In uno scenario comune di connessione tcp abbiamo un host mittente A e un host ricevente B, entrambi questi host impostano dei buffer di ricezione. Il processo applicativo associato leggerà i dati da questo buffer ma non è detto che lo faccia nel momento in cui arrivano, magari perché è impegnato in un altro compito e magari leggerà i dati in un tempo successivo. Se l'applicazione è lenta nella lettura dei dati può accadere che il mittente mandi in overflow il buffer di ricezione inviando i dati troppo rapidamente. Il TCP offre un servizio di controllo di flusso per evitare questi inconvenienti.
Il TCP offre il controllo di flusso facendo mantenere al mittente una variabile chiamata finestra di ricezione (receive window) che fornisce al mittente un'indicazione sullo spazio libero disponibile nel buffer del destinatario. Dato che il TCP è un protocollo full-duplex i due mittenti mantengono finestre di ricezione distinte.
Definiamo ora delle variabili:
- LastByteRead : Numero dell'ultimo byte nel flusso di dati letto dal processo applicativo in B.
- LastByteRcvd : Numero dell'ultimo byte copiato nel buffer di ricezione di B.
Dato che il TCP non può fuoriuscire dal buffer allocato, dobbiamo avere:
- LastByteRcvd - LastByteRead <= RcvBuffer.
La finestra di ricezione chiamata RcvWindow verrà quindi impostata alla quantità di spazio disponibile nel buffer :
- RcvWindow = RcvBuffer - [LastByteRcvd - LastByteRead]
Visto che lo spazio disponibile varia con il tempo la dimensione di RcvWindow è dinamica.
Quindi l'Host B comunica ad A quanto spazio ha a disposizione nel proprio buffer posizionando il valore corrente di RcvWindow nel campo finestra di ricezione dei segmenti che manda ad A. A sua volta l'host A mantiene due variabili che sono LastByteSent e LastByteAcked (ultimo byte inviato, ultimo byte riscontrato) la differenza tra questi due valori indica la quantità di dati inviati e non ancora riscontrati da A nella connessione. Mantenendo quindi la differenza LastByteSent-LastByteAcked <= RcvWindow si garantisce che l'host A non mandi in overflow il buffer di ricezione dell'host B. Può capitare, però, che il buffer di B si riempia e, come conseguenza, l'host A rimanga bloccato e non possa trasmettere ulteriori dati. Per risolvere tale problema, Il TCP fa sì che l'host A continui ad inviare segmenti costituiti da un byte di soli zero quando la finestra di ricezione di B è zero. Questi segmenti verranno scartati fino a quando il buffer di B non inizi a svuotarsi. Una volta svuotato il buffer, l'host A riceverà dei riscontri non nulli della RcvWindow di B e da lì continuerà ad inviare (se ci sono ancora) dati all'host B.
