Basi di network programming sotto Unix/Linux (draft version) Claudio Piciarelli

Transcript

1 Basi di network programming sotto Unix/Linux (draft version) Claudio Piciarelli 20 dicembre 2004

2 ii

3 Indice 1 Introduzione Notazioni e terminologia Un po di premesse Il network byte order Strutture per gli indirizzi Gestire gli indirizzi gethostbyname() gethostbyaddr() inet ntoa() inet aton() getsockname() getpeername() Connessioni TCP/IP Funzionamento dei protocolli IP e TCP I socket connect() Lettura e scrittura Chiusura della connessione Un client basato su TCP: l idea Un client basato su TCP: il codice Funzioni per i server: bind(), listen() e accept() Un server basato su TCP: l idea Un server basato su TCP: il codice Come usare inetd Un server che utilizza inetd: il codice UDP/IP Funzionamento del protocollo UDP Un semplice client UDP Un semplice server UDP Approfondimenti 27 iii

4 iv INDICE

5 Capitolo 1 Introduzione Questo breve testo cerca di dare al lettore le conoscenze di base per poter iniziare a scrivere programmi orientati al networking. L argomento è molto vasto e questo testo non ha alcuna pretesa di essere esauriente; in particolare ci occuperemo solo di come poter trasmettere e ricevere dati utilizzando i protocolli TCP e UDP, senza trattare altri protocolli di diversa natura (ad es. IPX) o di livello più alto (SMTP, POP3, NNTP ecc.). Daremo per scontate delle nozioni minime di networking e la conoscenza del linguaggio C. Inoltre, citando Aleph1, un prerequisito fondamentale è il possesso di un cervello, di una mente o di un qualsiasi altro device pensante equivalente. Se trovate qualche errore in questo documento, non esitate a segnalarlo all indirizzo piccia(at)dimi.uniud.it 1.1 Notazioni e terminologia Prima di iniziare è bene mettersi d accordo sulle convenzioni di scrittura e sul significato di alcuni termini usati in questo testo. Notazioni: * Ad ogni funzione di importanza rilevante è associata una scheda riassuntiva che indica gli header da includere, la dichiarazione formale, la lista dei parametri (ad ognuno dei quali è associato un sintetico commento) e il valore di ritorno. * le porzioni di codice sono indentate rispetto al testo normale. * i comandi da eseguire da shell sono preceduti dal prompt $ Nelle parti di testo che non rappresentano porzioni di codice o schede di funzioni... * tutti i nomi di funzione sono seguiti dalle parentesi tonde (). Es: socket(). * i tipi di dati sono compresi tra apici singoli. Es: struct sockaddr. * le costanti sono comprese tra apici inversi. Es: INADDR LOOPBACK. * i nomi di variabili sono compresi tra apici doppi. Es: s. Terminologia: datagramma : unità di trasmissione dei protocolli IP e UDP pacchetto : unità di trasmissione tra il livello IP e il sottostante livello data link. Ad esempio un datagramma IP può essere suddiviso in più frammenti, ognuno dei quali è un pacchetto. segmento : unità di trasmissione del protocollo TCP 1

6 2 CAPITOLO 1. INTRODUZIONE

7 Capitolo 2 Un po di premesse 2.1 Il network byte order Uno dei problemi che si deve affrontare lavorando con architetture diverse è quello della cosiddetta endianity. Il problema riguarda l ordine in cui i byte vengono memorizzati in RAM nelle varie architetture hardware. Per capire di cosa si tratta, è utile iniziare subito con un esempio pratico. Prendiamo un numero intero di tipo long, che nella maggior parte della macchine attuali è lungo 32 bit, o equivalentemente 4 byte. Ad esempio: Sì, duemiliardicinquecentoventimilioniseicentomiladuecentododici. Se convertiamo questo numero in esadecimale, otteniamo: 963D4E94 o, in binario: Possiamo quindi rappresentare questo numero con 4 gruppi di 8 bit, ovvero 4 byte (binario) 96 3D 4E 94 (esadecimale) MSB LSB Il byte più a sinistra si chiama Most Significant Byte (MSB), mentre quello più a destra è detto Least Significan Byte (LSB). Il perché di questi nomi è facile da intuire: il byte più a sinistra è quello che pesa di più, mentre quello più a destra è quello che pesa di meno. E come dire che, nel numero , l 1 è la cifra più importante, perché rappresenta i milioni, mentre il 7 è quella meno importante, perché rappresenta le unità. La memoria RAM di un computer è vista come una sequenza di byte, ognuno con il suo indirizzo. E lecito quindi chiedersi in che ordine i 4 byte visti prima vengano memorizzati quando vogliamo scrivere in memoria un intero di tipo long. La risposta è: dipende dall architettura. I processori Intel x86 ad esempio memorizzano per primo il byte meno significativo (LSB) e per ultimo quello più significativo, quindi in memoria il nostro numero verrebbe rappresentato come: 94 4E 3D 96 i processori motorola 68x00 invece memorizzano prima il byte più signficativo, ovvero: 96 3D 4E 94 3

