11. Protocollo di trasporto a datagramma: User Datagram Protocol (UDP) 11.1. Introduzione È il più semplice protocollo di trasporto 11.2. Identificare la destinazione finale La macchine sono multiprogrammate: numerosi processi vogliono accedere ai servizi di comunicazione non basta un servizio da macchina a macchina! Non si può indirizzare i vari processi con il loro nome perché: 1. cambia dinamicamente 2. vorremmo poter cambiare il processo ricevente senza che il mittente ne debba essere informato 3. il processo destinazione deve essere caratterizzato dalla sua funzione 4. un processo potrebbe svolgere più funzioni (ad es. in macchina monoprogrammata) introdurre delle destinazioni astratte, dette protocol port in internet (transport selector in OSI) identificate da numeri interi positivi: il sistema operativo deve fornire chiamate per accedere o registrarsi ad una porta In che modalità si accede ad una porta? Spesso sincrona = il processo si blocca durante tutta l'operazione di accesso alla porta (spedizione o ricezione); spedizione blocca solo per l'elaborazione locale Pagina 11.1
In generale le porte sono bufferizzate = quando un messaggio viene ricevuto viene memorizzato se il ricevente non ha già eseguito la system call di ricezione (notare: non in tutti i sistemi operativi!); bufferizzazione anche in spedizione, per congestione locale sulla interfaccia Quindi per poter comunicare con il proprio pari, un processo deve conoscere l'indirizzo IP della macchina su cui il pari esegue e il numero di porta su cui il pari ascolta: destination port. È necessario comunicare la source port sulla quale ci si attende la risposta 11.3. UDP È un servizio di trasporto a datagramma, cioè connectionless (quindi molto simile a IP). Oltre ai dati spediti, ogni messaggio UDP contiene la destination port e la source port L'affidabilità è la stessa di IP (non c'è!), perché l'unico servizio aggiunto a IP è l'indirizzamento su porta (la prima delle funzioni fondamentali di un servizio di comunicazione!) 11.4. Formati dei messaggi UDP 0 16 31 UDP SOURCE PORT UDP MESSAGE LENGHT DATA... UDP DESTINATION PORT UDP CHECKSUM Come si vede le porte sono interi positivi a 16bit. SOURCE PORT può essere lasciata a zero (assente). LENGTH include l'header. CHECKSUM a zero indica che è assente (quando viene zero per la somma in complemento a 1, si usa lo zero con tutti i bit a uno) Pagina 11.2
11.5. UDP pseudo-header UDP vuole controllare non solo la correttezza dei propri dati ma manche che il messaggio sia stato consegnato (da IP) all'indirizzo giusto, dalla sorgente giusta, con il PROTOCOL giusto. Allora prima di spedire e alla ricezione calcola la checksum prependendo al messaggio uno pseudo-header (che non viene trasmesso): 0 8 16 31 SOURCE IP ADDRESS DESTINATION IP ADDRESS ZERO PROTO UDP LENGTH PROTO = 17 per UDP Pagina 11.3
11.6. Incapsulamento e stratificazione Stratificazione concettuale Applicazione UDP IP Network Interface Notare che questa stratificazione implica anche un completo incapsulamento di UDP nei dati di IP UDP HEADER UDP DATA IP HEADER IP DATA AREA FRAME HEADER FRAME DATA AREA Le protocol data unit (PDU) di ciascun protocollo (UDP e IP) sono imbustate una nell'altra e infine nel frame della sottorete fisica. All'arrivo ciascuno strato esamina il proprio header, decide cosa fare su questa base, e se è il caso consegna all'utilizzatore sovrastante la PDU relativa (più informazioni utili di sua pertinenza, quali gli IP address sorgente e destinazione) IP identifica gli host sorgente e destinazione; UDP identifica le porte sorgente e destinazione Pagina 11.4
11.7. Stratificazione e calcolo della checksum UDP UDP ha bisogno degli IP address sorgente e destinazione per calcolare la sua checksum. È questa una violazione dl principio della stratificazione? Il libro sostieni di sì, ma dimentica che informazioni quali PROTOCOL number, e IP address sono necessarie perché l'interazione fra IP e IP-user avvenga come l'ip-user desidera: mancherebbe altro che fosse IP a decidere dove spedire un pacchetto, oppure non informasse l'ip-user della sorgente di un pacchetto che gli consegna: è un esempio dei deliri a cui si può arrivare quando si scambiano considerazioni progettuali con dogmi religiosi! 11.8. UDP: multiplexing, demultiplexing, e porte Come anticipato, UDP esegue un multiplexing (e relativo demultiplexing, non c'è uno senza l'altro!) di IP mediante il concetto di porta Porta 1 Porta 2 Porta 3 Porta A Porta B Porta C UDP: Demultiplexing basato su Porte UDP: Multiplexing basato su Porte Arriva un datagramma UDP Spedisce un datagramma UDP Strato IP Strato IP Pagina 11.5
Una porta può esser pensata come una coda realizzata dal sistema operativo. Prima di operare su una porta, un processo deve chiedere al sistema operativo di essere l'utilizzatore di tale porta. A questo punto il SO crea la coda Se arriva un datagramma per una porta non in uso, il SO lo scarta e invia un messaggio ICMO di port unreachable. Se al coda della porta è piena il SO scarta il datagramma in arrivo (Source Quench? provare!) Attenzione: alcuni sistemi operativi (si dice) non associano alcuna coda ad una porta UDP: se il processo non è già in attesa quando arriva il datagramma UDP, questo viene scartato! 11.9. Numeri di porta UDP riservati e disponibili Come fa un mittente a sapere il numero di porta su cui spedire? La risposta giusta è che ci dovrebbe essere un directory sul quale andare a cercare quale sia il numero di porta che corrisponde su una certa macchina a una certa applicazione distribuita Internet ha sempre cercato prima soluzioni semplici anche se più limitate. Quindi in internet i numeri di porta sono di due tipi: wellknown e dinamiche Le porte well-known sono assegnate da un Internet Standard. Sul libro sono listate alcune. Non si dovrebbero usare se non per l'uso per cui sino state definite. In Unix c'è un file di sistema (/etc/services) che contiene la lista delle porte well-known Le altre porte sono usabili dinamicamente dai programmi applicativi Pagina 11.6
11.10. Conclusioni Abbiamo visto il primo (dei due) servizi di trasporto definiti in internet: UDP È educativo perché la sua unica funzione è quella di rendere disponibile la prima funzionalità fondamentale di un servizio di trasporto: la consegna end-to-end di messaggi da processo a processo (invece che da macchina a macchina come fa la rete). Conseguentemente, deve fornire una funzione di mux-demux sulle porte definite su una macchina UDP non fa altro che questo, perché per il resto utilizza IP come portatore dei propri messaggi Pagina 11.7