Lez. 21 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena Reti di Calcolatori Indirizzamento Il Layer di Trasporto – CLTS Vedi: D. Comer, Internetworking.

Presentazione sul tema: "Lez. 21 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena Reti di Calcolatori Indirizzamento Il Layer di Trasporto – CLTS Vedi: D. Comer, Internetworking."— Transcript della presentazione:

1 Lez. 21 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.

2 2 Host, processi, servizi.1 Il protocollo IP e' capace di trasferire datagram tra diversi host (end- system) 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 lapplicazione 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 lindirizzamento del server: questi puo limitarsi a rispondere ai client che lo hanno contattato e che ragionevolmente gli hanno fornito il proprio indirizzo.

3 3 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 dellapplicazione 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).

4 4 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.

5 5 nSAP.1 Un nSAP e: Un punto daccesso ai servizi di rete di livello n da parte di una protocol entity di livello (n+1). Lindirizzo univoco sulla rete di una protocol entity di livello (n+1). La struttura dellidentificativo 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 lnSAP. DellnSEL (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). n-level protocol entity (n-1)SAP nSAP 1 nSAP m... nSAP 1 = (n-1)SAP + nSEL 1 … nSAP m = (n-1)SAP + nSEL m

6 6 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 luno dallaltro 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 unapplicazione 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.

7 7 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.

8 8 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 loperatore (il processo) che ci fornisce il servizio, quello che ci interssa e ottenerlo. Ma di per se non ci interessa nemmeno chiamare l800-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 associato ad un certo servizio applicativo.

9 9 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 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 un cliente riesce a raggiungerlo. Implementazione di un TSAP su Internet NSAP OSI

10 10 Internet layer e SAP.1 Ethernet - MAC address A Ethernet - MAC address B ARP Ethertype = 2054 Ethertype = 2048 ICMP Protocol = 1 Protocol = 17 Protocol = 6 TCPUDP TCP port = 111 UDP port = 111 Port Mapper UDP port = 69 UDP port = 161 TFTP server TCP port = 21 FTP server TCP port = 80 HTTP server IP address A1.A2.A3.A4 IP IP address B1.B2.B3.B4 SNMP agent

11 11 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:NSAP TCP + (TCP port = 21) TFTP server o TSAP:NSAP UDP + (UDP port = 69)

12 12 Struttura di un datagram IP e individuazione dellNSAP destinazione (da Tanenbaum) Indirizzo IP NSEL: notare che ce 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.

13 13 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 dellapplicazione distribuita. Linterazione 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. Lindirizzo di una protocol entity del Layer Applicativo e quello del TSAP attraverso cui avvengono le sue comunicazioni.

14 14 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). Lutente 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. LAPI IP e unAPI interna del sistema (non proprio vero). Il limite e evidenziato anche dal fatto che lNSEL (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.

15 15 Indirizzo di rete.1 Perche come indirizzo della protocol entity IP non uso un suo/i suoi DlSAP (in effetti allinterno 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 dellindirizzo 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, dallindirizzo 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?

16 16 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 lindirizzo 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 (nellesempio, 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. Nellesempio: TSAP=A1.A2.A3.A4 or B1.B2.B3.B4 or 127.0.0.1:80. 127.0.0.1 e lindirizzo di un qualunque nodo IP sulla propria sottorete di loopback.

17 17 O:\>ipconfig /all Configurazione IP di Windows Nome host.............. : csalati-xp Suffisso DNS primario....... : dl.net Routing IP abilitato......... : No Elenco di ricerca suffissi DNS.... : dl.net datasensor.corp psc.pscnet.com pscnet.com Scheda Ethernet connessione alla intranet Datalogic: Suffisso DNS specifico per connessione: dl.net Descrizione............. : Broadcom NetXtreme 57xx Gigabit Controller Indirizzo fisico........... : 00-14-22-31-0B-9D DHCP abilitato............ : Sì Configurazione automatica abilitata : Sì Indirizzo IP............. : 172.16.2.64 Subnet mask............. : 255.255.0.0 Gateway predefinito......... : 172.16.255.254 Server DHCP............. : 172.16.0.5 Server DNS............. : 172.16.0.5 172.16.0.6 Configurazione di una interfaccia IP/Ethernet Nome della macchina: csalati-xp.dl.net Indirizzo IP del router da utilizzare Ben 2 server DNS!? A cosa servono? Indirizzo del nodo nella sottorete Indirizzo IP sulla sottorete Indirizzo della sottorete vs. indirizzo del nodo

18 18 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!). Ce 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)!

19 19 Indirizzi di rete pubblici e privati sottorete ES IS ES IS sottorete IS intranet

20 20 Indirizzi IP particolari Nellarchitettura 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 dellindirizzo 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 sullES A puo utilizzare lindirizzo 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 lNSAP/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

21 21 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 dellindirizzo di sottorete e quanti fanno parte dellindirizzo di nodo sulla sottorete e definito dalla netmask della sottorete E possibile indirizzare tutti i nodi di una sottorete concatenando allindirizzo della sottorete un campo indirizzo di nodo di bit tutti a 1 Oltre allindirizzo 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

22 22 Associazione client - server Un servizio applicativo e associato ad una porta ben nota (well known port). Il processo (server) che offre quel servizio applicativo sullhost 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 sullhost S, sa che esso e offerto sulla porta di trasporto well known relativa, ed indirizzera quindi le sue richieste a questa porta dellhost S. Lautorita che si occupa di gestire/garantire lassociazione 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)

23 23 Associazione client - server E la IANA che gestisce / assegna tutti i numeri importanti di internet. E la IANA che ha stabilito che lEthernet 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

24 24 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 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 interessa.

25 25 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 allindirizzo 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 questultimo. Le porte utilizzate dai processi client possono avere numero qualunque, purche siano univoche relativamente alla protocol entity di Trasporto che le supporta.

26 26 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 lunico 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 gestisce il conto corrente).

27 27 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 liniziativa 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 dallaltro 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 client- server il problema del servizio T-CONNECT per cui simultaneous T-CONNECT requests typically result in a corresponding number of TCs risulta irrilevante!

28 28 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 end- point. 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.

29 29 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: Ce 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 lEtherType deve essere uguale ai due lati della comunicazione Data Link.

30 30 Multiplexing e de-multiplexing UDP e' esemplificativo di unaltra 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).

31 31 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). 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. I due numeri di porta possono essere diversi. I due TSAP possono avere TSEL diverso! UDP source portUDP destination port UDP message lengthUDP checksum data... 0151631

32 32 UDP: segmentazione? Dal formato del PDU UDP risulta che la lunghezza massima di un messaggio e limitata a 2 16. Ma la lunghezza massima effettiva di un messaggio UDP non e cosi grande: Attualmente e spesso ancora limitata a soli 2 13 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 allinterno di un singolo datagram IP. UDP e un servizio message oriented: UDP preserves the boundaries of the TSDUs.

33 33 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 dellindirizzo 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