Se invece abbiamo più gateway tra i due host, ogni gateway, tranne l’ultimo, dovrà spedire il messaggio a un altro gateway.La tabella di instradamento fornisce per ogni possibile rete destinataria finale l’indirizzo IP del gateway successivo.

Queste tabelle non contengono di solito gli indirizzi IP di tutti i possibili host destinatari, cosa che sarebbe fisicamente impossibile, bensì gli indirizzi delle reti raggiungibili a partire da quel gateway.

Esiste poi la possibilità di specificare un gateway di default e cammini specifici per host speciali. La prima cosa è molto comune, mentre la seconda è usata solo in casi eccezionali. La logica di instradamento è quindi quella riportata nel diagramma.

La gestione dei messaggi di errore: Come si può facilmente capire dal meccanismo di instradamento appena spiegato, non è possibile sapere se il destinatario effettivamente esiste fintanto che il datagramma non arriva all’ultimo gateway.

l’IP non contiene grossi meccanismi di verifica, ed è per questo che è detto “inaffidabile“.

Esso richiede quindi un protocollo ausiliario per l’emissione di messaggi di errore in rete, che permettano ai protocolli di livello superiore di implementare una logica più affidabile e robusta.

Tale protocollo è chiamato Internet Control Message Protocol (ICMP).
L’ICMP è considerato parte integrante dell’IP ed è sostanzialmente un protocollo per le segnalazioni di errori il cui utente principale è l’IP stesso.

In casi particolari l’ICMP arriva a informare dell’errore eventuali livelli superiori all’IP.

Cosa fare quando avviene un errore non spetta all’ICMP, ma ai processi che se ne avvalgono.

L’ICMP informa sempre l’IP mittente, non i vari gateway intermedi.

Questo in quanto del cammino percorso da un datagramma non rimane traccia, per cui l’unico possibile destinatario di un messaggio di errore è solo chi ha generato il datagramma.

I datagrammi ICMP viaggiano incapsulati in datagrammi IP, come un qualunque messaggio di livello superiore, essi sono soggetti alle stesse limitazioni in termini di affidabilità di qualunque altro messaggio spedito via TCP/IP.

Non analizzeremo in dettaglio tutti i datagrammi ICMP, anche perché ognuno può avere una struttura differente.

Diciamo che l’intestazione di un datagramma ICMP contiene sempre almeno tre campi: il tipo di messaggio, un codice di errore, e una somma di controllo.

Il livello di Trasporto:

La torre Internet si può schematizzare più o meno su quattro livelli.

La  base della torre ospita l’hardware che rappresenta la rete vera e propria.

Il primo livello, ospita l’interfaccia alla rete fisica, detto appunto Network Interface o anche Data Link.

I protocolli a questo livello si scambiano blocchi di dati chiamati frame, la cui struttura è strettamente legata alle caratteristiche hardware della rete stessa.

Il secondo livello ospita le interconnessioni fra reti, ovverosia il livello dell’IP la cui unità di scambio dati è appunto il datagramma IP.

Il terzo livello è quello detto di Trasporto.

Concettualmente è a questo livello che si pongono sia il TCP che appunto l’UDP. L’unità di scambio dati al terzo livello si chiama pacchetto (transport packet).

 Il quarto livello ospita gli Applicativi, al quale vengono scambiati i messaggi applicativi (message e data stream).

Abbiamo visto come l’IP permette di scambiare datagrammi fra host, cioè a livello di macchine. Tuttavia non è certo la macchina il destinatario finale dei dati che fluiscono nella rete, bensì le applicazioni e i programmi che girano su di essa.

Lo scopo dell’UDP è appunto quello di permettere di distinguere in un singolo host più destinatari per i dati che arrivano dalla rete. Ma come?
Se io devo stampare un file cosa faccio? Collego al mio computer una stampante, attivo il driver corrispondente, e uso una applicazione o un comando del sistema operativo per lanciare l’ordine di stampa.