8 4 CAPITOLO 2. UN PO DI PREMESSE Nel primo caso si parla di approccio little endian, il secondo è invece detto big endian. Perchè tutta questa lunga digressione sulla rappresentazione in memoria dei numeri? Semplice: nella programmazione di applicazioni orientate alle connessioni di rete ci si trova inevitabilmente a dover scambiare con altri host alcuni dati di tipo long o short. Ad esempio un indirizzo IP è composto da 32 bit (per ora - le cose cambieranno con IPv6) e quindi è semplicemente un long. Allo stesso modo una porta è un numero compreso tra 0 e 65535, quindi rappresentabile con 16 bit, ovvero uno short. Se ogni programma memorizzasse gli indirizzi nei pacchetti IP a seconda dell endianità dell architettura su cui gira sarebbe un disastro: macchine con architetture diverse non riuscirebbero a comunicare tra loro; un PC e un Macintosh ad esempio non potrebbero condividere una connessione TCP per il semplice fatto che usano metodi diversi per rappresentare le porte e gli indirizzi. Poichè la rete Internet (e, assieme ad essa, i protocolli IP e TCP) è stata concepita per permettere la comunicazione tra elaboratori indipendentemente dalla loro architettura, si è reso necessario l utilizzo di una rappresentazione comune, una sorta di lingua franca a cui tutti i software di rete devono conformarsi: questa rappresentazione dei numeri è detta Network Byte Order. (per i più curiosi, il network byte order dovrebbe essere equivalente al big endian). Risulta quindi necessario avere delle funzioni che permettano di convertire i numeri dal formato locale (Host Byte Order) a quello di rete. Sotto linux queste funzioni sono: #include <netinet/in.h> dichiarazioni: unsigned long int htonl (unsigned long int n); unsigned short int htons (unsigned short int n); unsigned long int ntohl (unsigned long int n); unsigned short int ntohs (unsigned short int n); n: numero da convertire il numero convertito Il nome delle funzioni dice tutto: htonl() significa host to network long e converte appunto un long dal formato locale a quello di rete; la funzione ntohl() fa ovviamente l operazione inversa. Le altre due funzioni, ntohs() e htons(), sono equivalenti a ntohl() e htonl(), ma lavorano con gli short integer. 2.2 Strutture per gli indirizzi Come vedremo in seguito, molte funzioni devono ricevere come parametri degli indirizzi e dei numeri di porta; per rappresentare questi dati si utilizza la struttura struct sockaddr. La cosa curiosa, e che spesso confonde i programmatori alle prime armi, è che questa struttura non viene mai utilizzata direttamente dal programmatore, sebbene sia richiesta come parametro da molte funzioni! Il motivo di tutto ciò è molto semplice, e nasce da una necessità di generalizzazione. Funzioni come bind(), connect() o altre che vedremo in seguito, sono progettate per funzionare con diversi tipi di protocolli: non esiste solo il TCP/IP, ci sono ad esempio IPX (usato nelle reti Novell), Appletalk, X25 ecc. Ognuno di questi protocolli tuttavia necessita di una struttura ad hoc adatta a contenerne gli indirizzi, e queste strutture sono diverse l una dall altra. La struttura struct sockaddr in realtà non è altro che un wrapper, che serve a nascondere le differenze tra le strutture specifiche dei vari protocolli. Se per esempio vogliamo usare il protocollo IPX definiremo i nostri indirizzi con la struttura apposita ( struct sockaddr ipx ) e poi faremo un type cast a struct sockaddr ogni volta che sarà necessario utilizzarla. Un esempio come al solito chiarirà le idee. sockaddr in, definita in <netinet/in.h>: La struttura usata per gli indirizzi IP è la struct struct sockaddr_in {

