Apertura di una connessione

L’apertura di una connessione `e una operazione necessariamente asincrona:

le applicazioni che saranno connesse non possono prendere la stessa decisione allo stesso istante!

In genere si distingue una apertura passiva ed una attiva: la passiva serve a richiedere l’apertura di una connessione in attesa che un’altra applicazione faccia una richiesta di apertura attiva. L’apertura passiva alloca una porta sul nodo che la richiede, ed eventualmente specifica la porta ed il nodo dal quale si attende la corrispondente apertura attiva. L’apertura attiva avverr`a

specificando la porta sul nodo partner, ed allocando una porta sul nodo che la richiede. Quindi si tratta di due primitive simmetriche, l’una bloccante, l’altra no. Nel primo caso si dice anche che l’applicazione si prepara ad accettare connessioni su una certa porta.

Nel seguito, parleremo di server per indicare il processo che richiede l’a-pertura passiva della connessione, e client per indicare quello che richiede l’apertura attiva.

Un caso particolare di apertura passiva si ha quando il processo decide di accettare, su una certa porta, connessioni di cui non specifica la provenienza (porta o host). Questo caso si presenta in particolare quando un’applica-zione intende presentarsi come server senza specificare l’identit`a del cliente.

In questo caso la porta mittente indicata nella OPEN passiva sar`a generica, rappresentata con un codice specifico al sistema operativo.

Determinate porte saranno associati a servizi “noti”, ma il documento [2]

indica la possibilit`a che esistano server specializzati nel fornire gli indirizzi di porta e l’indicazione dei nodi in grado di offrire un servizio specifico.

Anche se la modalit`a usuale per la creazione di una connessione avviene facendo corrispondere una apertura passiva con una attiva, lo standard pre-vede che anche la simultanea richiesta di due connessioni attive venga servita correttamente.

Il three way handshake

Una delle funzionalit`a fondamentali del protocollo di apertura di una connes-sione `e la definizione del numero d’ordine del primo pacchetto inviato (Initial Sequence Number (ISN)) da ciascuno dei partner.

E considerato inopportuno che il numero d’ordine del primo ottetto in-` viato sia 0. Infatti la stessa connessione pu`o essere riaperta e richiusa, un numero indeterminato di volte: restando identici gli host e le porte coin-volte, si tratter`a di reincarnazioni successive della stessa connessione. Se allora ogni connessione iniziasse con ISN=0, una connessione chiusa appe-na aperta ed immediatamente (cio`e entro MSL, v. pagiappe-na 139) ricostituita, presenterebbe numeri d’ordine duplicati.

Si raccomanda dunque di utilizzare un orologio per generare gli ISN per minimizzare la probabilit`a di generare, in incarnazioni successive, gli stessi numeri d’ordine. Legando la generazione dell’ISN ad un orologio interno, questa possibilit`a non si presenta se il tempo di ciclo del clock `e ben superiore alla MSL. L’RFC consiglia un clock che avanzi di una unit`a ogni circa 4 µs:

il tempo di ciclo di questo clock sarebbe di circa 5 ore. Poich´e questo tempo

`e sicuramente superiore a qualsiasi ragionevole MSL, concludiamo che non possono essere contemporaneamente in rete due aperture con lo stesso ISN.

La determinazione dell’ISN su una connessione necessita di una forma di accordo tra le due applicazioni coinvolte nella connessione. Infatti non esiste una nozione di tempo globale in rete, e quindi ciascuna applicazione non pu`o considerare di conoscere il valore del clock che l’altro usa per generare il numero d’ordine iniziale.

L’accordo sui valori iniziali dei due numeri d’ordine (uno per ciascun processo) viene ottenuto tramite un procedimento indicato come three way handshake, nome che deriva dal fatto che sono tre i messaggi necessari per concludere l’operazione.

In sintesi, la comunicazione tra le due applicazioni che stanno stabilendo la connessione `e la seguente (indichiamo con pa il client, pb il server):

1. pa→ pb Il mio primo numero d’ordine `e ISNa

2. pa← pb Il tuo primo numero d’ordine `e ISNa

3. pa← pb Il mio primo numero d’ordine `e ISNb

4. pa→ pb Il tuo primo numero d’ordine `e ISNb

Poich´e il secondo ed il terzo passo possono essere incorporati nello stesso messaggio, i messaggi sono in realt`a solo tre. Con solo due messaggi non `e possibile ottenere un risultato analogo: infatti ciascuna applicazione necessita di ottenere un riscontro, mentre uno dei messaggi non pu`o essere di riscontro.

I primi due messaggi coinvolti in questa fase iniziale hanno il flag SYN attivo. Il secondo ed il terzo hanno il flag di ACK settato. Il valore del primo numero d’ordine sar`a indicato nel campo dell’intestazione destinato al nume-ro d’ordine, mentre il riscontnume-ro sar`a indicato nel campo destinato al riscontnume-ro.

Il valore del flag SYN segnaler`a che questi campi non vanno interpretati in maniera usuale, poich´e `e in corso il protocollo di sincronizzazione dei numeri d’ordine.

In figura 5.5 viene rappresentato il diagramma a stati dell’algoritmo. Gli stati hanno il seguente significato:

CLOSED La connessione non esiste.

syn-rcvd create tcb; snd syn——–

@@

Figura 5.5Diagramma a stati (semplificato) del three-way handshake

LISTEN La connessione `e stata aperta in modalit`a passiva (server) e si at-tende la prossima richiesta.

SYN-SENT La connessione `e stata richiesta con modalit`a attiva ed `e stato spedito il messaggio SYN contenente il proprio ISN. Ora si attende il riscontro del partner, ed il suo ISN.

SYN-RCVD `E lo stato di una connessione attiva ed utilizzabile per il trasferi-mento di informazione.

Le transizioni sono etichettate con un evento osservato (sopra) ed una azione intrapresa (sotto). Da notare che la transizione da SYN-SENT a SYN-RCVD si presenta solo nel caso in cui ambedue i partner abbiano operato una apertura attiva.