6) Il livello quattro (Transport)

Il livello transport è il cuore di tutta la gerarchia di protocolli. Il suo compito è di fornire un trasporto affidabile ed efficace dall'host di origine a quello di destinazione, indipendentemente dalla rete utilizzata.

Questo è il livello in cui si gestisce per la prima volta (dal basso verso l'alto) una conversazione diretta, cioè senza intermediari, fra sorgente e destinazione.

Da ciò discende che il software di livello transport è presente solo sugli host, e non nei router della subnet di comunicazione.

Servizi offerti dal livello transport

I servizi principali offerti ai livelli superiori sono vari tipi di trasporto delle informazioni fra una transport entity su un host e la sua peer entity su un altro host.

Naturalmente, tali servizi sono realizzati dal livello transport per mezzo dei servizi ad esso offerti dal livello network.

Così come ci sono due tipi di servizi di livello network, ce ne sono due anche a livello transport:

• servizi affidabili orientati alla connessione (tipici di questo livello);
• servizi datagram (poco usati in questo livello).

Essi sono molto simili, come caratteristiche, a quelli corrispondenti del livello network, ed hanno gli analoghi vantaggi e svantaggi.

Ma allora, perché duplicare le cose in due diversi livelli? Il fatto è che l'utente (che accede ai servizi di rete dall'alto) non ha alcun controllo sulla subnet di comunicazione, e vuole comunque certe garanzie di servizio (ad esempio, il trasferimento corretto di un file). Dunque, tali garanzie devono essere fornite al di fuori della subnet, per cui devono risiedere in un livello superiore a quello network. In sostanza, il livello transport permette di offrire un servizio più affidabile di quanto la subnet sia in grado di fare.

Inoltre, ha un altro importante scopo, quello di isolare i livelli superiori dai dettagli implementativi della subnet di comunicazione. Ottiene ciò offrendo un insieme di primitive (di definizione dei servizi) semplici da utilizzare ed indipendenti dai servizi dei livelli sottostanti. Questo perché mentre solo poche persone scrivono componenti software che usano i servizi di livello network, molte scrivono applicazioni di rete, che si basano sui servizi di livello transport.

Un ultimo aspetto riguarda la possibilità di specificare la QoS (Quality of Service) desiderata. Questo in particolare è adatto soprattutto ai servizi connection oriented, nei quali il richiedente può specificare esigenze quali:

• massimo ritardo per l'attivazione della connessione;
• throughput richiesto;
• massimo ritardo di transito ammesso;
• tasso d'errore tollerato;
• tipo di protezione da accessi non autorizzati ai dati in transito.

In questo scenario:

• le peer entity avviano una fase di negoziazione per mettersi d'accordo sulla QoS, anche in funzione della qualità dei servizi di livello network di cui dispongono;
• quando l'accordo è raggiunto, esso vale per tutta la durata della connessione.

Primitive di definizione del servizio

Esse definiscono il modo di accedere ai servizi del livello.

Tipicamente sono progettate in modo da nascondere i dettagli della subnet (di più, in modo da essere indipendenti da qualunque subnet) ed essere facili da usare.

Ad esempio, questo può essere un tipico insieme di primitive:

Ad esempio, consideriamo i seguenti frammenti di codice di un'applicazione client-server:

Questi due frammenti sono in grado di portare avanti un dialogo senza errori (se il servizio utilizzato è affidabile, il che è la norma), ignorando completamente tutto quanto riguarda la meccanica della comunicazione.

6.1) Protocolli di livello transport

I protocolli di livello transport (sulla base dei quali si implementano i servizi) assomigliano per certi aspetti a quelli di livello data link. Infatti si occupano, fra le altre cose, anche di:

• controllo degli errori;
• controllo di flusso;
• riordino dei TPDU.

Ci sono però anche delle importanti differenze. Quella principale è che:

• nel livello data link fra le peer entity c'è un singolo canale di comunicazione;
• nel livello transport c'è di mezzo l'intera subnet di comunicazione.

Questo implica che, a livello transport:

• è necessario indirizzare esplicitamente il destinatario;
• è più complicato stabilire la connessione;
• la rete ha una capacità di memorizzazione, per cui dei TPDU possono saltare fuori quando la destinazione meno se li aspetta;
• buffering e controllo di flusso richiedono un approccio differente che nel livello data link, a causa del numero molto variabile di connessioni che si possono avere di momento in momento.

6.2) Indirizzamento

Quando si vuole attivare una connessione, si deve ovviamente specificare con chi la si desidera. Dunque, si deve decidere come è fatto l'indirizzo di livello transport, detto TSAP address (Transport Service Access Point address).

Tipicamente un TSAP address ha la forma

Ad esempio, in Internet un TSAP address (ossia un indirizzo TCP o UDP) ha la forma:

dove IP address è il NSAP address, e port number è l'informazione supplementare.

Questo meccanismo di formazione degli indirizzi dei TSAP ha il vantaggio di determinare implicitamente l'indirizzo di livello network da usare per stabilire la connessione.

In assenza di tale meccanismo, diviene necessario che l'architettura preveda un servizio per effettuare il mapping fra gli indirizzi di livello transport e i corrispondenti indirizzi di livello network.

6.3) Attivazione della connessione

Questa operazione sembra facile ma non lo è, perché la subnet può perdere o duplicare (a causa di ritardi interni) dei pacchetti.

Ad esempio, a causa di ripetuti ritardi nell'invio degli ack può succedere che vengano duplicati e successivamente arrivino in perfetto ordine a destinazione tutti i pacchetti precedentemente generati nel corso di una connessione. Ciò in linea di principio può significare che l'attivazione della connessione e tutto il suo svolgimento abbiano luogo due volte.

Si immaginino le conseguenze di tale inconveniente se lo scopo di tale connessione fosse stato la richiesta (a una banca) di versare un miliardo sul conto di un personaggio dalla dubbia onestà.

Il problema di fondo risiede nella possibile esistenza di duplicati ritardatari che arrivano a destinazione molto dopo essere partiti.

Già sappiamo che, una volta che la connessione è stabilita, un qualunque protocollo a finestra scorrevole è adatto allo scopo. Infatti durante il setup della connessione le peer entity si accordano sul numero iniziale di sequenza, e quindi i doppioni ritardatari non vengono accettati.

Viceversa, per risolvere il problema dei duplicati relativi alla fase di attivazione della connessione esiste una soluzione detta three-way handshaking (Tomlinson, 1975).

Il protocollo funziona così:

• il richiedente invia un TPDU di tipo conn.request con un numero x proposto come inizio della sequenza;
• il destinatario invia un TPDU di tipo ack contenente:
  • la conferma di x;
  • la proposte di un proprio numero y di inizio sequenza;
• il richiedente invia un TPDU di tipo dati contenente:
  • i primi dati del dialogo;
  • la conferma di y.

I valori x e y possono essere generati, ad esempio, sfruttando l'orologio di sistema, in modo da avere valori ogni volta diversi.

In assenza di errori, il funzionamento è il seguente:

Se arriva a destinazione un duplicato della richiesta di attivazione, il destinatario risponde come prima ma il mittente, che sa di non aver richiesto una seconda connessione, lo informa dell'errore:

Se infine arrivano al destinatario sia un duplicato della richiesta di attivazione che un duplicato del primo TPDU dati, la situazione è la seguente:

Infatti, in questo caso:

• il mittente invia un reject alla risposta del destinatario, perché sa di non aver richiesto una seconda connessione (come nel caso precedente);
• il destinatario scarta il TPDU dati, perché questo reca un ack relativo ad un numero di sequenza (z) precedente e non a quello (y) da lui testé inviato.