Qualora il datagram non raggiunga la destinazione, la rete e il protocollo IP non fanno nulla. In questo senso best effort equivale a "non affidabile", ma non solo; infatti non è detto che i datagram arrivino a destinazione nell'ordine esatto con cui sono stati inviati, o addirittura, un datagram può essere recapitato più volte al destinatario (per una serie di motivi che capiremo meglio lungo l'articolo). Ma tali caratteristiche sono state scelte apposta dai progettisti per mantenere il protocollo molto snello e comunque funzionale. Ogni caratteristica che IP non fornisce e che è richiesta da un'applicazione, può benissimo essere implementata dagli strati superiori a quello di rete, per esempio dai protocolli dello strato di trasporto (TCP, UDP) o dall'applicazione stessa che usa Internet.


Analizziamo il formato di un datagram: questo consiste in una intestazione seguita dai dati, che costituiscono il vero messaggio che due nodi intendono scambiarsi. I campi più importanti dell'intestazione sono:

• version number: la versione del protocollo, quindi 4. Questo campo è fondamentale per capire a quale versione fa riferimento la struttura del datagram e quindi da ciò si capisce come poter interpretare correttamente il resto del datagram;
• header-length: lunghezza dell'intestazione misurata in parole di 32 bit, ciò perché un datagram può contenere un numero variabile di opzioni; generalmente le opzioni non sono presenti e allora la lunghezza tipica è pari a 20 byte;
• TOS: Type Of Service, permette di distinguere i pacchetti in base alle necessità delle applicazioni;
• length: lunghezza del datagram misurata in byte. Poiché tale campo è di 16 bit, un datagram può avere dimensione massima pari a 65545 byte, dimensione mai raggiunta, si preferisce mantenere ogni datagram il più snello possibile. Una dimensione tipica è di 1500 byte, per mantenere una compatibilità con i protocolli dello strato inferiore (strato di collegamento), che prenderanno in consegna il datagram. Messaggi lunghi verranno quindi frammentati in più datagram, argomento che prenderemo in esame a breve;
• alcuni campi che servono a gestire le operazioni di frammentazione dei messaggi lunghi in più datagram;
• TTL: Time To Live, una sorta di contatore di passaggi (hop) attraverso i router, o come certi autori dicono, una sorta di temporizzatore. Lo scopo è assicurare che un datagram non circoli per sempre in rete, rimbalzando da un router ad un altro. Ogni router che elabora un datagram, prima di rilanciarlo, decrementa questo campo e se questo va a zero il datagram è scartato. Un valore tipico è 64;
• protocol: serve per il demultiplexing del datagram, indica cioè a quale protocollo dello strato di trasporto il datagram medesimo va consegnato;
• checksum: è il campo che serve per rilevare eventuali errori occorsi nel trasporto del datagram. Esso viene calcolato trattando ogni due byte del datagram come un numero intero: viene effettuata una somma di tali numeri, e si effettua il complemento a 1 del risultato, che è poi il valore checksum che verrà scritto nel datagram. Il calcolo viene per forza di cose effettuato da ogni router (cambiando ad ogni rilancio il valore del TTL). All'arrivo di ogni datagram si effettua il controllo: il datagram viene visto come una serie di numeri a 16 bit, si calcola la somma e stavolta si effettua un'addizione con il campo checksum: per effetto delle operazioni in logica binaria, il risultato dell'addizione deve portare ad un numero che in bit presenta tutti 1. Qualora sia presente anche un solo 0, allora significa che nel datagram è occorso un qualche errore. In questo caso un router scarterà il datagram, poichè l'errore occorso potrebbe risiedere nell'indirizzo di destinazione e si rischia di così di recapitare il datagram al destinatario non corretto;
• indirizzi IP del mittente e del destinatario del datagram;
• opzioni eventuali, raramente usate.

L'intestazione è seguita dal payload, ossia i dati veri e propri che costuiscono il messaggio da recapitare al receiver (destinatario). Nella prossima parte approfondiremo il discorso della frammentazione e ricostruzione dei datagram.

• Pubblicazioni correlate:
• 07-01-2008 Uno studio sullo strato di rete (1/7)
• 10-01-2008 Uno studio sullo strato di rete (3/7)
• 14-01-2008 Uno studio sullo strato di rete (4/7)
• 18-01-2008 Uno studio sullo strato di rete (5/7)
• 21-01-2008 Uno studio sullo strato di rete (6/7)
• 29-01-2008 Uno studio sullo strato di rete (7/7)