9 2.3. GESTIRE GLI INDIRIZZI 5 short sin_family; short sin_port; struct in_addr sin_addr; dove a sua volta la struct in addr è definita come: struct in_addr { long s_addr; In sin family va sempre messa la costante AF INET, in sin port la porta e in sin addr.s addr l indirizzo IP (questi ultimi due in network byte order!). Tutte le volte che una funzione richiederà una struct sockaddr come parametro, sarà sufficiente passare come argomento la nostra struct sockaddr in usando un type cast: struct sockaddr_in s; s.sin_family = AF_INET; s.sin_port = htons(25); s.sin_addr.s_addr = htonl(inaddr_loopback); connect(..., (struct sockaddr *) &s,...); In questo caso la funzione connect() richiede (oltre ad altri parametri che sono stati omessi) un puntatore a struct sockaddr, tuttavia è stato passato come argomento un puntatore ad una struct sockaddr in, ingannando la connect() con il type cast (struct sockaddr *). In questo modo si ottiene la generalizzazione cercata: la funzione connect() riceve comunuque sempre e solo delle struct sockaddr, le quali però in realtà sono delle strutture più specifiche, a seconda del protocollo utilizzato. 2.3 Gestire gli indirizzi Abbiamo visto precedentemente come gli indirizzi IP siano rappresentati dalla struttura struct in addr, che contiene un solo elemento, il long s addr. Ma come trovare gli indirizzi che ci servono? La libc ci viene incontro con alcune funzioni molto utili; qui di seguito verranno analizzate le più importanti gethostbyname() #include <netdb.h> dichiarazione: struct hostent *gethostbyname(const char *name); *name: stringa contenente l hostname o un indirizzo IP numerico una struttura contenente i dati dell host Questa funzione permette di trovare l indirizzo IP di una macchina, data una stringa che contiene un hostname (es: pippo.pluto.com ) o un indirizzo numerico (es: ). Il sistema operativo si occupa di risolvere il nome nella maniera più opportuna, ad esempio cercandolo in /etc/hosts o interrogando un DNS. Il risultato viene salvato in una struct hostent, il cui formato è il seguente: struct hostent { char *h_name; /* nome ufficiale dell host */ char **h_aliases; /* lista di alias */ int h_addrtype; /* tipo di indirizzo (vale sempre AF_INET ) */

10 6 CAPITOLO 2. UN PO DI PREMESSE int h_length; /* lunghezza dell indirizzo in bytes */ char **h_addr_list; /* lista di indirizzi */ #define h_addr h_addr_list[0] /* il primo indirizzo */ Il campo più importante è h addr (che in realtà è definito come primo elemento della lista h addr list). Anche se non sembra, h addr punta ad una struct in addr, e quindi al suo interno contiene l unico elemento s addr, che è una long rappresentante l indirizzo IP in formato Network Byte Order. Notate tuttavia che h addr è definito come un char * e non come una struct in addr * (sempre per motivi di generalizzazione). Si rende quindi necessaria la presenza di h length, che contiene la lunghezza in byte della struttura puntata da h addr. Se ad esempio vogliamo memorizzare l indirizzo appena trovato con gethostbyname() in una struct sockaddr in, sarà necessario scrivere: struct sockaddr_in s; struct hostent *h; h = gethostbyname("localhost"); memcpy(&s.sin_addr, h->h_addr, h->h_length); in questo esempio la funzione memcpy() prende la struct in addr puntata da h addr e la copia in s.sin addr gethostbyaddr() #include <netdb.h> dichiarazione: struct hostent *gethostbyaddr(const char *addr, int len, int type); *addr: puntatore ad una struct in\_addr (type cast a char *) len : lunghezza della struttura puntata da addr type : tipo di indirizzo (vale sempre AF\_INET ) una struttura contenente i dati dell host Questa funzione, come dice il nome, fa il lavoro inverso di gethostbyname(). Prende in input una struct in addr (di cui è stato fatto il type casting a char *), la lunghezza della struttura e il tipo di indirizzo (che è sempre AF INET ). Anche gethostbyaddr() ritorna una struct hostent, in cui è memorizzato il nome dell host cercato nel campo h name. Un esempio del suo utilizzo: struct in_addr a; struct hostent *h; a.s_addr = htonl(inaddr_loopback); h = gethostbyaddr((char *) &a, sizeof(a), AF_INET); printf("il nome è: %s\n", h->h_name); Poichè INADDR LOOPBACK è una costante che indica l indirizzo , il risultato dell esecuzione di questo codice dovrebbe essere: il nome è: localhost inet ntoa() #include <sys/socket.h> #include <netinet/in.h>

11 2.3. GESTIRE GLI INDIRIZZI 7 #include <arpa/inet.h> dichiarazione: char *inet_ntoa(struct in_addr in); in: struct in_addr contenente un indirizzo una stringa rappresentante l indirizzo IP Il funzionamento di questa funzione è banale: data una struct in addr restituisce una stringa con l indirizzo IP espresso in formato numbers-and-dots. Ad esempio il codice: a.s_addr = htonl(inaddr_loopback); printf("l indirizzo è: %s\n", inet_ntoa(a)); dà come risultato l indirizzo è: Il nome della funzione significa network to ASCII inet aton() #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> dichiarazione: int inet_aton(const char *cp, struct in_addr *inp); *cp : stringa rappresentante un indirizzo IP *inp: struct in_addr in cui salvare il risultato un numero diverso da zero se l indirizzo è valido, 0 altrimenti Ovviamente la simmetrica di inet ntoa(). Presa una stringa con un indirizzo IP in formato numbers-anddots, lo trasforma in una struct in addr. Il risultato è salvato nella struttura passata come argomento getsockname() #include <sys/socket.h> dichiarazione: int getsockname(int s, struct sockaddr *name, socklen_t *namelen); s : un socket *name : struttura in cui salvare il risultato *namelen: lunghezza di name, in byte 0 in caso di successo, -1 in caso di errore Questa funzione salva in name i dati relativi all indirizzo a cui il socket s è stato associato tramite la funzione bind().

12 8 CAPITOLO 2. UN PO DI PREMESSE getpeername() #include <sys/socket.h> dichiarazione: int getpeername(int s, struct sockaddr *name, socklen_t *namelen); s : un socket *name : struttura in cui salvare il risultato *namelen: lunghezza di name, in byte 0 in caso di successo, -1 in caso di errore Analoga a getsockname(), ma ritorna l indirizzo dell host remoto a cui il socket è connesso.

13 Capitolo 3 Connessioni TCP/IP 3.1 Funzionamento dei protocolli IP e TCP IP è un protocollo per la trasmissione dei dati inaffidabile e connectionless, ovvero non orientato alla connessione. Questo significa che non possiamo sapere nulla della sorte di un datagramma IP dopo averlo inviato: i router cercheranno di farlo arrivare a destinazione (e questo è infatti l unico scopo di IP), ma non ci viene garantito nulla riguardo al percorso seguito dai datagrammi, al loro ordine di arrivo, o addirittura all arrivo stesso: il datagramma potrebbe venire perso lungo il tragitto senza che il mittente venga notificato di quanto è accaduto. TCP al contrario, pur viaggiando incapsulato nei datagrammi IP, è un protocollo di trasmissione dei dati affidabile e orientato alla connessione. Orientato alla connessione significa che questo protocollo implementa una forma di comunicazione point-to-point, in cui due host che vogliano scambiarsi dei dati sono alle due estremità di un canale di comunicazione che li collega. Il paragone più classico in questo caso è quello del telefono: quando Tizio telefona a Caio, si crea tra di loro una sorta di tunnel virtuale che li mette in contatto: non importa il modo in cui effettivamente la telefonata è gestita dall operatore telefonico, dal punto di vista dell utente è come se ci fosse un cavo che collega direttamente i due apparecchi. Affidabile significa che TCP ci garantisce la corretta ricezione dei dati trasmessi. In altre parole TCP pone rimedio a tutti i problemi del protocollo sottostante (IP), garantendo l arrivo dei dati e la loro corretta ricostruzione nel caso arrivino in un ordine diverso da quello di spedizione. Il risultato finale è un protocollo che offre un alto livello di astrazione. La suddivisione dei dati spediti in segmenti è infatti compito del protocollo stesso e non dell utente (a differenza di quanto vedremo accadere con UDP); in questo modo l utente vede solo un flusso (stream) di byte che viaggiano da un host all altro, cosa che rende la trasmissione dei dati molto più flessibile e semplice da gestire. Ricordiamo infine che TCP introduce il concetto di porta. Se l indirizzo IP identifica univocamente un host, le porte TCP sono i vari ingressi (o uscite) verso (da) quell host: ogni connessione TCP proviene da una porta ed è diretta verso una porta. In questo modo tutte le connessioni sono univocamente identificate da quattro valori: indirizzo IP sorgente, indirizzo IP di destinazione, porta sorgente, porta di destinazione. 3.2 I socket Il concetto più importante nella programmazione di rete è forse quello del socket. Per capire cosa sia un socket, è utile ricorrere all analogia telefonica vista precedentemente. Se paragoniamo una connessione TCP ad una connessione telefonica, allora il socket è il telefono stesso. Dal punto di vista del programma applicativo i socket sono i punti di accesso alla rete, o meglio il punto di contatto tra il programma e il kernel sottostante che gestisce le connessioni TCP; ogni connessione TCP ha due socket alle estremità, proprio come ogni telefonata avviene tra due telefoni. Il nostro programma si occuperà solo di gestire un socket, senza preoccuparsi troppo del funzionamento del protocollo TCP stesso, così come un utente te- 9

14 10 CAPITOLO 3. CONNESSIONI TCP/IP lefonico interagisce solo con il telefono, senza chiedersi come la telefonata venga effettivamente instradata. Più concretamente, dal punto di vista del programmatore il socket è molto simile ad un file descriptor, proprio come quelli ottenuti tramite la funzione open(). Su un socket è possibile effettuare operazioni di lettura e scrittura, proprio come su un file discriptor, e in generale la somiglianza tra le due entità è tale da permette di applicare ai socket molte funzioni che solitamente sono utilizzate con i file descriptor: ad esempio vedremo che, tramite fdopen(), sarà possibile associare uno stream (ovvero un FILE * ) ad un socket. Per creare un socket, si usa la funzione omonima: #include <sys/types.h> #include <sys/socket.h> dichiarazione: int socket(int domain, int type, int protocol); domain : il dominio di comunicazione del socket type : semantica di comunicazione protocol: il protocollo da utilizzare un descrittore che identifica il socket, o -1 in caso di errore Domain è una costante che indica quale famiglia di protocolli verrà utilizzata con quel socket e nel caso di una connessione TCP assume il valore PF INET ; nella man page di socket() potrete trovare tutti gli altri possibili valori utilizzabili. Type indica invece il tipo di comunicazione usata e nel caso del TCP deve assumere il valore costante SOCK STREAM. Protocol infine indica il tipo di protocollo da utilizzare. Tipicamente domain e type identificano univocamente un solo protocollo possibile, quindi non è necessario specificare esplicitamente questo parametro: sarà sufficiente usare il valore 0 per lasciare al sistema operativo il compito di decidere da solo il protocollo più adatto da usare. Il valore ritornato è un socket; si tratta di un semplice int, esattamente come accade per i file descriptor. Riassumendo, per creare un socket da utilizzare in una connessione TCP è sufficiente scrivere: int s; s = socket(pf_inet, SOCK_STREAM, 0); 3.3 connect() Se vogliamo connetterci ad un host remoto, una volta creato un socket dobbiamo inizializzare una connessione TCP ed associarla al socket stesso. Per farlo si utilizza la funzione connect(): #include <sys/types.h> #include <sys/socket.h> dichiarazione: int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen); sockfd : socket da associare alla connessione *serv_addr: indirizzo del server addrlen : lunghezza in byte della struttura puntata da serv_addr

15 3.4. LETTURA E SCRITTURA 11 0 in caso di successo, -1 in caso di errore connect() apre una connessione verso un host remoto. Il primo parametro è il socket creato con socket(), il secondo è un puntatore alla struct sockaddr in che contiene l indirizzo e la porta a cui dobbiamo collegarci (come al solito è richiesto un type cast a struct sockaddr * ) mentre l ultimo parametro deve contenere la lunghezza in byte della struttura stessa. connect() ritorna 0 in caso di successo e -1 in caso di errore. 3.4 Lettura e scrittura Una volta instaurata una connessione TCP con socket() e connect(), come possiamo comunicare con l host remoto? Esistono due funzioni apposite per la lettura e scrittura su socket: #include <sys/types.h> #include <sys/socket.h> dichiarazioni: int recv(int s, void *buf, size\_t len, int flags); int send(int s, const void *msg, size\_t len, int flags); s : descrittore da cui leggere o su cui scrivere *buf/*msg: buffer in cui salvare i dati letti o contenente i dati da spedire len : dimensione del buffer flags : flag aggiuntivi valori di ritorno: il numero di byte ricevuti o spediti, -1 in caso di errore Tuttavia nella maggior parte dei casi non è necessario ricorrere a queste funzioni. Ricordiamo infatti che un socket viene trattato come un file descriptor, quindi possiamo utilizzare le funzioni standard di lettura e scrittura su file: #include <unistd.h> dichiarazioni: ssize_t read(int fd, void *buf, size_t count); ssize_t write(int fd, const void *buf, size_t count); fd : descrittore da cui leggere o su cui scrivere *buf : buffer in cui salvare i dati letti o contenente i dati da scrivere count: numero di byte da leggere/scrivere il numero di byte letti (0 = End Of File) o scritti. -1 in caso di errore. Sia read() che write() richiedono come parametri il file descriptor da cui leggere/scrivere (nel nostro caso la socket), il puntatore ad un buffer in cui scrivere i dati letti o da cui leggere i dati da scrivere e la dimensione massima dei dati da leggere/scrivere. Ricordiamo che non è possibile sapere a priori in che modo TCP ha segmentato i dati da spedire, quindi possono essere necessarie più read() per ricevere tutti i dati trasmessi dall host remoto. Tuttavia anche read() e write() sono delle funzioni di basso livello, scomode da usare e inadeguate nel caso si debbano usare le features di formattazione dell input e dell output tipiche di fscanf() e fprintf().

16 12 CAPITOLO 3. CONNESSIONI TCP/IP Sappiamo infatti che TCP ci offre un livello di astrazione tale da poter considerare la connessione come un semplice flusso (stream) di byte, quindi è lecito pensare di poter usare anche con i socket le funzioni per la gestione di stream. E infatti possibile associare uno stream ad un socket tramite la funzione fdopen(): #include <stdio.h> dichiarazione: FILE *fdopen (int fildes, const char *mode); fildes: descrittore *mode : stringa indicante la modalità di apertura dello stream un puntatore a FILE in caso di successo, NULL in caso di errore. Fdopen ritorna uno stream (ovvero un FILE *) partendo da un file descriptor e una stringa che indica il modo di gestione dello stream ( r per la sola lettura, w per la sola scrittura ecc. ecc. Vedere la relativa man page per i dettagli). Una volta aperto lo stream, è consigliabile disabilitare il buffer ad esso associato, per evitare di introdurre dei ritardi di trasmissione. Per farlo, è sufficiente usare la funzione setbuf(): #include <stdio.h> dichiarazione: void setbuf(file *stream, char *buf); *stream: lo stream di cui si vuole cambiare il buffer *buf : il buffer (NULL = no buffer) nessuno Con setbuf() si può disabilitare completamente il buffering ponendo buf = NULL. In conclusione, dato un socket, è possibile associare ad esso uno stream in questo modo /* s è un socket */ FILE *f; f = fdopen(s, "r"); setbuf(f, NULL); A questo punto è possibile gestire il socket usando lo stream f tramite le classiche funzioni fprintf(), fscanf() e simili. Nel caso sia necessario compiere contemporanemanete operazioni di lettura e scrittura, conviene usare due stream diversi per evitare fastidiosi problemi: FILE *f1, *f2; f1 = fdopen(s, "r"); f2 = fdopen(s, "w"); setbuf(f1, NULL); setbuf(f2, NULL); 3.5 Chiusura della connessione Una connessione TCP può essere chiusa sia dal client che dal server, semplicemente usando la classica close() (o fclose() nel caso sia stato associato uno stream al socket). Quando uno dei due host chiude la connessione, l altro riceve un EOF (end of file). In alternativa si può utilizzare una funzione apposita, ovvero shutdown():

17 3.6. UN CLIENT BASATO SU TCP: L IDEA 13 #include <sys/socket.h> dichiarazione: int shutdown(int s, int how); s : socket da chiudere how: 0 = chiusura in ricezione, 1 = chiusura in spedizione, 2 = chiusura bidirezionale 0 in caso di successo, -1 in caso di errore La caratteristica interessante di shutdown() è quella di permettere la chiusura del socket solo in lettura ( how = 0) o solo in scrittura (how = 1). Nel caso si assegni ad how il valore 2, la chiusura avviene sia in lettura che scrittura, ed il suo effetto è equivalente a quello di close(). 3.6 Un client basato su TCP: l idea Arrivati a questo punto, abbiamo tutte le conoscenze necessarie per scrivere un client che apra una connessione TCP verso un server. Come esempio pratico, scriveremo un programma che si colleghi alla porta daytime (13/tcp) per leggere la data e l ora corrente; l effetto sarà lo stesso dell esecuzione del comando $ telnet nomehost 13 Ovviamente la macchina su cui ci collegheremo dovrà avere il servizio daytime attivo. Sotto linux è sufficiente avere il demone inetd attivo e aggiungere, se non c è già, la seguente linea in /etc/inetd.conf daytime stream tcp nowait root internal Se usate xinetd il file da modificare è /etc/xinetd.conf, e la sintassi è: service daytime { type id socket\_type protocol user wait = INTERNAL = daytime-stream = stream = tcp = root = no Vediamo quali sono i passi principali che il nostro client deve effettuare: 1. creare un socket 2. memorizzare in una struct sockaddr in l indirizzo dell host remoto 3. inizializzare una connessione TCP verso l host specificato al punto 2 e assegnare questa connessione al socket creato al punto 1 4. leggere la data e l ora che il server ci invierà automaticamente 5. chiudere la connessione.

18 14 CAPITOLO 3. CONNESSIONI TCP/IP 3.7 Un client basato su TCP: il codice /* < */ #include <netdb.h> /* gethostbyname() */ #include <sys/types.h> /* socket() connect() */ #include <sys/socket.h> /* socket() connect() */ #include <netinet/in.h> /* struct sockaddr_in */ #include <string.h> /* memset() memcpy() */ #include <stdio.h> #include <errno.h> #define BUF_SIZE 100 extern int h_errno; /* variabile esterna per la gestione degli errori */ int main(int argc, char **argv) { struct hostent *host; /* la macchina a cui vogliamo collegarci */ struct sockaddr_in addr; /* il suo indirizzo nella struttura inaddr_in */ int s; /* il nostro socket... */ FILE *f; /*...e lo stream ad esso associato */ char buf[buf_size]; /* buffer di lettura */ if(argc!= 2){ printf("uso: %s hostname\n", argv[0]); /* cerchiamo l indirizzo dell host passato come parametro */ host = gethostbyname(argv[1]); if(host == NULL){ herror("gethostbyname"); /* memorizziamo in addr l indirizzo dell host e la porta (13) * a cui vogliamo connetterci */ memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(13); memcpy(&addr.sin_addr, host->h_addr, host->h_length); /* creiamo un socket adatto alle connessioni TCP */ s = socket(pf_inet, SOCK_STREAM, 0); if(s == -1){ perror("socket"); /* effettuiamo la connessione */ if(connect(s, (struct sockaddr *) &addr, sizeof(addr)) == -1){ perror("connect");

19 3.8. FUNZIONI PER I SERVER: BIND(), LISTEN() E ACCEPT() 15 /* associamo uno stream al socket */ f = fdopen(s, "r"); setbuf(f, NULL); /* ciclo di lettura: leggi e scrivi finchè non arriva un EOF */ fgets(buf, BUF_SIZE, f); do{ printf(buf); fgets(buf, BUF_SIZE, f); while(! feof(f)); /* chiudiamo lo stream (e di conseguenza il socket) */ fclose(f); exit(0); /* < */ 3.8 Funzioni per i server: bind(), listen() e accept() In una connessione TCP il client ha solitamente un ruolo attivo, poichè si occupa di richiedere l apertura di una connessione usando la funzione connect(). Al contrario il server ha un ruolo passivo, e si limita a rimanere in ascolto su una determinata porta, in attesa di connessioni. Per questo la programmazione di un server richiede l utilizzo di alcune funzioni particolari. La prima di queste è bind(): #include <sys/types.h> #include <sys/socket.h> dichiarazione: int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen); sockfd : socket *my_addr: indirizzo locale di binding addrlen : lunghezza della struttura puntata da my_addr 0 in caso di successo, -1 in caso di errore Bind in inglese significa legare, ed in effetti è proprio questo lo scopo di tale funzione: quello di legare un socket ad una porta, in modo da poter gestire tramite quel socket tutte le connessioni che arrivano a quella porta. sockfd è il socket da legare, my addr punta ad una struct sockaddr in contenente i dati dell host locale su cui il server deve girare e addrlen è la lunghezza in byte della struttura puntata da my addr. Cosa deve contenere la struttura puntata da my addr? Come al solito è necessario assegnare a sin family la costante AF INET e a sin port la porta su cui vogliamo metterci in ascolto. Ma quale indirizzo mettere in sin addr? Probabilmente vorremo che il nostro server possa girare su qualsiasi macchina, quindi sarà sufficiente utilizzare la costante INADDR ANY che rappresenta, appunto, un indirizzo qualsiasi, ed è equivalente a In altre parole per mettere un server in ascolto sulla porta 6969 avremo bisogno di una struct sockaddr in così inizializzata: struct sockaddr_in addr; addr.sin_family = AF_INET;

20 16 CAPITOLO 3. CONNESSIONI TCP/IP addr.sin_port = htons(6969); addr.sin_addr.s_addr = htonl(inaddr_any); Associare il socket ad una porta non è tuttavia sufficiente, bisogna anche mettersi in ascolto su quel socket per accorgersi dell arrivo di nuove connessioni. La funzione da utilizzare è listen(): #include <sys/socket.h> dichiarazione: int listen(int s, int backlog); s : socket backlog: dimensione della coda delle connessioni 0 in caso di successo, -1 in caso di errore s è il socket legato alla porta su cui vogliamo attendere connessioni, mentre backlog indica quante connessioni possono rimanere contemporaneamente in attesa di completamento. Attenzione, questo numero non indica quante connessioni il server può gestire contemporaneamente! Una connessione TCP, prima di raggiungere lo stato finale di ESTABLISHED, deve passare attraverso una fase di inizializzazione (il famoso three-way handshake); backlog indica quante connessioni ancora non completate il server può gestire contemporaneamente. Un valore tipico è 5. L ultima funzione è quella per accettare le connessioni in arrivo, ed ovviamente si chiama accept(): headers: #include <sys/types.h> #include <sys/socket.h> dichiarazione: int accept(int s, struct sockaddr *addr, socklen_t *addrlen); s : socket su cui rimanere in ascolto addr : puntatore alla struct sockaddr_in in cui verrà memorizzato l indirizzo e la porta DA CUI PROVIENE la connessione addrlen: puntatore ad un intero in cui verrà memorizzata la lunghezza dell indirizzo addr. Deve essere inizializzato con la dimensione della struttura puntata da addr un socket accept() gestisce le connessioni in arrivo sul socket s, su cui ci eravamo precedentemente messi in ascolto con listen(). L indirizzo dell host remoto da cui proviene la connessione viene salvato in addr. accept() ritorna un nuovo socket da utilizzare per gestire la connessione appena accettata; in questo modo il primo socket ( s ) può continuare a rimanere in attesa di altre connessioni. In altre parole il socket s serve solo ad accettare le connessioni, che poi saranno gestite tramite gli altri socket creati di volta in volta da accept(). Ricordatevi che accept è una funzione bloccante, ovvero il vostro programma si bloccherà su questa funzione finchè non arriverà una connessione da gestire. 3.9 Un server basato su TCP: l idea Quali sono dunque le operazioni che deve compiere un server? 1. creare un socket

21 3.9. UN SERVER BASATO SU TCP: L IDEA memorizzare in una struct sockaddr in l indirizzo locale 3. legare il socket creato al punto 1. all indirizzo locale specificato al punto 2. con bind() 4. mettersi in attesa di connessioni con listen() 5. accettare le connessioni in arrivo con accept() 6. gestire la connessione 7. chiudere la connessione 8. ritornare al punto 5. per accettare nuove connessioni Tuttavia in questo modo si può gestire solo una connessione alla volta: dopo la accept() (punto 5) il server è impegnato a gestire la connessione appena ricevuta, e può aspettarne altre (ovvero tornare al punto 5) solo dopo aver chiuso la connessione corrente. Questo può andare bene in alcuni casi, in cui il server si limita a mandare una breve sequenza di dati al client chiudendo subito dopo la connessione (vedi ad es. il server daytime per il quale precedentemente abbiamo scritto un client), tuttavia in altri casi è inaccettabile. In particolar modo, un server non può accettare una sola connessione alla volta se deve attendere dei dati spediti dal client: in questi casi infatti sarebbe banale per un utente collegarsi, non spedire nulla e bloccare così il nostro server impedendo la connessione a tutti gli altri utenti. E giunta quindi l ora di sfruttare le potenzialità multitasking del nostro sistema operativo. L idea è semplice: ogni volta che arriva una nuova richiesta di connessione, il server crea una copia di se stesso per gestirla. In questo modo, mentre il processo padre si limita ad accettare le connessioni, queste sono poi gestite dai processi figli che vengono appositamente creati di volta in volta. La funzione per creare questi nuovi processi è fork(), la cui trattazione approfondita va al di là degli scopi di questo documento, per cui rimando il lettore alla relativa man page. L importante, per noi programmatori di server, è sapere che guardando il valore di ritorno di fork() siamo in grado di capire se ci troviamo nel processo padre (in questo caso fork ritorna il PID del processo, necessariamente diverso da 0) o nel processo figlio (il valore ritornato è 0); in questo modo saremo in grado di gestire i due diversi casi. Fork() inoltre torna utile se vogliamo scrivere un vero e proprio daemon, ovvero un server che vada in background da solo al momento dell esecuzione. La cosa è molto semplice da realizzare, e consiste nel fare un fork all inizio del programma. Successivamente si farà terminare subito il processo padre, mentre il processo figlio dovrà limitarsi a chiamare la funzione setsid(). Un ultima cosa: senza entrare nel dettaglio della gestione dei segali, diciamo solo che si renderà necessaria la linea signal(sigchld, SIG\_IGN); per evitare la creazione di processi zombie ad ogni nuova connessione. Questo serve a disabilitare il comportamento di default, in cui un processo padre dovrebbe attendere la terminazione dei processi figli con la funzione wait(). I nuovi passi per scrivere un server sono quindi: 1. se necessario, andare in background (daemon mode) 2. creare un socket 3. memorizzare in una struct sockaddr in l indirizzo di binding 4. legare la socket creata al punto 1. all indirizzo di binding specificato al punto 2. con bind() 5. mettersi in ascolto con listen() 6. accettare le connessioni in arrivo con accept() 7. effettuare una fork() 8. il processo padre ritorna subito al punto il processo figlio invece gestisce e alla fine chiude la connessione. La terminazione della connessione coincide con la terminazione del processo figlio che la gestiva.

22 18 CAPITOLO 3. CONNESSIONI TCP/IP Notate come il processo padre rimane perennemente in attesa di connessioni, in un loop infinito. Il nostro server non prevede un metodo esplicito di terminazione, e sarà necessario killarlo da linea di comando. Detto questo, siamo pronti per scrivere un piccolo server che rimane in attesa di connessioni sulla porta Il server chiederà all utente di immettere il proprio nome e scriverà in risposta il nome immesso e l indirizzo IP da cui proviene la connessione Un server basato su TCP: il codice /* < */ #include <netdb.h> /* gethostbyaddr() */ #include <sys/types.h> /* socket() bind() accept() */ #include <sys/socket.h> /* socket() bind() listen() accept() */ #include <netinet/in.h> /* struct sockaddr_in */ #include <string.h> #include <errno.h> #include <signal.h> #include <stdio.h> extern int h_errno; /* variabile esterna per la gestione degli errori */ void gestisci_connessione(int, struct sockaddr_in *); int main(void) { int s; /* il socket di ascolto */ int s2; /* il socket per la gestione delle connessioni*/ int raddrlen; /* la lunghezza della struttura raddr */ struct sockaddr_in laddr; /* il nostro indirizzo locale */ struct sockaddr_in raddr; /* indirizzo remoto di chi si collega */ /* evitiamo gli zombie */ signal(sigchld, SIG_IGN); /* andiamo in daemon mode */ switch(fork()){ case -1: /* errore */ perror("fork"); case 0: /* processo figlio */ setsid(); break; default: /* processo padre */ exit(0); /* creiamo una socket */ s = socket(pf_inet, SOCK_STREAM, 0); if(s == -1){ perror("socket"); /* mettiamo in laddr il nostro indirizzo di binding */ memset(&laddr, 0, sizeof(laddr)); laddr.sin_family = AF_INET;

23 3.10. UN SERVER BASATO SU TCP: IL CODICE 19 laddr.sin_port = htons(6969); laddr.sin_addr.s_addr = htonl(inaddr_any); /* colleghiamo la socket all indirizzo di binding */ if(bind(s, (struct sockaddr *) &laddr, sizeof(laddr)) == -1){ perror("bind"); /* mettiamoci in ascolto */ if(listen(s, 5) == -1){ perror("listen"); /* creiamo un ciclo infinito in attesa di connessioni */ while(1){ /* accettiamo le connessioni! */ raddrlen = sizeof(raddr); s2 = accept(s, (struct sockaddr *) &raddr, &raddrlen); if(s2 == -1){ perror("accept"); switch(fork()){ case -1: /* errore */ perror("fork"); case 0: /* processo figlio */ gestisci\_connessione(s2, &raddr); exit(0); default: /* processo padre */ close(s2); /* il padre non ne ha bisogno! */ break; /* fine while */ /* */ void gestisci_connessione(int s2, struct sockaddr_in *raddr) { FILE *f1, *f2; char buf[100]; /* associamo due stream al socket */ f1 = fdopen(s2, "r"); f2 = fdopen(s2, "w"); setbuf(f1, NULL); setbuf(f2, NULL); /* dialogo col client */ fprintf(f2, "Ciao! Scrivi il tuo nome:\n"); fgets(buf, 100, f1); buf[strlen(buf) - 2] = \0 ; /* eat newline */

24 20 CAPITOLO 3. CONNESSIONI TCP/IP fprintf(f2, "Ciao %s, ti colleghi da %s\n", buf, inet_ntoa(raddr->sin_addr)); /* chiudiamo gli stream e quindi il socket */ fclose(f1); fclose(f2); /* < */ 3.11 Come usare inetd Inetd è un demone molto particolare che permette di semplificare notevolmente la scrittura di un server. Questo programma si mette in ascolto su determinate porte e, quando riceve una connessione ad una di esse, esegue il server ad essa corrispondente, passandogli la palla e lasciandogli la gestione della trasmissione dei dati vera e propria. In altre parole inetd è un meta-server che raduna in sè tutto il codice necessario per gestire le connessioni TCP, liberando così i singoli server dal gravoso compito di occuparsene loro. I server lanciati da inetd infatti possono astrarre completamente dal livello del TCP/IP, poichè inetd collega i flussi di input e di output rispettivamente ai loro standard input e standard output. Questo significa che un server può gestire la connessione come se leggesse l input da tastiera e scrivesse l output a schermo, il tutto in maniera completamente trasparente. L utilizzo di inetd dà alcuni importanti vantaggi, quali: * maggiore semplicità di programmazione del server * il server viene eseguito solo quando è necessario * si possono usare filtri per accettare/rifiutare le connessioni, come il tcp-wrapper (tcpd). Tuttavia comporta anche alcuni svantaggi: * il server non è più indipendente, per utilizzarlo è necessario appoggiarsi a inetd * l esecuzione del server ad ogni richiesta di connessione può rivelarsi penalizzante in termini di prestazioni (è per questo che, ad esempio, i server web non vengono solitamente lanciati tramite inetd) Qual è la soluzione migliore per il vostro server? Se pensate che la richiesta di avere inetd installato non sia troppo restrittiva e se ritenete che il server non dovrà gestire molte connessioni, allora potete usare inetd e risparmiarvi un po di lavoro; se invece volete un programma autonomo o pensate che dovrà gestire un numero elevato di connessioni, scrivete il vostro server partendo da zero. Spesso la soluzione migliore è quella di implementare entrambe le funzionalità, lasciando poi all utente la possibilità di decidere se utilizzare il programma in modalità stand-alone o tramite inetd. Vediamo ora come è possibile riscrivere il server di prima utilizzando inetd. Innanzitutto aggiungiamo la seguente riga in /etc/inetd.conf 6969 stream tcp nowait nobody /tmp/mioserver mioserver o, nel caso di xinetd: service mioserver { port = 6969 socket_type = stream protocol = tcp wait = no user = nobody server = /tmp/mioserver

25 3.12. UN SERVER CHE UTILIZZA INETD: IL CODICE 21 e facciamo rileggere ad inetd il suo file di configurazione con il comando $ killall -HUP inetd o, nel caso di xinetd $ killall -USR2 xinetd Ora inetd è pronto ad eseguire il programma /tmp/mioserver ogni volta che verrà richiesta una connessione sulla porta Il codice del server risulta molto semplificato, visto che sono state tolte tutte le parti di gestione della connessione TCP e ci si limita ad usare gli stream standard di input e output per comunicare con il client Un server che utilizza inetd: il codice /* < */ #include <string.h> #include <stdio.h> #include <errno.h> #include <netinet/in.h> /* struct sockaddr_in */ int main(void) { char buf[100]; struct sockaddr_in addr; int addrlen; /* disabilitiamo i buffer in input e output */ setbuf(stdin, NULL); setbuf(stdout, NULL); /* prendiamo l indirizzo del client remoto. Poichè non usiamo più * la funzione accept() che salva in una struct sockaddr_in l indirizzo * dell host remoto, dobbiamo ottenere questa informazione con una * chiamata a getpeername(). NB: 0 è il file descriptor dello * standard input. */ addrlen = sizeof(addr); if(getpeername(0, &addr, &addrlen) == -1){ perror("getpeername"); /* dialogo col client */ printf("ciao! Scrivi il tuo nome:\n"); /* potremmo usare gets, ma fgets permette di specificare * un utile vincolo sulla dimensione del buffer */ fgets(buf, 100, stdin); buf[strlen(buf) - 2] = \0 ; /* eat newline */ printf("ciao %s, ti colleghi da %s\n", buf, inet_ntoa(addr.sin_addr)); exit(0); /* < */

26 22 CAPITOLO 3. CONNESSIONI TCP/IP

27 Capitolo 4 UDP/IP 4.1 Funzionamento del protocollo UDP A differenza di TCP, UDP è un protocollo connectionless, ovvero non orientato alle connessioni. Questo significa che un pacchetto UDP, quando viene trasmesso, è lasciato a se stesso : nulla ci garantirà il suo effettivo arrivo a destinazione. In altre parole, con UDP vengono meno tutte quelle caratteristiche garantite da un protocollo orientato alla connessione come TCP. In questo UDP è molto simile al protocollo IP in cui viaggia incapsulato, rispetto al quale aggiunge solo il concetto di porta, come già faceva TCP. Per queste sue caratteristiche, UDP è utilizzato nei casi in cui il traffico sia limitato e non richieda forme sofisticate di controllo; ad esempio le risposte dei DNS viaggiano spesso su UDP. In questo caso infatti la perdita di un pacchetto non è critica in quanto il client può sempre chiedere la ritrasmissione dei dati nel caso non siano arrivati entro un certo tempo limite. E importante notare che ogni trasmissione dei dati con UDP comporta l invio di un singolo datagramma. E infatti compito del programmatore spedire un datagramma alla volta, poichè UDP non fa nessun tipo di segmentazione automatica dei dati come invece accade con TCP. Se si limita la dimensione dei dati spediti a 512 bytes, è garantito che il pacchetto UDP possa essere contenuto in un singolo pacchetto IP, mentre con dimensioni maggiori è possibile incorrere nella frammentazione dei datagrammi operata dal protocollo IP stesso. In ogni caso non è possibile superare la dimensione massima del datagramma IP, che in linea teorica è di bytes, anche se alcuni sistemi operativi non implementano correttamente lo stack IP e impongono restrizioni maggiori. Quando possibile, è conveniente usare UDP, in quanto questo protocollo, vista la sua estrema semplicità, genera meno traffico di TCP. Ovviamente non sempre è possibile convivere con le pesanti restrizioni imposte da questo protocollo. 4.2 Un semplice client UDP Il codice di un client UDP non presenta molte differenze rispetto ad uno basato su TCP. Le funzioni da usare sono le stesse, e bisogna solo avere l accortezza di usare la costante SOCK DGRAM al posto di SOCK STREAM nella chiamata a socket(). Una cosa che può apparire a prima vista illogica è l uso della connect(). Che senso ha usare una funzione che crea connessioni in un protocollo connectionless? Nel caso di UDP, connect() si limita a specificare l indirizzo a cui i dati vanno trasmessi; tale indirizzo sarà anche l unico da cui sarà accettato del traffico in ingresso, di modo che un client possa ricevere delle risposte solamente dal server che ha contattato. Vediamo il codice di un client che legge la data e l ora corrente tramite il servizio daytime (porta 13/udp). Si tratta dello stesso servizio utilizzato precedentemente per il client TCP, e che è disponibile per entrambi i protocolli. /* < */ #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> 23

28 24 CAPITOLO 4. UDP/IP #include <stdio.h> #define BUF_SIZE 100 extern int h_errno; int main(int argc, char **argv) { int s; struct sockaddr_in addr; struct hostent *host; char buf[buf_size]; if(argc!= 2){ printf("uso: %s hostname\n", argv[0]); /* cerchiamo l indirizzo dell host passato come parametro */ host = gethostbyname(argv[1]); if(host == NULL){ herror("gethostbyname"); /* memorizziamo in addr l indirizzo dell host e la porta (13) * a cui vogliamo connetterci */ memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(13); memcpy(&addr.sin_addr, host->h_addr, host->h_length); /* creiamo un socket adatto alle connessioni UDP */ s=socket(pf_inet, SOCK_DGRAM, 0); if(s == -1){ perror("socket"); /* associamo al socket l indirizzo remoto */ if(connect(s, (struct sockaddr *) &addr, sizeof(addr)) == -1){ perror("connect"); /* spediamo qualcosa in modo che il server sappia che * deve risponderci! E lecito spedire un pacchetto vuoto */ send(s, NULL, 0, 0); /* lettura di un unico pacchetto UDP */ recv(s, buf, BUF_SIZE, 0); /* scriviamo a video il risultato */ printf("%s", buf); /* chiudiamo il socket e usciamo */ close(s);

29 4.3. UN SEMPLICE SERVER UDP 25 exit(0); /* < */ Notate come la versione UDP del protocollo daytime richieda che venga inizialmente spedito un pacchetto dal client verso il server, altrimenti il server non avrebbe modo di sapere che c è qualcuno in attesa dei dati, e in ogni caso non saprebbe a quale indirizzo spedirli! La seconda cosa da sottolineare è l utilizzo di send() e recv(). UDP infatti non fornisce l astrazione del flusso di byte da trasmettere tipica di TCP, quindi non avrebbe senso usare in questo caso gli stream. Inoltre, come già detto precedentemente, l invio di dati con UDP comporta sempre la trasmissione di un unico pacchetto, che si può facilmente gestire anche con queste due funzioni di basso livello. 4.3 Un semplice server UDP Passiamo ora alla programmazione di un server basato su UDP; per semplicità ci limiteremo a scrivere un server che rispedisce indietro al mittente tutto quello che riceve. La creazione del socket ed il suo binding all indirizzo locale su cui rimanere in ascolto è analoga al caso del server TCP, eccetto per il fatto che il socket deve essere di tipo SOCK DGRAM. Successivamente tuttavia non sono più necessarie le funzioni listen() e accept() per il semplice fatto che non ci sono connessioni da accettare, poichè UDP è un protocollo connectionless. Per lo stesso motivo, non è necessario usare una fork() per gestire le varie comunicazioni: sarà sufficiente un server iterativo che di volta in volta riceve un pacchetto e risponde al mittente. Ma, una volta ricevuti dei dati, com è possibile sapere qual è l indirizzo del mittente a cui vogliamo rispondere? In altre parole, come possiamo sapere chi è che ci spedisce dei dati? In questo caso bisogna utilizzare delle funzioni di lettura/scrittura adatte allo scopo: #include <sys/types.h> #include <sys/socket.h> dichiarazioni: int recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen); int sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen); s : socket *buf/*msg: buffer dei dati da spedire/ricevere len : numero di byte da spedire/ricevere flags : flag aggiuntivi *from/*to: indirizzo destinatario/mittente *fromlen/tolen: dimensione della struttura puntata da *from/*to valori di ritorno: il numero di byte letti/scritti, -1 in caso di errore. Queste due funzioni sono analoghe a send() e recv(), tranne per gli ultimi due si tratta di una struct sockaddr e della relativa lunghezza, in cui viene memorizzato l indirizzo da cui i dati sono stati ricevuti (nel caso di recvfrom()) o a cui devono essere spediti (nel caso di sendto()). Sebbene queste funzioni siano teoricamente utilizzabili con qualsiasi tipo di socket, per ovvi motivi si rivelano utili soprattutto nell utilizzo di protocolli connectionless. Detto questo, abbiamo tutti i mezzi per scrivere il server: /* < */ #include <sys/types.h> #include <sys/socket.h>