In questa lezione analizzeremo il protocollo Send and Wait, uno dei meccanismi fondamentali per il controllo del flusso e degli errori nel livello Data Link.
Esploreremo il suo funzionamento base, analizzando nel dettaglio i vincoli di efficienza e i limiti che ne condizionano l'utilizzo nelle reti moderne.
Nella lezione precedente abbiamo posato le fondamenta logiche dell'architettura ARQ (Automatic Repeat reQuest). Sappiamo che per ottenere una trasmissione affidabile ci servono il Checksum per gli errori, l'ACK per la conferma, l'RTO per i Timeout e i Numeri di Sequenza per arginare i duplicati. La combinazione più elementare, storica e basilare di questi quattro elementi genera il protocollo conosciuto in ingegneria come Send and Wait (o Stop and Wait).
Questo protocollo rappresenta il "battesimo" dello studente di reti: è concettualmente perfetto e garantisce un'affidabilità matematica del 100%, ma nasconde un difetto prestazionale talmente catastrofico da renderlo inutilizzabile sulle moderne infrastrutture a banda larga. In questa lezione dissezioneremo la logica del protocollo e useremo la matematica per dimostrare perché fallisce nel mondo reale.
Il funzionamento del protocollo Send and Wait è racchiuso interamente nel suo nome: "Invia e Aspetta". Il software del mittente estrae un blocco di dati, gli applica un'intestazione (creando il Segmento), lo inietta nella scheda di rete e poi si ferma istantaneamente .
Il mittente entra in uno stato di blocco totale (blocking state). Non accetterà nuovi dati dall'applicazione e non invierà alcun nuovo pacchetto finché non si verifica una di queste due condizioni:
1. Riceve l'ACK corretto dal ricevitore (il che gli dà il "semaforo verde" per inviare il pacchetto successivo).
2. Il timer di Timeout scade a zero, costringendolo a ritrasmettere lo stesso identico pacchetto.
Se il Send and Wait è così facile da programmare (basta un flag a 1 bit) e offre garanzie granitiche contro la perdita di dati, perché i moderni sistemi operativi si rifiutano di usarlo per scaricare i file? La risposta risiede nel calcolo delle prestazioni.
Per comprendere l'inefficienza, dobbiamo isolare due metriche fisiche della rete:
1. Ritardo di Trasmissione (Transmission Delay): È il tempo meccanico/elettronico che la scheda di rete impiega per "spingere" tutti i bit del pacchetto sul cavo di rame o sulla fibra. Dipende solo dalla velocità del modem (es. Gigabit o Megabit).
[tooltip]L'RTT (Round Trip Time) è il tempo fisico impiegato da un bit per viaggiare dal tuo PC fino al server estero, sommato al tempo che impiega la risposta per tornare indietro. È dettato dalla velocità della luce e dalla distanza geografica. Nel gergo dei videogiochi multiplayer, l'RTT è comunemente chiamato "Ping".[/tooltip]Facciamo un calcolo ingegneristico spietato. Supponiamo che la tua scuola abbia appena installato una modernissima linea in Fibra Ottica a 1 Gigabit al secondo (1.000.000.000 bit/s). Vuoi scaricare un file da un server situato a New York (l'RTT per attraversare l'Oceano Atlantico andata e ritorno è di circa 100 millisecondi).
Calcolo dell'inefficienza: Un pacchetto Ethernet standard contiene 1500 byte (che equivalgono a 12.000 bit). Con la tua potentissima fibra a 1 Gigabit, il Ritardo di Trasmissione per "pompare" questi 12.000 bit sul cavo è di appena 0,012 millisecondi. Se usiamo il protocollo Send and Wait, il tuo PC trasmette il pacchetto in 0,012 ms e poi si BLOCCA. Deve aspettare in silenzio assoluto per 100 millisecondi (l'RTT) finché l'ACK da New York non attraversa l'oceano per dargli il via libera.La formula dell'Efficienza (o Utilizzo del Canale) si calcola dividendo il tempo in cui la scheda di rete lavora effettivamente, per il tempo totale del ciclo.
Efficienza = 0,012 / (100 + 0,012) = 0,00012.
In termini percentuali, l'utilizzo del canale è dello 0,012%. Questo significa che, pur pagando al provider una costosissima fibra ottica da 1 Gigabit, la tua velocità effettiva di download sarà ridicola (circa 120 Kilobit al secondo, come i vecchi modem 56k degli anni '90). Per il 99,98% del tempo, la tua fibra ottica rimane letteralmente vuota e inutilizzata, in attesa del semaforo verde.
Questo collo di bottiglia strutturale è noto in ambito accademico come il problema del Bandwidth-Delay Product (Prodotto Banda-Ritardo) sulle reti LFN (Long Fat Networks). Una rete è "Grassa" (Fat) quando ha un'enorme larghezza di banda, ed è "Lunga" (Long) quando ha una grande latenza, come le connessioni satellitari o intercontinentali.
Il protocollo Send and Wait è efficiente SOLO se usato su reti dove l'RTT è pari a zero. Negli anni passati veniva utilizzato sui vecchi cavi stampante paralleli lunghi un metro, dove il tempo di risposta del dispositivo era istantaneo. Sul pianeta Internet, dove i server distano migliaia di chilometri, il Send and Wait è architetturalmente insostenibile e collassa sotto il peso dei suoi stessi tempi morti.
Il protocollo Send and Wait ci insegna una lezione magistrale: l'affidabilità assoluta ha un costo pesantissimo in termini di prestazioni. Costringendo la scheda di rete a inviare un solo pacchetto e fermarsi, si elimina la complessità di riordinare i pacchetti a destinazione e si riduce il Sequence Number a 1 solo bit (0-1), ma si uccide l'efficienza matematica del mezzo trasmissivo, sprecando il 99% della banda disponibile a causa della latenza (RTT) che separa i continenti.
Per misurare quanto il vincolo fisico del Send and Wait sia scolpito nella roccia, risolvi questo scenario estremo: sei un ingegnere aerospaziale e stai comunicando con un rover su Marte. Immaginiamo che il tuo trasmettitore laser abbia una banda infinita (può inviare qualsiasi file istantaneamente). Tuttavia, il tempo di viaggio andata-ritorno (RTT) del segnale radio tra la Terra e Marte è di 20 minuti (1200 secondi). Se il tuo software usa rigidamente il protocollo Send and Wait senza modifiche, qual è il numero ASSOLUTO massimo di pacchetti (indipendentemente dalla loro grandezza) che potrai inviare al rover nell'arco di un'intera ora?
Contatti Supportaci Chi siamo Cookies
La possibilità di poter ascoltare l'audio è offerto da ResponsiveVoice-NonCommercial
licensed under
Questo sito è un'idea di Francesco
Statistics