Se ora stacco la stampante e ne attacco un’altra alla stessa porta non devo far altro che cambiare il driver per continuare a lavorare senza che il sistema si sia accorto di niente.

Se poi le due stampanti usano lo stesso driver generico devo solo staccare e riattaccare fisicamente le stampanti senza modificare il sistema.

In generale, tutto lo scambio di dati da e verso un computer avviene attraverso porte di I/O. Ogni applicazione accede la porta che gli serve in modo dinamico.

La periferica di I/O non ha bisogno di sapere con quale applicazione sta parlando: la porta fa da schermo fra i due. L’UDP fa una cosa analoga. associa a un indirizzo IP più punti di ingresso e di uscita virtuali, detti protocol port.

Queste porte si comportano un po’ come quelle di I/O di un computer. Ogni porta è identificata da un numero intero positivo e i processi possono chiedere al sistema l’accesso a tali porte.

Quando un processo accede una porta, esso si mette in attesa dei dati sulla stessa. Il meccanismo è sincrono. Inoltre, se dei dati arrivano a una porta alla quale non si è agganciato ancora un processo, questi vengono mantenuti in memoria nell’ordine di arrivo. Si dice cioè che le porte hanno un buffer.
A questo punto, sia il processo mittente che quello destinatario sono univocamente identificati dall’indirizzo IP dell’host su cui girano e dal numero di porta che utilizzano per la trasmissione in rete.

Tale associazione è tuttavia dinamica, e così come più applicazioni possono stampare sulla stessa stampante purché non contemporaneamente, così più processi possono attaccarsi uno alla volta alla stessa porta ed essere visti come lo stesso destinatario dalla controparte mittente.

Ciò permette di spedire un file di testo con un word processor, e subito dopo spedire un file binario, per esempio un file ZIP, con un comando di sistema.

Il tutto sempre attraverso la stessa porta e con lo stesso destinatario in termini di host e di processo.
Come abbiamo visto nel caso dell’IP e dei vari protocolli di rete, anche il datagramma UDP è formato da una intestazione (header) e da una parte dati.

E’ inoltre incapsulato in un datagramma IP il quale a sua volta è contenuto in un frame della rete fisica.
Diversamente da quello IP, l’header UDP è molto più semplice. Esso è formato dal numero di porta del mittente, da quello del destinatario, dalla lunghezza del messaggio UDP, sia dei dati che dell’intestazione, e da una somma di controllo (checksum) per la verifica dell’integrità dei dati.

Anche l’UDP, come l’IP, è un protocollo cosiddetto “inaffidabile”.

Significa che un messaggio UDP può andare perso, essere duplicato, o arrivare nell’ordine sbagliato. L’UDP non fa alcun controllo al riguardo. L’affidabilità della comunicazione è infatti affidata a i protocolli di livello più elevato.

Tutti i campi dell’intestazione sono lunghi 16 bit. Benché il formato del datagramma UDP sia alquanto semplice, la sua gestione può essere un po’ più complessa.

Il punto riguarda la somma di controllo. Questo valore è opzionale e, al contrario di quello che succedeva con la somma di controllo nel datagramma IP, esso non è relativo solo all’intestazione ma a tutto il datagramma, compresa la parte dati.

Questo vuol dire che tale campo rappresenta l’unico elemento di controllo a livello IP e UDP dell’integrità dei dati arrivati.

Se esso non viene utilizzato, il campo va posto a zero. Perché la somma di controllo segue la logica a complemento uno.

Ovvero se la somma calcolata è zero, essa può essere memorizzata come 16 bit impostati a uno, dato che in tale logica un valore con tutti i bit a uno e uno con tutti i bit a zero rappresentano lo stesso numero.

Perciò: se il campo è a zero, vuol dire che non è stato utilizzato; se viceversa ha tutti i bit ad 1, vuol dire che la somma era zero.
La somma di controllo, tuttavia, per ragioni pratiche, non riguarda solo il datagramma UDP, ma viene calcolata anche utilizzando alcune informazioni addizionali. Queste formano il cosiddetto pseudo-header.

