Alma Mater Studiorum - Universita' di Bologna
Sede di Cesena
Reti di Calcolatori
Indirizzamento
Il Layer di Trasporto – CLTS
Vedi:
• D. Comer, Internetworking con TCP/IP - Principi, protocolli e
architetture, vol. 1, Addison-Wesley cap. 12, pagg. 207-216.
Copyright © 2006-2014 by Claudio Salati.
Lez. 2
1
Host, processi, servizi
.1
• Il protocollo IP e' capace di trasferire datagram tra diversi host (endsystem) della rete
(N.B.: questa affermazione non e’ proprio corretta formalmente ma lo
e’ nella sostanza).
• Un host e’ indirizzato tramite il suo indirizzo (uno dei suoi indirizzi) IP.
• Su uno host sono pero' normalmente in esecuzione diversi processi,
ciascuno dei quali rappresenta una istanziazione (attivazione,
esecuzione) di un programma utente ed una entita’ fornitore o cliente
di un certo servizio applicativo.
 Assumiamo che di norma l’applicazione distribuita abbia la
struttura client-server.
• Sono questi processi, di solito, e non gli host di per se’ stessi, i veri
destinatari dei dati e delle informazioni che viaggiano sulla rete.
• Se e' con loro che vogliamo parlare, come possiamo indirizzarli?
 Notiamo che in un contesto client-server convenzionale il
problema esiste per l’indirizzamento del server: questi puo’
limitarsi a rispondere ai client che lo hanno contattato e che
2
ragionevolmente gli hanno fornito il proprio indirizzo.
Host, processi, servizi
.2
• E' ad esempio ragionevole indirizzare un messaggio ad un processo
che si trova ad un certo indirizzo IP e che ha un certo PID (Process
Identifier)?
No, i PID sono:
• difficili da conoscere, specie su un nodo remoto,
• volatili, in quanto assegnati dinamicamente,
• non indicativi del servizio fornito dal processo!
• Quello che vorremmo e' poter indirizzare un servizio applicativo
disponibile su un nodo, indipendentemente dall'identita' del processo
che lo fornisce.
 In particolare vorremmo poter indirizzare il lato server
dell’applicazione distribuita.
 Ricordiamo che i processi applicativi accedono al servizio di
