MECCANISMO FINESTRE SCORREVOLI . AIUTO !!!!

[leon84]

Non riesco a capire una cosa .... Ho letto il documento su Networkingitalia .... Ad un certo punto fa un esempio grazie al quale dimostra l'inefficienza di questo meccanismo e dice : Supponiamo che si inviino i pacchetti 1-2-3-4 e 5 ... Il due viene perso e quindi al trasmittente arriveranno gli ack del 1 , 3, 4 e 5 tutti uguali indicando che l'ultimo pacchetto ricevuto è il numero 1 . Ora non capisco una cosa ... se l'ack è sempre uguale al sequencer number del pacchetto inviato + 1 , come fa poi il ricevente ad inviare per i pacchetti 3 - 4 e 5 lo stesso ack di 1 ? Mi spiegate per favore ? Grazie infinite

[leon84]

Possibile che nessun ne sa niente ?

[gohan]

sinceramente non è chiarissima la spiegazione......

[leon84]

Originally posted by "gohan"

sinceramente non è chiarissima la spiegazione......

Allora ci riprovo : nel meccanismo delle finestre scorrevoli se ad esempio si inviano 5 pacchetti e questi giungono tutti a destinazione si otterranno 5 ack ( che sono relativi a ciascuno dei pacchetti inviati ) . In realtà vengono inviati gli ack fino al pacchetto che giunge a destinazione correttamente . Ciò vuol dire che se dei 5 pacchetti il 3 si perde io otterò i seguenti 4 ack 1 per il primo pacchetto , 2 per il secondo , per il terzo nulla perché è andato perso , per il 4 l'ack del 2 , e per il 5 l'ack del 2 . Cioè in realtà l'ack non mi dice chi è andato perso , ma mi indica soltanto l'ultimo pacchetto che è stato ricevuto prima ce uno se ne perda... Ora volevo sapere perché ? Se l'ack è uguale al sequencer number del pacchetto inviato + 1 perché se se ne perde 1 gli ack degli altri sono gli stessi ? Spero di essere stato chiaro altrimenti ti posto proprio il documento da dove l'ho letto ... Anzi lo faccio ora :

Consideriamo ora qualche caso particolare.

Se il pacchetto 2 non arrivasse a destinazione, la finestra non verrebbe spostata oltre il pacchetto 1. Il destinatario manderebbe gli Ack dei pacchetti 3, 4, 5... ma tutti uguali, cioè settati al valore 1, dato che è il questo l'ultimo pacchetto valido, ricevuto nell'ordine di consegna. Ad un certo punto il timer per 2 scade e il pacchetto viene ritrasmesso. A questo punto però sorge una domanda: dobbiamo ritrasmettere anche 3, 4, 5... ? Purtroppo non possiamo saperlo. Se mandiamo solo 2, ma anche 3, 4, 5... sono andati persi dovremo aspettare che scadano i timer di tutti questi altri segmenti. Alternativamente possiamo rimandare tutta la finestra. E' comunque chiaro che nessuna soluzione è priva di inefficienze, perchè l'informazione del campo Ack non è sufficientemente espressiva: non dice nulla del frame ricevuto, dice solo qual'è l'ultimo frame valido ricevuto nell'ordine di consegna.  Altra caso particolare: il pacchetto 2 viene ricevuto correttamente, ma è l'Ack che viene perso. Semplicemente, il mittente riceverà prima o poi un Ack con valore 3, questo indica che tutti i pacchetti fino al terzo sono arrivati a destinazione, quindi anche il secondo. Dopo l'Ack 3 il mittente può spostare la finestra in avanti di 2 passi in una volta. La finestra ora coprirà i pacchetti da 4 a n+3. Nella realtà, per identificare i segmenti si usa il Sequence number non il numero di pacchetto (vedi la def. di Sequence number, nell'header TCP). Inoltre l'ampiezza della finestra è variabile da parte del ricevente durante la connessione grazie al campo Window.

[rudiger]

Per quanto ne so io, TCP invia un pacchetto di ack cumulativo per il numero di sequenza dell'ultimo pacchetto ricevuto corrattamente ed in sequienza corretta. Cioè se ha ricevuto i pacchetti 1,2,3,4,6,7,8 il TCP, quando deciderà di mandare un ack (non è detto che lo faccia ogni pacchetto ricevuto) manderà un ack con il numero 5, perchè è 5 il prossimo pacchetto che si aspetta per completare la sequenza. Se il 5 continua a non arrivare il ricevente continua a mandare sempre l'ack 5 (ecco il motivo degli ack ripetuti). Appena arriva il pacchetto 5, il ricevente manderà l'ack 9 perchè ha già 6,7,8 nel buffer.
Correggetemi se ho detto sciocchezze.

[leon84]

Originally posted by "rudiger"

Per quanto ne so io, TCP invia un pacchetto di ack cumulativo per il numero di sequenza dell'ultimo pacchetto ricevuto corrattamente ed in sequienza corretta. Cioè se ha ricevuto i pacchetti 1,2,3,4,6,7,8 il TCP, quando deciderà di mandare un ack (non è detto che lo faccia ogni pacchetto ricevuto) manderà un ack con il numero 5, perchè è 5 il prossimo pacchetto che si aspetta per completare la sequenza. Se il 5 continua a non arrivare il ricevente continua a mandare sempre l'ack 5 (ecco il motivo degli ack ripetuti). Appena arriva il pacchetto 5, il ricevente manderà l'ack 9 perchè ha già 6,7,8 nel buffer.
Correggetemi se ho detto sciocchezze.

Allora dovrebbe essere così ? A volte ci sono certe cose che fanno veramente perdere la testa ....