 |
Supernick |
.tritagranchi.
Registered: Jan 2008
Posts: 323 (0.05 al dì)
Location: Albairate (MI)
Corso: Comunicazione Digitale
Anno: 3°
Time Online: 1 Day, 17:31:17 [...]
Status: Offline
Edit | Report | IP: Logged |
Per la prima non son molto daccodo...si sta parlando di flusso, non di congestione (due cose ben distinte).
TCP gestisce il flusso mantenendo della variabili che indicano lo spazio libero nei buffer di invio e di ricezione.
Più nel dettaglio, il ricevente ha una variabile di questo tipo chiamata RcvBuffer (receive buffer) che indica la dimensione totale del buffer, e se indichi con LastByteRead, l'ultimo byte che è stato letto e gia scartato dal buffer, e LastByteRcvd i dati che devono ancora essere letti e che quindi devono vengono copiati nel buffer, deve essere che:
LastByteRcvd - LastByteRead <= RcvBuffer
Quindi x esempio se il buffer ha ricevuto 15 byte e ne ha letti 5 (e successivamente scartati), lo spazio occupato è di 10 byte, e logicamente deve essere minore della dimensione totale del buffer, mentre lo spazio libero 5 byte, indicato dalla variabile RcvWindow.
Dal lato dell'invio invece non ci sono byte letti o ricevuti, ma solo byte riscontrati (LastByteAcked) (l'ACK è arrivato insomma e quindi si possono togliere dal buffer) e quelli inviati ma non ancora riscontrati (LAstByteSent) (vanno ancora tenuti nel buffer, fin che non vengono riscontrati), la storia è un po' diversa
LastByteSent - LastByteAcked <= RcvWindow
Questo serve per far si che il mittente non invii più byte di quanti la RcvWindow ne possa contenere (x es, non ti invio 15 byte se ha solo 10 byte di spazio libero)
Rammenta che l'host mittente deve essere informato dal ricevente di quando egli svuota i buffer, altrimenti pensa che questo è sempre pieno
Per la seconda invece non saprei, noi con Maggiorini abbiam visto in particolare il RIP ma non l'OSPF
Spero comunque di esserti stato utile, ricordati soprattutto (FLUSSO!=CONGESTIONE, flusso tra due host, congestione tutta la rete)
Nick
|
asterix07
