Gli eventi

Possiamo suddividere gli eventi a cui deve fare fronte il modulo TCP in

• eventi prodotti da una applicazione dello strato superiore,

• eventi prodotti dal modulo IP, e

• eventi di timeout.

Li vediamo in qualche dettaglio: per una descrizione pi`u approfondita rimando all’RFC793 [2].

Gli eventi prodotti dall’applicazione possono essere caratterizzati dai parametri di una chiamata di funzione: al solito, questo `e solo un modo per rappresentare una interfaccia.

OPEN (local port, foreign socket, active/passive)

⇒ local connection name – richiede l’apertura della connessione.

Si distingue in active e passive. La prima corrisponde all’azione del client che richiede un servizio ad un server che considera gi`a attivo, mentre la seconda corrisponde all’azione del server che offre un servizio, senza ancora prestarlo.

L’operazione di OPEN conduce sino allo stato ESTAB, e prende come parametri necessari la porta locale su cui si vuole instaurare la connessione, il socket remoto, e la modalit`a di apertura.

Nel caso la modalit`a sia passiva, l’apertura della connessione risulta bloc-cante, in attesa di una apertura dall’altro lato.

Nel caso la modalit`a sia attiva, l’operazione termina con successo se la connessione viene stabilita entro il timeout dato, altrimenti fallisce.

La connessione che viene restituita rappresenta una coppia di socket.

SEND (local connection name, buffer address, byte count, PUSH flag, URGENT flag) – richiesta di spedizione di un segmento.

Se viene indicato il flag PUSH, i dati vengono immediatamente trasmessi al destinatario (insieme agli altri accumulati nel buffer), ed il bit PUSH viene attivato nell’ultimo segmento inviato.

Se viene indicato il flag URGENT, i segmenti avranno il flag corrispondente attivato.

Nell’RFC dedicato al protocollo TCP [2], vengono esaminate diverse alterna-tive per le caratteristiche non funzionali della SEND: in particolare, se debba o meno essere bloccante, se si debba verificare o meno un rendez-vous tra le applicazioni. Noi ci limitiamo a portare un esempio di una implementazione ormai dominante, i socket BSD-UNIX. In questa, la SEND non `e bloccante.

RECEIVE (local connection name, buffer address, byte count)

⇒ byte count, urgent flag, push flag – ricezione di un segmento.

Nell’RFC [2] viene specificato che il flag di PUSH va passato all’applicazione.

Questo non `e strettamente necessario, e [10] lo afferma facoltativo (paragra-fo 4.2.2.2). `E invece importante che la segnalazione URG venga recapitata all’applicazione destinataria ([10] paragrafo 4.2.2.4): in realt`a l’applicazio-ne dovrebbe essere immediatamente informata (tramite una trap o simile) della presenza di dati urgenti, e quindi continuer`a a leggere segmenti sino a trovare quello contenente il flag, e tutti quelli con lo stesso flag attivo.

Anche in questo caso, l’RFC lascia notevole libert`a nell’interpretare le ca-ratteristiche non funzionali della RECEIVE.

CLOSE (local connection name) – chiusura della connessione.

La chiusura si intende sempre morbida: i dati relativi a SEND gi`a richieste verranno completati, ed eventuali future RECEIVE verranno pure ricevute, sino alla CLOSE del partner.

Come abbiamo visto, l’operazione di chiusura non `e istantanea: oltre a dover svuotare i buffer (una CLOSE implica sempre un’operazione di flush), la connessione rimarr`a ancora attiva per il tempo necessario a non avere pi`u messaggi obsoleti in circolazione.

STATUS (local connection name) ⇒ status data – restituisce informa-zioni relative allo stato della connessione, in parte contenute o derivate dal TCB.

ABORT (local connection name) – richiede l’interruzione della connessio-ne, con la perdita dei segmenti la cui trasmissione era incompleta.

L’evento prodotto dallo strato inferiore coincide con l’arrivo di un nuovo segmento: nel descrivere i protocolli di apertura e chiusura abbiamo trattato tutti gli eventi di questo tipo che rientrano nel funzionamento nor-male del protocollo. Abbiamo invece trascurato i casi in cui gli eventi si pre-sentino “al momento sbagliato”, probabilmente causati da malfunzionamenti hardware o errori di implementazione.