In pratica, quando si deve calcolare il checksum UDP si mette davanti al datagramma UDP un altro blocco di dati che contiene l’indirizzo IP del mittente e del destinatario, il codice del protocollo UDP (17), e la lunghezza del datagramma UDP.

Il motivo di questa tecnica risiede nel fatto che, per verificare se un messaggio UDP è arrivato al giusto destinatario, non basta verificare il numero di porta, ma anche l’indirizzo IP dell’host in cui gira il processo che è collegato a quella porta.

Il datagramma UDP contiene tuttavia solo il numero di porta, per cui il controllo fornito da una somma sul solo datagramma non potrebbe realmente verificare che il destinatario dei dati è quello giusto.

Questa tecnica ha tuttavia un prezzo: gli indirizzi IP fanno parte appunto del livello internet, non di quello di trasporto.

Perché l’UDP conosca tali informazioni è necessario violare una legge fondamentale dei protocolli di comunicazione, e cioè che ogni livello della torre deve gestire i suoi dati senza esportarli agli altri livelli a cui offre, o da cui riceve, servizi.

Questo vuol dire che la separazione tra UDP ed IP non è così pulita come dovrebbe essere, ma che i due protocolli sono in qualche modo legati tra loro.

D’altra parte i vantaggi in termini di controllo e semplicità di implementazione sono tali che si è deciso di fare un’eccezione ai principi dell’architettura.

Da notare che la pseudo-intestazione serve solo a calcolare la somma di controllo.

Essa non viene fisicamente trasmessa con il datagramma UDP, dato che le informazioni che contiene fanno già parte dell’intestazione del datagramma IP in cui quello UDP sarà incapsulato.
Se l’IP rappresenta il braccio del TCP/IP, il TCP ne rappresenta la mente.

Il primo si limita a spedire rapidamente i dati che gli arrivano senza preoccuparsi troppo se qualcosa va male

Il secondo si occupa invece di controllare che l’informazione passatagli dai livelli superiori arrivi correttamente a destinazione. Insieme sono sicuramente una coppia molto affiatata.

Utilizzeremo il termine applicazioni per indicare tanto i protocolli applicativi come FTP o SMTP, quanto i programmi applicativi veri e propri, salvo indicazione contraria.

Indicheremo inoltre con il termine utente di un servizio colui che utilizza tale servizio, sia esso direttamente una persona, un’applicazione, o un protocollo. Per esempio, il TCP è un utente dell’IP.

C’è subito da dire due cose importanti sul TCP. La prima è che lo standard del TCP non definisce né l’implementazione dello stesso, né le modalità con cui un’applicazione accede a i servizi di questo protocollo.

Esso definisce solamente le caratteristiche di tali servizi, per cui si possono trovare molte differenti implementazioni del TCP, ognuna con la propria interfaccia applicativa.

Ricordo che un’interfaccia applicativa o API (Application Programming Interface) non è altro che l’insieme delle funzioni, delle istruzioni, dei parametri e dei blocchi di controllo che vengono utilizzati dai programmatori per accedere ai servizi di un sistema.

Se ho un sistema di posta elettronica potrei definire un’API basata su due funzioni, una chiamata spedisci, e una chiamata ricevi.

Per ogni funzione sarebbero poi da definire quali informazioni sono da passare al momento dell’utilizzo (parametri in ingresso), quali si ottengono una volta espletato il servizio (parametri di ritorno), eventuali codici di errore, e le regole di utilizzo delle singole funzioni.

Il motivo che sta alla base della scelta di non standardizzare l’interfaccia con il TCP è che in molti casi questo protocollo è direttamente definito nel sistema operativo, o comunque fa parte del cosiddetto corredo di base di un sistema, per cui si è voluto evitare di forzare una sintassi che potesse essere in contrasto con quella nativa del sistema ospite.

Se vi siete persi le puntate precedenti le trovate qui:

Tcp / Ip parte 1

Tcp / Ip parte 2

Tcp / Ip parte 3

Tcp / Ip parte 4

Tcp / Ip parte 5