Trasporto tramite un TSAP e che un TSAP e’ un indirizzo univoco
sulla rete (a livello di Trasporto).
3
Host, processi, servizi
.3
• Esiste anche un altro problema. Consideriamo il daemon inetd
presente su tutti i sistemi Unix.
• Esso e' fatto per ricevere richieste relative a molti dei servizi
disponibili sul sistema (ftp, telnet, …).
• In base al tipo di servizio richiesto esso attiva l'opportuno servitore
per fornirlo (il superserver inetd e’ una specie di centralinista!).
• inetd deve poter riconoscere il tipo di servizio richiesto non in base
al contenuto della richiesta, che non sa interpretare, ma in base al
(l'indirizzo del) destinatario di essa.
• Tutti questi problemi vengono risolti se il destinatario finale di un
messaggio sulla rete non e' direttamente un processo, ma un SAP, il
SAP attraverso il quale un processo destinatario ha accesso alla rete
(al Servizio di Trasporto: quindi qui si sta parlando di TSAP).
• Addirittura, almeno lato server, possiamo vedere un TSAP come
identificatore di un servizio applicativo (piuttosto che del processo
che concretamente lo offre), il che risolve il problema di inetd.
4
nSAP
.1
• Un nSAP e’:
• Un punto d’accesso ai servizi di rete di livello n da parte di una
protocol entity di livello (n+1).
• L’indirizzo univoco sulla rete di una protocol entity di livello (n+1).
• La struttura dell’identificativo di un nSAP e’ uguale qualunque sia n:
• Un identificativo di nSAP e’ ottenuto dalla concatenazione:
• Dell’(n-1)SAP che identifica univocamente la protocol entity di
livello n che fornisce il servizio acceduto tramite l’nSAP.
• Dell’nSEL (selettore di livello n) che identifica univocamente i
diversi utenti di una stessa protocol entity di livello n.
• Per come e’ costruito un nSAP e’ un identificatore unico per le
protocol entity di livello (n+1).
nSAP1
. . .
n-level protocol entity
(n-1)SAP
nSAPm
nSAP1 = (n-1)SAP + nSEL1
…
nSAPm = (n-1)SAP + nSELm
5
nSAP
.2
• Tutti gli utenti di una stessa protocol entity hanno nSAP in cui la parte
(n-1)SAP e’ uguale.
• Quindi quello che differenzia davvero l’uno dall’altro i diversi utenti di
una stessa protocol entity del Layer n e’ lo nSEL.
• Se, almeno lato server, vogliamo vedere un TSAP come identificatore
di un servizio applicativo, dovra’ essere un particolare valore di TSEL
ad essere associato a quel tipo di servizio applicativo.
 N.B.: in un’applicazione client-server quando si parla di
indirizzamento ci si riferisce sempre a quello del lato server
• Diverse protocol entity di livello (n+1) di uno stesso tipo (protocollo)
che utilizzano diverse protocol entity di livello n per accedere ai servizi
di livello n avranno diversa la parte (n-1)SAP del loro nSAP, ma
avranno uguale la parte nSEL.
6
nSAP
.3
• Esempio 1:
• Due diverse istanze di protocol entity IP su macchine diverse, con
diverse interfacce Ethernet, avranno diverso MAC address ma
uguale DlSEL (selettore di DataLink, 2SEL)
• Due diverse istanze di protocol entity TCP su macchine diverse
avranno diverso indirizzo IP ma uguale NSEL (selettore di Rete,
3SEL)
• N.B. TCP, UDP e IP non sono strutturati secondo il paradigma
client-server: tutte le loro protocol entity devono presentarsi sulla
rete tramite un SAP ben noto!
• Esempio 2:
• In un servizio applicativo di struttura client-server i moduli che
implementano il lato server su diverse macchine avranno diverso
NSAP ma uguale TSEL.
7
TSAP, processi, servizi
• Perche’ lo schema funzioni occorre che ci sia una relazione ben nota
tra un TSAP e un servizio:
• Comunque i clienti sono interessati ai servizi, non ai TSAP!
• Esempio:
• Il numero di telefono 800-999-500 in Italia e’ associato al servizio
clienti di HERA.
• Non ci interessa chi e’ l’operatore (il processo) che ci fornisce il
servizio, quello che ci interssa e’ ottenerlo.
• Ma di per se’ non ci interessa nemmeno chiamare l’800-999-500,
quello che ci interessa e’ chiamare il servizio clienti di HERA
• In realta’ in un TSAP solo il TSEL e’ legato al particolare tipo di utente
del Servizio di Trasporto:
 Sara’ quindi il TSEL ad identificare il particolare servizio applicativo
(terminale remoto, file transfer, …) offerto sul Servizio di Trasporto.
• E’ quindi necessario che:
• Ci sia una autorita’ che gestisce/garantisce queste associazioni.
• Ci sia un servizio di pagine gialle che mi dica quale e’ il TSEL 8
associato ad un certo servizio applicativo.
Implementazione di un TSAP su Internet
 Secondo OSI un TSAP e' un punto d'accesso al servizio del layer di
Trasporto.
 In internet il concetto di TSAP e' implementato (circa) attraverso la
nozione di porta di protocollo.
 Una porta di protocollo e' individuata (circa) attraverso una tripla:
 Un indirizzo IP del sistema su cui la porta si trova
 NSAP OSI
 Il protocollo di Trasporto cui la porta e' relativa
(TCP vs. UDP)( NSEL OSI)
 Il numero della porta (un intero compreso tra 1 e 65.535)( TSEL OSI)
 Concretamente, una porta identifica univocamente una applicazione che
accede, tramite il servizio di Trasporto, alla rete (per offrire il proprio
servizio).
 Warning: per comunicazioni CO il concetto va un po’ precisato;
vedi lezione relativa.
 Ogni servizio applicativo deve essere associato ad una porta (TSEL)
ben nota (well known), perche’ e’ indirizzando questa porta che
9
un cliente riesce a raggiungerlo.
Internet layer e SAP
HTTP
server
FTP
server
TCP port
= 80
TCP port
= 21
TFTP
server
Port Mapper
TCP port
= 111
TCP
UDP port
= 111
ICMP
Protocol
=6
UDP port
= 69
SNMP
agent
UDP port
= 161
UDP
Protocol
=1
IP
IP address A1.A2.A3.A4
.1
Protocol
= 17
IP address B1.B2.B3.B4
ARP
Ethertype
= 2048
Ethertype =
2054
Ethernet - MAC address A
Ethertype
= 2048
Ethernet - MAC address B
10
Internet layer e SAP
•
•
•
•
.2
Data Link Layer
• Protocol Entity Ethernet
• Indirizzo:
MAC address
• DlSEL:
Ethernet Type
Network Layer
• Protocol Entity IP
• Indirizzo:
IP address(es)
• NSEL:
Protocol
o DlSAP(Ethernet): MAC address + (Ethernet Type = 2048)
Transport Layer
• Protocol Entity TCP
• TSEL:
TCP port
o NSAP:
IP address(es) + (Protocol = 6)
• Protocol Entity UDP
• TSEL:
UDP port
o NSAP:
IP address(es) + (Protocol = 17)
Application Layer
• FTP server
o TSAP:
NSAPTCP + (TCP port = 21)
• TFTP server
o TSAP:
NSAPUDP + (UDP port = 69)
11
Struttura di un datagram IP e individuazione
dell’NSAP destinazione
• NSEL: notare che c’e’ un unico NSEL per
mittente e destinazione, che devono quindi
avere NSEL uguale.
• NSEL ha dimensione 1 byte, per cui sono
possibili solo 256 NSEL diversi.
(da Tanenbaum)
Indirizzo IP
12
Un servizio (applicazione) identificato da un TSAP?
• Ma non dovrebbe essere un qualcosa come un ASAP ad identificare un
servizio applicativo?
 Nel mondo OSI si’, ma nel mondo internet un servizio e’ indirizzato e
identificato da una porta di protocollo!
 Cioe’ nel mondo internet un servizio e’ identificato e indirizzato da un
TSAP (e in particolare da un TSEL)!
• 2 argomenti perche’ e’ cosi’:
1. Il Layer di Trasporto e’ una frontiera implementativa:
• I layer 2..4 sono implementati come parte del sistema operativo.
• I layer 5..7 sono implementati come parte del processo utente che
realizza il modulo dell’applicazione distribuita.
• L’interazione tra programma utente e layer 5..7 e’ interna al
processo utente e non avviene tramite SAP ma tramite API
procedurali.
2. I Layer 6 e 7 non sono strutturati come veri e propri Layer OSI;
in particolare il Layer 6 e’ visto come un servizio di de/codifica locale e
non come un layer di comunicazione vero e proprio.
• L’indirizzo di una protocol entity del Layer Applicativo e’ quello del
TSAP attraverso cui avvengono le sue comunicazioni.
13
Perche’ il Layer di Trasporto?
• E’ evidente che anche il Layer di Rete e’ capace di distinguere tra
diversi utenti e che in effetti gia’ lo fa (e.g. TCP, UDP, ICMP).
 L’utente destinatario (e sorgente) del datagram IP e’ indicato dal
campo Protocol del datagram stesso
• Allora perche’ diciamo che i processi utente sono indirizzabili solo a
livello di Trasporto?
Perche’ il layer IP e’ accessibile di norma solo da parte di (altre)
entita’ di sistema (le protocol entity di Trasporto o la protocol entity
ICMP), non dai processi utenti.
• L’API IP e’ un’API interna del sistema (non proprio vero).
• Il limite e’ evidenziato anche dal fatto che l’NSEL (trasportato in rete
tramite il campo Protocol del datagram) deve essere uguale su
entrambi i lati della comunicazione:
• Non e’ un problema per le entita’ di Trasporto (perche’?).
• Impedirebbe di avere su una stessa macchina (a) piu’ browser
aperti, (b) un browser e un web server.
14
Indirizzo di rete
.1
• Perche’ come indirizzo della protocol entity IP non uso un suo/i suoi
DlSAP (in effetti all’interno della sottorete lo/i uso)?
 Perche’ i DlSAP sono relativi alla sottorete e, in generale, sono
univoci solo sulla sottorete.
 Perche la struttura stessa dei DlSAP (sintassi dell’indirizzo di
Data Link e del DlSEL) dipende dalla particolare sottorete, e IP
non vuole avere a che fare con le particolarita’ delle sottoreti.
 La definizione di un layer di internetwork implica che anche per
gli indirizzi, nel Network Layer, si riparta da zero, dall’indirizzo
IP del nodo.
• Ma di indirizzi IP una protocol entity IP puo’ averne tanti.
 Ne ha uno per ciascuna sottorete su cui si appoggia, compresa
la sottorete di loopback.
 Quale/i bisogna usare?
15
Indirizzo di rete
.2
• Se qualcuno cerca di indirizzare una entita’ di livello superiore a IP
riferendo un indirizzo IP che questa non ha utilizzato?
 Data la struttura di NSAP e TSAP l’indirizzo IP compare in
ciascuno di essi.
• Se nella costruzione del proprio TSAP si usa un solo, particolare,
indirizzo IP per identificare la protocol entity IP che ci supporta (ad
esempio: TSAP=A1.A2.A3.A4:80), allora vuole dire che vogliamo
essere indirizzati solo tramite quel particolare indirizzo IP.
 Se qualcuno cerca di indirizzarci utilizzando un diverso indirizzo
IP della macchina (nell’esempio, B1.B2.B3.B4), non riesce a
raggiungerci.
• Altrimenti deve esserci una maniera di indicare nel TSAP “tutti gli
indirizzi IP della protocol entity IP che mi supporta”.
 Nell’esempio:
TSAP=“A1.A2.A3.A4 or B1.B2.B3.B4 or 127.0.0.1”:80.
 127.0.0.1 e’ l’indirizzo di un qualunque nodo IP sulla propria
sottorete di loopback.
16
Configurazione di una interfaccia IP/Ethernet
O:\>ipconfig /all
Configurazione IP di Windows
Nome host . . . . . . . . . . . . . .
Suffisso DNS primario . . . . . . .
Routing IP abilitato. . . . . . . . .
Elenco di ricerca suffissi DNS. . . .
:
:
:
:
“Nome” della macchina:
csalati-xp
csalati-xp.dl.net
dl.net
No
dl.net
datasensor.corp
psc.pscnet.com
pscnet.com
Scheda Ethernet connessione alla intranet Datalogic:
Suffisso DNS specifico per connessione:
Descrizione . . . . . . . . . . . . . :
Indirizzo fisico. . . . . . . . . . . :
DHCP abilitato. . . . . . . . . . . . :
Configurazione automatica abilitata
:
Indirizzo IP. . . . . . . . . . . . . :
Subnet mask . . . . . . . . . . . . . :
Gateway predefinito . . . . . . . . . :
Server DHCP . . . . . . . . . . . . . :
Server DNS . . . . . . . . . . . . . :
Indirizzo della sottorete vs. indirizzo del nodo
dl.net
Broadcom NetXtreme 57xx Gigabit Controller
00-14-22-31-0B-9D Indirizzo del nodo nella
Sì
sottorete
Sì
172.16.2.64 Indirizzo IP sulla sottorete
255.255.0.0
172.16.255.254 Indirizzo IP del router da
utilizzare
172.16.0.5
172.16.0.5
172.16.0.6
Ben 2 server DNS!?
A cosa servono?
17
Indirizzi di rete (indirizzi IP) pubblici e privati
• E se lo spazio di indirizzamento IP si esaurisce?
 E’ quello che e’ capitato davvero!
• In realta’ internet non e’ piatta:
 Ci sono reti interne di aziende (una rete privata!).
 Ci sono le reti interne dei service provider (una rete privata!).
 C’e’ il backbone.
• Non e’ detto che i nodi di una rete privata debbano avere indirizzi
pubblici!
• RFC 1918 “Address allocation for Private Internets” assegna dei
blocchi di indirizzi IP per uso in reti private:
• 172.16.0.0
-
172.31.255.255
• 192.168.0.0
-
192.168.255.255
• Nota che uno stesso indirizzo puo’ essere utilizzato in tante reti
private.
• Ovviamente se un nodo deve essere raggiungibile su internet
deve avere un indirizzo pubblico!
• NAT (NATP)!
18
Indirizzi di rete pubblici e privati
IS
sottorete
sottorete
intranet
IS
sottorete
IS
sottorete
sottorete
ES
ES
ES
sottorete
intranet
IS
19
Indirizzi IP particolari
• Nell’architettura internet ogni ES (host) e’ connesso ad una
particolare sottorete (locale) di loopback che gli consente di
interagire (solo) con se stesso
• E’ una sottorete “virtuale” ma e’ effettivamente implementata come
parte dello stack TCP/IP
• Su questa sottorete lo host ha indirizzo IP 127.0.0.1
• Il significato dell’indirizzo 127.0.0.1 e’ puramente locale:
su ogni ES esso indica lo stesso ES sulla relativa sottorete di
loopback
• Quindi una applicazione che risiede sull’ES A puo’ utilizzare
l’indirizzo 127.0.0.1 solo per interagire con altre applicazioni che
risiedono sullo stesso ES A
• Un altro indirizzo IP particolare, dal significato contestuale, e’
255.255.255.255 che, come indirizzo destinazione, indica tutti i nodi
connessi direttamente alla sottorete cui e’ collegato l’NSAP/TSAP
che ha trasmesso il datagram IP
 Quindi 255.255.255.255 e’ un indirizzo broadcast di sottorete
 E’ utilizzabile solo su sottoreti che supportano comunicazioni
broadcast
20
Indirizzi IP: sottorete e nodo
• Un indirizzo IP e’ composto di 2 parti concatenate tra loro, per un
totale di 32 bit
 Indirizzo di sottorete
 Indirizzo del nodo sulla sottorete
• La lunghezza di queste due parti non e’ fissa, ma dipende dalla
sottorete
• Quanti dei 32 bit fanno parte dell’indirizzo di sottorete e quanti fanno
parte dell’indirizzo di nodo sulla sottorete e’ definito dalla netmask
della sottorete
• E’ possibile indirizzare tutti i nodi di una sottorete concatenando
all’indirizzo della sottorete un campo indirizzo di nodo di bit tutti a 1
• Oltre all’indirizzo contestuale di broadcast di sottorete
255.255.255.255, utilizzabile solo su nodi direttamente collegati alla
sottorete, esiste quindi un indirizzo di broadcast di sottorete non
contestuale
21
Associazione client - server
• Un servizio applicativo e’ associato ad una porta ben nota (well
known port).
• Il processo (server) che offre quel servizio applicativo sull’host S
utilizza (deve utilizzare) per accedere ai servizi del Layer di
Trasporto la porta well known associata al servizio applicativo.
• Un processo client che vuole utilizzare il servizio applicativo in
questione, offerto sull’host S, sa che esso e’ offerto sulla porta di
trasporto well known relativa, ed indirizzera’ quindi le sue richieste
a questa porta dell’host S.
• L’autorita’ che si occupa di gestire/garantire l’associazione numero
di porta  servizio applicativo e’ la IANA (Internet Assigned
Numbers Authority).
 E’ la IANA che ha stabilito che la porta 80 identifica il servizio
applicativo WWW (cioe’, e’ quella utilizzata dal lato server del
protocollo HTTP)
22
Associazione client - server
• E’ la IANA che gestisce / assegna tutti i numeri importanti di
internet.
 E’ la IANA che ha stabilito che l’Ethernet Type = 2048 identifica
il protocollo IP sulle sottoreti Ethernet
 E’ la IANA che ha stabilito che Protocol = 6 a livello IP identifica
il protocollo di trasporto TCP
(mentre Protocol = 17 identifica il protocollo di trasporto UDP)
• Ma come fa un cliente a sapere quale e’ il numero di porta che la
IANA ha associato ad un certo servizio applicativo?
 O va sul sito www.iana.org
http://www.iana.org/assignments/port-numbers
 O ha bisogno di un servizio di pagine gialle dinamico!
Che effettui il mapping
nome del servizio applicativo  numero di porta
23
getservbyname()
• In realta' la maniera migliore di nominare un servizio applicativo dal
punto di vista umano e' attraverso un nome stringa: "telnet", "ftp", ...
• La funzione getservbyname() consente di ottenere la protocol port
su cui un certo service provider applicativo offre il suo servizio a
partire dal nome (stringa) del servizio stesso.
#include <netdb.h>
struct servent *getservbyname(const char *name,
const char *proto);
struct servent {
char *s_name;
// official name of service
char **s_aliases; // alias list
int s_port;
// port service resides at
char *s_proto;
// protocol to use, if !=NULL
};
• Un servizio applicativo puo' essere offerto tramite uno solo o piu'
servizi di Trasporto: la query ha quindi un parametro opzionale che
consente di filtrare la ricerca in base al servizio di Trasporto che 24
interessa.
Associazione client - server
• In realta’ nelle pagine passate abbiamo fatto una assunzione:
• Un fornitore di un certo servizio applicativo si mette in attesa di clienti su
una porta ben nota (sulla porta ben nota di quel servizio applicativo ).
• Un cliente che vuole utilizzare quel servizio applicativo si rivolge ad un
processo server che lo offre utilizzando per indirizzarlo la porta ben nota
relativa.
• Un server invia le risposte all’indirizzo da cui gli e’ arrivata la richiesta di
servizio.
• Di conseguenza:
• le porte utilizzate dai processi server devono essere ben note (well
known);
• le porte utilizzate dai processi client non hanno nessun significato
particolare: diversi processi client di uno stesso servizio applicativo possono
avere (utilizzare per accedere al Servizio di Trasporto) porte diverse.
• Un processo server si limita a rispondere al processo client che lo ha
cercato, qualunque sia la porta di quest’ultimo.
• Le porte utilizzate dai processi client possono avere numero qualunque,
purche’ siano univoche relativamente alla protocol entity di Trasporto
25
che le supporta.
Modelli di interazione sulla rete
• Il modello di interazione tra moduli di un programma distribuito che
stiamo considerando e’ il seguente:
• Un modulo server che si mette in attesa di clienti sulla rete,
• Un modulo client che entra in comunicazione con il modulo
server che gli interessa,
• Un dialogo punto-punto tra client e server.
E’ l’unico possibile?
• NO:
• Si pensi ad un servizio di vendita porta a porta.
• Si pensi ad un servizio di tipo push, dove il server, quando ha
qualcosa da dire, inizia lui la comunicazione con i client
registrati.
• Si pensi al DNS.
• Si pensi ad uno sportello Bancomat in cui sono coinvolti non 2
ma 3 attori (lo sportello, il calcolatore centrale della banca che
possiede lo sportello, il calcolatore centrale della banca che 26
gestisce il conto corrente).
Modelli di interazione sulla rete
• Nel mondo OSI viene fatta la distinzione tra i ruoli di
• client e server
• Rispettivamente, chi richiede il servizio e chi lo fornisce
• initiator e respoder della comunicazione
• Rispettivamente, chi prende l’iniziativa di iniziare la
comunicazione e chi accetta passivamente la richiesta di entrare
in comunicazione
• Nel mondo TCP/IP i ruoli di
• client e initiator da un lato, e di
• server e responder dall’altro
sono pensati in generale come coincidenti (salvo indicazione contraria).
• Le protocol entity TCP e IP, di per se’ stesse, non interagiscono con le
loro pari secondo il modello client-server!
• N.B.: E’ evidente che nel contesto del modello di interazione clientserver il problema del servizio T-CONNECT per cui “simultaneous
T-CONNECT requests typically result in a corresponding number 27
of TCs” risulta irrilevante!
Host, processi, servizi: UDP
.1
• La distinzione tra indirizzo IP e indirizzo finale di un servizio, e'
esemplificativa dal significato del protocollo UDP.
 E di quello del Layer di Trasporto
• Che tipo di servizio offre il protocollo UDP? CLTS!
• Consegna inaffidabile di un messaggio (user datagram) tra due endpoint.
• I datagram possono essere persi, corrotti, ritardati, duplicati, arrivare
fuori ordine.
• Non e' fornita alcuna funzione di flow-control tra i due end-point:
e’ cosi' possibile che un end-point riceva messaggi ad una velocita'
maggiore di quanto esso riesca a consumarli (e quindi li debba
scartare).
• E’ il layer applicativo, utente di UDP, che non riesce a trattare
abbastanza velocemente i messaggi che gli arrivano tramite UDP.
• UDP puo’ bufferare messaggi che gli sono arrivati ma che il layer
utente non ha ancora letto, ma lo spazio di bufferamento e’ finito.
28
Host, processi, servizi: UDP
.2
• Il servizio offerto da UDP e’ (circa) lo stesso tipo di servizio offerto da IP,
ma
• IP lo fornisce tra host
(end-point = host, in realta’ end-point = protocollo di Trasporto)
• UDP lo fornisce tra porte (end-point = porta UDP),
e, tramite le porte, tra processi applicativi.
• Quale e' il valore aggiunto di UDP rispetto a IP?
La capacita' di distinguere tra porte (destinazioni / processi applicativi)
diverse all'interno di uno stesso host.
• In IP esiste un NSEL, analogo al TSEL (alla porta) che distingue i diversi
TSAP UDP, ma ha caratteristiche piu’ limitative:
• C’e’ un unico campo Protocol nel datagram IP, quindi i due lati della
comunicazione devono condividere uno stesso NSEL.
• Il campo Protocol e’ limitato a soli 8 bit, quindi sono possibili solo 256
NSEL diversi.
• Notare che anche l’EtherType deve essere uguale ai due lati della
comunicazione Data Link.
29
Multiplexing e de-multiplexing
• UDP e' esemplificativo di un’altra funzione tipica dei layer
dell'architettura di rete: il de/multiplexamento delle comunicazioni.
• UDP offre il proprio servizio tramite diverse porte a diversi clienti.
• Per implementare il proprio servizio UDP utilizza un (solo) NSAP
del protocollo IP
(Valore del campo Protocol del datagram IP uguale a 17.
Per TCP il campo Protocol del datagram IP vale 6.
L'NSAP e' dato dalla concatenazione di un indirizzo IP del nodo e
del valore del campo Protocol utilizzato.)
• UDP di conseguenza
• multiplexa il traffico in trasmissione da n TSAP (le sue porte) ad
un singolo NSAP, e
• demultiplexa il traffico in ricezione da un singolo NSAP a n
TSAP (le sue porte).
30
Formato di un datagram UDP
• In che modo sono descritti i PDU del protocollo UDP?
• La descrizione dei PDU avviene in termini di mappe di byte e di bit,
come per tutti i protocolli dei layer  6 (6 = Presentazione).
0
15 16
31
UDP source port
UDP destination port
UDP message length
UDP checksum
data
...
• E si specifica che:
• Il PDU e’ costituito da un numero intero di parole di 32 bit
• I byte all'interno di una parola sono in ordine big-endian.
• I bit all'interno di un byte sono in ordine big-endian (un must!).
• Gli interi (unsigned) sono espressi come numeri binari.
• Notare che ci sono due campi diversi (di 2 byte ciascuno) per indicare
il numero di porta (UDP) dei due lati della comunicazione.
31
• I due numeri di porta possono essere diversi.
• I due TSAP possono avere TSEL diverso!
UDP: segmentazione?
• Dal formato del PDU UDP risulta che la lunghezza massima di un
messaggio e’ limitata a 216.
• Ma la lunghezza massima effettiva di un messaggio UDP non e’
cosi’ grande:
 Attualmente e’ spesso ancora limitata a soli 213 Byte (=8 KByte).
 In passato e’ stata anche piu’ limitata, 512 Byte!
• Questo perche’ UDP non supporta la segmentazione dei TSDU.
• La lunghezza massima effettiva del TSDU UDP e’ legata alla
dimensione massima del PDU UDP che e’ vincolata dalla
dimensione massima del datagram IP:
 Uno user datagram UDP e’ trasportato all’interno di un singolo
datagram IP.
 UDP e’ un servizio message oriented:
UDP preserves the boundaries of the TSDUs.
32
Broadcast di sottorete UDP
• Oltre che comunicazioni unicast IP supporta anche comunicazioni
 Multicast
 Broadcast di sottorete
• UDP supporta tutti gli stili di comunicazione multicast e broadcast
supportati da IP
• Quindi, ad esempio, una applicazione che risiede su un nodo
collegato alla sottorete R puo’ inviare un messaggio broadcast a
tante applicazioni (a tante porte UDP destinazione), ciascuna
residente su un nodo collegato alla stessa sottorete R
• Ovviamente, data la struttura dell’indirizzo di una porta UDP, tutte le
porte UDP destinazione del datagram devono condividere lo stesso
numero di porta
 Quello che e’ supportato e’ il broadcasting verso diverse istanze
dello stesso tipo di servizio allocate su nodi diversi
• Lo stesso discorso si applica per messaggi UDP multicast
33