Tralasciando dunque i casi di inconsistenza (per una trattazione esaustiva si rimanda a [2]), il segmento generico verr`a trattato controllandone la consi-stenza rispetto alla finestra, ed inserendolo in una coda di ricezione ordinata rispetto al numero d’ordine. In caso di sovrapposizione tra segmenti, viene trattenuto il valore del segmento successivo.

Infine gli eventi di timeout sono i seguenti:

USER TIMEOUT Si tratta di un timeout controllato dall’applicazione: al suo scadere si opera in modo simile ad un ABORT.

RETRANSMISSION TIMEOUT L’evento `e determinato dalla mancata restituzio-ne del riscontro per un segmento spedito. Si risponde comunque rispedendo il primo segmento nella coda di ritrasmissione.

TIME-WAIT TIMEOUT L’evento si presenta nel corso della chiusura della con-nessione, e corrisponde all’attesa di 2 ∗ MSL prima dell’effettiva distruzione del TCB.

Esercizi

• La transizione dallo stato SYN-SENT allo stato SYN-RCVD pu`o accadere solo in un caso particolare: quale?

• Che vantaggi si ottengono “raddoppiando” una connessione per trasferire dati ad una velocit`a superiore? Descrivete la struttu-ra dell’applicazione che utilizza questa tecnica. Quante porte utilizza? Come le utilizza?

• Una linea transatlantica lunga 2000 Km `e caratterizzata da una capacit`a di 100 Mbps. Qual `e il tempo necessario a trasferire un ottetto dalla stazione di partenza a quella di arrivo, se la velocit`a nel cavo `e il 90% di quella della luce? Cosa succede quando, in una connessione TCP, viene perduto un segmento?

Come `e opportuno configurare le finestre?

TCP e UDP dal punto di vista dell’applicazione

Nei capitoli precedenti abbiamo visto le caratteristiche funzionali dei proto-colli di trasporto di Internet: TCP e UDP. Il punto di vista adottato era quello degli RFC, cio`e di chi specifica le funzionalit`a e l’implementazione del protocollo, non di chi ne utilizza le funzionalit`a.

In questo capitolo invece consideriamo l’interfaccia offerta dallo strato trasporto ai processi utente che realizzano le applicazioni. Il punto di vista

`e quello del programmatore che deve utilizzare le primitive offerte dal livello trasporto per scrivere il codice dell’applicazione.

Ogni sistema operativo ed ogni linguaggio offrono una propria definizione dell’interfaccia alle funzionalit`a di trasporto, e quindi `e opportuno limitarsi ad un caso: presenteremo le primitive offerte dalla libreria C di GNU. Si tratta di software di pubblico dominio, che `e portabile su tutte i sistemi operativi UNIX ed `e adattabile anche ad altri sistemi operativi. Gli esempi che vedremo nel seguito sono stati realizzati per la piattaforma Linux.

Avvertenza Non `e tra gli obiettivi di questo testo fornire gli elementi del linguaggio C necessari a comprendere il contenuto di questo capitolo. D’al-tra parte, gli elementi di C propedeutici sono abbastanza superficiali: serve conoscere la sintassi di base del linguaggio, le direttive per l’inclusione di intestazioni, e dunque le possibilit`a di compilazione separata. Chi volesse provare ad eseguire o modificare i programmi presentati, dovrebbe preferi-bilmente avere a disposizione un computer con una installazione del sistema operativo Linux.

6.1 I socket

L’astrazione utilizzata per rappresentare l’interfaccia del livello trasporto `e il socket: ad un socket `e associata una coppia (indirizzo IP locale, numero di porta locale). Una comunicazione supportata da TCP o UDP avviene sempre tra due porte. Nel caso di TCP, una coppia di porte identificano una connessione.

I socket vengono utilizzati dai processi utente: per aprire ed utilizzare un socket non sono in genere necessari particolari privilegi di esecuzione.

Nella libreria GNU C un socket viene rappresentato con lo stesso tipo di dato associato ad un file: il file descriptor. Per operare sul socket si uti-lizzeranno dunque le stesse operazioni che si usano per operare su un file (apertura, chiusura, scrittura e lettura), pi`u alcune specifiche per l’associa-zione del file descriptor del socket locale ad un altro socket remoto, un passo necessario tanto a TCP quanto a UDP.

Non tutti i sistemi operativi supportano i socket: nella libreria GNU (che esiste per molti sistemi operativi, non solo per UNIX) il file di intestazione sys/socket.h esiste sempre, a prescindere dal sistema operativo, e sono sempre definite le funzioni sui socket. Queste tuttavia falliscono sempre se il sistema operativo non `e in grado di supportare i socket. Questo garantisce che un programma scritto utilizzando la libreria GNU C sia sempre compilabile nei sistemi operativi per cui esiste questa libreria, ma fallisca nel caso in cui il sistema operativo non realizzi lo strato trasporto di Internet.