[Didattico] TCP ed Interfaccia a Stream

[Neptune]

Ciao a tutti,
sto studiando il tcp e nelle slide c'è un punto che non mi è tanto chiaro, ovvero dice che il tcp sfrutta un interfaccia a stream, ovvero una sequenza continua di bytes. Fin qui tutto chiaro. So anche che questa sequenza in realtà viene spezzettata dal protocollo stesso per farla entrare in un pachetto ip. Poi però dice, riporto fedelmente "Nessuna garanzia che i dati arrivano negli stessi blocchi con cui sono stati spediti".

Cioè che significa? Posso capire che i blocchi in cui spezzetto lo strem possono arrivare disordinati (perchè magari fanno percorsi differenti o trovano la rete intasato o altre e mille motivi)), ma che cosa significa che i dati non arrivano negli stessi blocchi con cui sono stati spediti?!? che fanno i dati se ne vanno a spasso?! Oppure mi sfugge qualcosa?

Vi ringrazio in anticipo,
Neptune.

[MItaly]

TCP fornisce ai livelli superiori un'interfaccia a stream (ovvero, le applicazioni "sopra" lavorano con un flusso continuo di dati), e lo spezza in pacchetti per passarlo al protocollo IP (suo livello sottostante).

Per come funziona IP, non c'è nessuna garanzia che dall'altra parte i pacchetti arrivino nell'ordine in cui sono stati spediti (e alcuni si potrebbero anche perdere), per cui il protocollo TCP deve essere in grado di gestire queste situazioni senza che ai livelli superiori si rompa l'illusione di star lavorando con un flusso continuo di dati.
Per fare questo da un lato il software TCP del destinatario ha un qualche buffer in cui va ad inserire temporaneamente i pacchetti che gli arrivano, perché, se non è ancora arrivato il pacchetto 4 ma sono arrivati il 5 e il 6, TCP non può passare il 5 e il 6 all'applicazione, ma deve aspettare che arrivi il 4 per poter fornire il flusso di dati nell'ordine in cui è stato scritto dal mittente. Ci sono inoltre tutta una serie di meccanismi di acknowledgment, timeout, checksum & co. per fare in modo che se un pacchetto risulta perso o corrotto il mittente lo spedisce nuovamente per fare in modo che la connessione "virtuale" tra le due applicazioni non risulti corrotta.

[Neptune]

Originariamente inviato da MItaly
TCP fornisce ai livelli superiori un'interfaccia a stream (ovvero, le applicazioni "sopra" lavorano con un flusso continuo di dati), e lo spezza in pacchetti per passarlo al protocollo IP (suo livello sottostante).

Per come funziona IP, non c'è nessuna garanzia che dall'altra parte i pacchetti arrivino nell'ordine in cui sono stati spediti (e alcuni si potrebbero anche perdere), per cui il protocollo TCP deve essere in grado di gestire queste situazioni senza che ai livelli superiori si rompa l'illusione di star lavorando con un flusso continuo di dati.
Per fare questo da un lato il software TCP del destinatario ha un qualche buffer in cui va ad inserire temporaneamente i pacchetti che gli arrivano, perché, se non è ancora arrivato il pacchetto 4 ma sono arrivati il 5 e il 6, TCP non può passare il 5 e il 6 all'applicazione, ma deve aspettare che arrivi il 4 per poter fornire il flusso di dati nell'ordine in cui è stato scritto dal mittente. Ci sono inoltre tutta una serie di meccanismi di acknowledgment, timeout, checksum & co. per fare in modo che se un pacchetto risulta perso o corrotto il mittente lo spedisce nuovamente per fare in modo che la connessione "virtuale" tra le due applicazioni non risulti corrotta.

Perfetto, quindi quello che mi ero perso era quindi che i livelli superiori hanno un interfaccia a stream, difatti nel concreto mando un messaggio lungo millemila byte senza preoccuparmene, mentre ovviamente il tcp che si occupa lui della segmentazione suddivide il tutto in blocchi per il livello inferiore. Ed ovviamente non è detto che arrivi tutto in maniera ordinata.

Per quest'ultimo punto, correggimi se sbaglio, leggevo dell'algoritmo a finestra scorrevole. Questo algoritmo se non erro serve sia per garantire l'affidabilità grazie agli acknowledgment, garantisce anche il controllo del flusso perchè trasmettendo la grandezza della finestra si evita di saturare il buffer del ricevente. Infine garantisce l'inoltro ordinato dei dati perchè "Se qualcosa non mi arriva non mando l'ack e mi viene reinviata, se qualcosa non mi arriva in mezzo in mezzo (del tipo mi arriva 1 e 3 e non 2) io mando l'ack per 1, mi viene reinviato il 2 e dato che il 3 ce l'ho mando direttamente ack 3 (sempre se nel mentre non scade il timeout). Tutto giusto?

[MItaly]

Il concetto mi pare sia quello, poi i dettagli non li ricordo esattamente (ho lì un librone di TCP/IP che studio di tanto in tanto, ma è un po' che non lo guardo ).

[MatCap83]

Originariamente inviato da MItaly
TCP fornisce ai livelli superiori un'interfaccia a stream (ovvero, le applicazioni "sopra" lavorano con un flusso continuo di dati), e lo spezza in pacchetti per passarlo al protocollo IP (suo livello sottostante). [...]

Ottima spiegazione MItaly e direi anche molto accademica ...

[MItaly]

Grazie!