LIBRERIA SOCKET E FUNZIONI DI NETWORKING. **VERSIONE INCOMPLETA** Versione 0.6

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "LIBRERIA SOCKET E FUNZIONI DI NETWORKING. **VERSIONE INCOMPLETA** Versione 0.6"

Transcript

1 LIBRERIA SOCKET E FUNZIONI DI NETWORKING **VERSIONE INCOMPLETA** Versione 0.6 Vito Asta N.B. La presente dispensa accenna solo brevemente agli argomenti trattati e alle funzioni viste nel corso delle esercitazioni; per i dettagli, si veda qualunque testo o tutorial, o ancora le pagine di manuale di qualunque sistema Unix. Un ottimo riferimento bibliografico è il seguente: W. Richard Stevens, Unix Network Programming, vol. 1, second edition Addison-Wesley 1998 La dispensa è corredata da alcuni esempi di base. In sede d esame, lo studente deve dimostrare di aver capito perfettamente l uso delle funzioni qui introdotte e il codice di tutti gli esempi, essendo in grado di riscrivere lo schema essenziale di programmi dello stesso tipo. Nota Tutte le strutture dati, le le funzioni e gli esempi di utilizzazione sono presentati in un contesto TCP/IP "classico"; in particolare, per semplicità di esposizione, non sono tenuti in conto le varianti e gli pseudo-tipi introdotti da Posix.1g o da altre versioni innovative di Unix, nè tutto ciò che concerne IPv6. 1. Argomenti introduttivi Tipi di server: [**ADD**] server iterativo server concorrente server ad I/O multiplexato 2. Generalità L interfaccia fornita dalla libreria socket supporta più famiglie di protocolli di comunicazione, tra cui gli originali sono: Unix domain Internet domain, cioè TCP/IP Xerox NS domain (XNS) -1-

2 Le funzioni di libreria socket sono, a seconda delle implementazioni, vere chiamate sistema oppure funzioni di libreria; comunque ciò ètotalmente trasparente al programmatore. Le funzioni socket e le altre funzioni di rete che vedremo in questa dispensa necessitano normalmente l inclusione di uno o più dei seguenti files: #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> Per semplicità, nel resto della dispensa non viene dettagliato quali sono i files da includere per ciascuna funzione. Nozioni di base sui sockets: un socket è un punto terminale di accesso ad una rete dati e comunicazione attraverso essa un socket viene creato con la chiamata a socket(); gli argomenti specificano il tipo di socket, e il protocollo di comunicazione da usare un socket viene identificato con un socket descriptor, che è un intero in tutto simile ad un file descriptor un socket può avere alcune opzioni d uso, che possono essere impostate o consultate con setsockopt() e getsockopt(); ad esempio SO_DEBUG (che provoca il logging di vari messaggi diagnostici durante l uso del socket), SO_DONTLINGER (che specifica alcuni aspetti della modalità di chiusura del socket), etc. un socket, per poter essere utilizzato, va prima associato ad un indirizzo socket (che corrisponde, in TCP/IP, ad un indirizzo di host e ad un numero di porta); ciò viene fatto con la chiamata a bind() un socket può essere attivo (per fare chiamate uscenti, in un client) o passivo (per aspettare chiamate entranti, in un server); il socket è attivo di default, e viene reso passivo con la chiamata listen() un socket attivo può stabilire una connessione con un altro passivo, con connect() un socket passivo aspetta e poi accetta una chiamata entrante con accept() un socket può inviare o ricevere dati con write(), send() e sendto(), e con read(), recv() e recvfrom() un socket può venire disattivato, in tutto o in parte, con shutdown() un socket viene chiuso con close(). 3. Indirizzi socket La struttura sockaddr contiene un generico indirizzo socket, indipendente dalla famiglia di protocolli struct sockaddr unsigned short sa_family; /* address family char sa_data[14]; /* up to 14 bytes of protocol address ; Come si vede, la struttura dati di un indirizzo è lunga esattamente 16 bytes. I 14 bytes dell indirizzo di protocollo dipendono appunto dalla famiglia di protocolli usata (specificata dal primo campo della struttura); nel caso di Internet domain, cioè il TCP/IP (che è il -2-

3 caso che qui interessa), l indirizzo è definito dalle strutture sockaddr_in (che sostituisce la sockaddr) e in_addr struct sockaddr_in short int sin_family; /* Address family unsigned short int sin_port; /* Port number struct in_addr sin_addr; /* Internet address unsigned char sin_zero[8]; /* Pad to size of struct sockaddr. ; struct in_addr unsigned long s_addr; /* 32-bit netid-hostid, network-ordered ; Il primo campo, sin_family (corrispondente a sa_family in struct sockaddr) va posizionato alla costante manifesta AF_INET Gli indirizzi non sono tutti della stessa lunghezza (in particolare, non lo sono quelli dello Unix domain), quindi le chiamate socket che lavorano con qualunque famiglia di protocolli (ad esempio connect()) in genere richiedono il passaggio di un puntatore alla struttura contenente l indirizzo e della lunghezza in bytes della struttura stessa; ad es: struct sockaddr_in server_address;... connect(sd, &server_address, sizeof(server_address)); Inoltre, l argomento corrispondente all indirizzo è dichiarato come un puntatore a struct sockaddr (cioè al tipo generico); occorre quindi passare l indirizzo facendo il cast a puntatore alla struttura generica di dati; quindi il codice corretto è: struct sockaddr_in server_address;... connect(sd, (struct sockaddr *) &server_address, sizeof(server_address)); 4. Funzioni di servizio 4.1 Ordine dei bytes Una rete TCP/IP rappresenta quantità a 16 bit (come numeri di porta) e a 32 bit (come indirizzi IP) con un ordinamento dei bytes, per indirizzi di memoria crescenti, che va dal più significativo (MSB - Most Significant Byte) al meno significativo (LSB - Less Significant Byte); tale ordinamento è detto big endian, ed è opposto all ordinamento contrario (dallo LSB al MSB), detto little endian. Le macchine rappresentano tali quantità, a seconda della loro architettura hardware, in ordinamento big endian o little endian. Si utilizzano perciò delle funzioni di conversione dal network byte order, cioè quello standard di rete (che è sempre big endian) allo host byte order, della macchina (che è big endian o little endian, a seconda del tipo di CPU), e ciò per quantità a 16 bit (short) e a 32 bit (long): htons, htonl: unsigned short htons(unsigned short hostshort); unsigned long htonl(unsigned long hostlong); -3-

4 prendono un intero a 16 bit (htons) oa32bit (htonl) in host byte order, e lo restituiscono in network byte order. ntohs, ntohl: unsigned short ntohs(unsigned short netshort); unsigned long ntohl(unsigned long netlong); prendono un intero a 16 bit (ntohs) oa32bit (ntohl) in network byte order, e lo restituiscono in host byte order. Tutte le funzioni socket accettano dati in ingresso, e restituiscono dati in uscita, sempre in network byte order, che andrà convertito da/a host byte order. Ovviamente, per macchine che utilizzano la rappresentazione big endian, queste funzioni hanno un effetto nullo, cioè restituiscono il loro argomento inalterato. 4.2 Manipolazione di bytes Le funzioni di questo gruppo permettono di manipolare campi di bytes arbitrari, non terminati da un null byte (come avviene per le stringhe di caratteri); questi campi vengono anche detti stringhe di bytes. bzero: void bzero(void *buf, size_t nbytes); Inizializza a zero la stringa di bytes che parte dall indirizzo buf, di lunghezza nbytes. È utilizzata tipicamente per azzerare una struttura di dati (ad esempio una struct sockaddr_in) prima di riempirne i campi. bcopy: void bcopy(const void *src, void *dest, size_t nbytes); Copia nbytes bytes dall indirizzo src all indirizzo dest. Notare l ordine degli argomenti sorgente e destinazione, che è l inverso di quello della funzione strcpy(). bcmp: int bcmp(const void *buf1, const void *buf2, size_t nbytes); Confronta le due stringhe di bytes buf1 e buf2 lunghe nbytes bytes; ritorna 0 se sono uguali, altrimenti non-zero. Se la lunghezza è nulla, ritorna 0. Variante: memset(), memcpy(), memcmp(). 4.3 Conversione di indirizzi IP Queste funzioni convertono indirizzi IP da stringhe ASCII in dot-notation (p.es. " ") a valori binari, network byte ordered, e viceversa. inet_aton: int inet_aton(const char *strptr, struct in_addr *inaddrptr); Converte la stringa strptr in un indirizzo socket IP, messo nella struttura puntata da inaddrptr. Ritorna 1 se OK, 0 in caso di errore (stringa non valida come indirizzo IP). inet_ntoa: char *inet_ntoa(struct in_addr inaddr); Converte l indirizzo socket IP della struttura inaddr in una stringa di caratteri in dot-notation. Notare -4-

5 che l argomento della funzione è una struttura, non un puntatore a struttura. N.B. la stringa puntata dal valore di ritorno è in una zona statica di memoria, soprascritta ad ogni chiamata; pertanto questa routine non è rientrante. Variante: La funzione inet_addr() è analoga a inet_aton(), ma è da considerarsi obsoleta e da evitare; comunque, essendo ancora molto diffusa, se ne dà qui la dichiarazione: inet_addr: unsigned long int inet_addr(const char *strptr); Converte la stringa strptr in un indirizzo socket IP, restituito come valore di ritorno. In caso di errore ritorna la costante manifesta INADDR_NONE. Variante: inet_pton(), inet_ntop() funzionano sia con IPv4 (la versione attuale di IP) che con IPv6 (quella prossima ventura, con indirizzi a 128 bit). 5. Chiamate socket fondamentali socket: int socket(int family, int type, int protocol); Crea un socket, che è attivo di default; family può essere AF_INET per famiglia di protocolli TCP/IP con IPv4 (che è il caso qui di interesse) AF_INET6 per famiglia di protocolli TCP/IP con IPv6 AF_LOCAL, AF_NS, AF_ROUTE, AF_KEY etc. per altre famiglie, che qui non interessano type può essere SOCK_STREAM per uno stream socket (protocollo TCP) SOCK_DGRAM per un datagram socket (protocollo UDP) SOCK_RAW per un raw socket (livello network: protocolli IP, ICMP) protocol può essere lasciato a 0 (il protocollo usato sarà quello implicito secondo il valore di type), oppure posizionato a uno dei seguenti valori: IPPROT O_TCP per protocollo TCP IPPROT O_UDP per protocollo UDP IPPROT O_RAW per protocollo IP diretto IPPROT O_ICMP per protocollo ICMP Valore di ritorno: un intero non negativo (socket descriptor), o -1 in caso di errore. bind: int bind(int sd, struct sockaddr *addrp, int addrlen); Associa un indirizzo al socket identificato dal socket descriptor sd. addrp è l indirizzo di una struttura di indirizzo di socket, cioè come già detto, nel caso TCP/IP, di una struct sockaddr_in, che conterrà un indirizzo IP di un host e un numero di porta. Il terzo argomento è la dimensione dell oggetto puntato dal secondo, cioè in pratica sizeof(struct sockaddr_in). Valore di ritorno: 0 se o.k., -1 in caso di errore. -5-

6 N.B. un client non ha bisogno di chiamare bind() prima di usare il socket e connettersi ad un server remoto; il sistema assegna automaticamente ad un socket, di default, un indirizzo IP della macchina locale ed un numero di porta arbitrario, scelto tra i valori alti (com è noto, quelli bassi sono riservati ai server). Ciò naturalmente non è accettabile per un server, perchè dev e rispondere ad un numero di porta ben preciso (che dipende dal prototollo applicativo: SMTP, HTTP, DNS, etc.). Ad ogni buon conto, è possibile specificare dei valori di "wildcard" sia per l indirizzo IP che per la porta: per il primo si usa la costante manifesta INADDR_ANY, per la seconda il valore 0. Gli effetti sul comportamento di bind() sono i seguenti: IPaddr == INADDR_ANY, port == 0: il kernel assegna sia l indirizzo che la porta IPaddr == INADDR_ANY, port!= 0: il kernel assegna l indirizzo, il processo sceglie la porta IPaddr == indirizzo locale, port == 0: il processo sceglie l indirizzo, il kernel assegna la porta IPaddr == indirizzo locale, port!= 0: il processo sceglie sia l indirizzo che la porta L uso di INADDR_ANY come indirizzo fa sì che il kernel scelga, come indirizzo IP, quello (tra i vari possibili, supponendo che la macchina abbia più di un interfaccia di comunicazione) che viene usato per comunicare con la controparte (la scelta quindi dipende dai criteri di routing). I server tipicamente usano il wildcard per l indirizzo IP. listen: int listen(int sd, int backlog); Rende un socket passivo, cioè adatto a fungere da punto di chiamata da parte dei client esterni. sd è il socket descriptor; backlog specifica quante connessioni possono rimanere in coda di attesa dal sistema mentre aspetta che il processo server chiami nuovamente la accept(); di solito viene adottato il valore 5, che è spesso il massimo ammesso (anche se alcuni sistemi, come Linux, accettano anche fino a 128) Valore di ritorno: 0 se o.k., -1 in caso di errore. connect: int connect(int sd, struct sockaddr *raddrp, int raddrlen); Stabilisce una connessione tra il socket attivo locale identificato da sd e un socket passivo remoto identificato da un indirizzo nella struttura puntata da raddrp, e la cui lunghezza è specificata in raddrlen. Valore di ritorno: 0 se o.k., -1 in caso di errore. accept: int accept(int sd, struct sockaddr *raddrp, int *raddrlen); Sospende il processo finchè non arriva una chiamata da un client remoto, la accetta, crea un nuovo socket di lavoro per questa sessione col client ora connesso, e ritorna il socket descriptor del nuovo socket. sd è il socket passivo che aspetta la chiamata; raddrp è l indirizzo di una struttura (di tipo sockaddr_in nel caso TCP/IP) ove il sistema restituisce l indirizzo remoto del client che si è connesso; raddrlen viene posizionato, dalla routine chiamante, alla lunghezza massima accettabile (lunghezza della struttura puntata dal secondo argomento), e al ritorno dalla accept() viene -6-

7 modificato dal sistema per restituire la lunghezza effettiva della struttura ritornata. In pratica, per la famiglia AF_INET (cioè TCP/IP), il valore viene posizionato a 16 e rimane tale anche al ritorno dalla funzione. Si noti che l ultimo argomento di connect() è un intero, mentre l ultimo di accept() è l indirizzo di un intero. shutdown: int shutdown(int sd, int how); Disattiva il canale di comunicazione identificato dal socket sd; l argomento how può avere i seguenti valori: 0 - viene disabilitata la lettura dal socket; in TCP, dati ricevuti dalla controparte vengono riscontrati (ACK bit) e rimossi 1 - viene disabilitata la scrittura dal socket; in TCP, viene effettuata una delle due mezzechiusure della sessione (invio di un FIN e ricezione di un ACK) 2 - entrambi i sensi di comunicazione vengono disabilitati. 6. Primi esempi Seguono alcuni esempi di base, che illustrano combinazioni tipiche delle chiamate viste. 6.1 Server TCP concorrente /* a concurrent TCP server #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <signal.h> #define BACKLOG_VALUE 5 extern void log(char *,...); extern void fatal_error(char *,...); extern void serve_client(int); /* argument is my own port, in host byte order void concurrent_server(unsigned short port) int sd; /* passive socket struct sockaddr_in my_addr; /* server IPaddr + port number (void)signal(sigchld, SIG_IGN); /* we don t wait for children if((sd = socket(af_inet, SOCK_STREAM, 0)) == -1) fatal_error("socket error"); /* bind to any local address and to assigned port number bzero((char *)&my_addr, sizeof(my_addr)); my_addr.sin_family = AF_INET; my_addr.sin_addr.s_addr = htonl(inaddr_any); -7-

8 my_addr.sin_port = htons(port); if(bind(sd, (struct sockaddr *)&my_addr, sizeof(my_addr) ) == -1) fatal_error("bind error"); if(listen(sd, BACKLOG_VALUE) == -1) fatal_error("listen error"); /* server s infinite loop for(;;) pid_t pid; int wsd; /* working socket struct sockaddr_in client_addr; /* address of calling client int client_addr_len = sizeof(client_addr); /* blocking step wsd = accept(sd, (struct sockaddr *)&client_addr, &client_addr_len); if(wsd < 0) log("warn: accept error"); continue; log("got connection from client: %s/%d", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); /* here when a client just called us; being a concurrent server, we fork a dedicated child process to serve each client if( (pid = fork()) == (pid_t)0) close(sd); serve_client(wsd); exit(0); /* child process serves the request if(pid < (pid_t)0) log("warn: fork error"); close(wsd); /* parent process immediately goes to wait and accept next incoming call from clients -8-

9 6.2 Server TCP iterativo /* an iterative TCP server #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define BACKLOG_VALUE 5 extern void log(char *,...); extern void fatal_error(char *,...); extern void serve_client(int); /* argument is my own port, in host byte order void iterative_server(unsigned short port) int sd; /* passive socket struct sockaddr_in my_addr; /* server IPaddr + port number if((sd = socket(af_inet, SOCK_STREAM, 0)) == -1) fatal_error("socket error"); /* bind to any local address and to assigned port number bzero((char *)&my_addr, sizeof(my_addr)); my_addr.sin_family = AF_INET; my_addr.sin_addr.s_addr = htonl(inaddr_any); my_addr.sin_port = htons(port); if(bind(sd, (struct sockaddr *)&my_addr, sizeof(my_addr) ) == -1) fatal_error("bind error"); if(listen(sd, BACKLOG_VALUE) == -1) fatal_error("listen error"); /* server s infinite loop for(;;) int wsd; /* working socket struct sockaddr_in client_addr; /* address of calling client int client_addr_len = sizeof(client_addr); /* blocking step wsd = accept(sd, (struct sockaddr *)&client_addr, &client_addr_len); if(wsd < 0) log("warn: accept error"); continue; -9-

10 log("got connection from client: addr/port = %s/%d", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); /* here when a client just called us; being an iterative server, we serve directly each client serve_client(wsd); /* serve the request close(wsd); 6.3 Client TCP /* a TCP client #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> extern void error_exit(char *,...); extern void get_service(int); /* arguments are port and IP address of remote server, in host byte order void tcp_client(unsigned short rport, struct in_addr ripaddress) int sd; /* active socket struct sockaddr_in serv_addr; /* server IPaddr + port number if((sd = socket(af_inet, SOCK_STREAM, 0)) == -1) error_exit("socket error\n"); /* (a TCP client usually does not bind() - there s no need /* fill server address and port number into structure bzero((char *)&serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(ripaddress.s_addr); serv_addr.sin_port = htons(rport); /* connect to server if(connect(sd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) error_exit("connect error\n"); get_service(sd); /* talk with server close(sd); exit(0); -10-

11 6.4 Server UDP /* an UDP server #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> extern void log(char *,...); extern void fatal_error(char *,...); extern void serve_client(int, struct sockaddr_in *, size_t); /* argument is my own port, in host byte order void udp_server(unsigned short port) int sd; struct sockaddr_in my_addr; /* server IPaddr + port number if((sd = socket(af_inet, SOCK_DGRAM, 0)) == -1) fatal_error("socket error"); /* the UDP server binds to a well-known port number bzero((char *)&my_addr, sizeof(my_addr)); my_addr.sin_family = AF_INET; my_addr.sin_addr.s_addr = htonl(inaddr_any); my_addr.sin_port = htons(port); if(bind(sd, (struct sockaddr *)&my_addr, sizeof(my_addr) ) == -1) fatal_error("bind error"); /* server s infinite loop for(;;) struct sockaddr_in client_addr; /* address of calling client bzero((char *)&client_addr, sizeof(client_addr)); /* serve requests from a client; all clients are served always with the same open socket serve_client(sd, &client_addr, sizeof(client_addr)); /* here we may log info about connected client: we have its IP address and port number in client_addr (this has been filled in by the serve_client() routine) log("just served a client: addr/port = %s/%d", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); -11-

12 6.5 Client UDP /* an UDP client #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> extern void error_exit(char *,...); extern void get_service(int, struct sockaddr_in *, size_t); /* arguments are server s remote port and IP address, in host byte order void udp_client(unsigned short rport, struct in_addr ripaddress) int sd; struct sockaddr_in my_addr; /* my own IPaddr + UDP port number struct sockaddr_in serv_addr; /* server IPaddr + UDP port number /* open UDP socket if((sd = socket(af_inet, SOCK_DGRAM, 0)) == -1) error_exit("socket error\n"); /* bind() is not necessary for clients, but in UDP it is better to call it anyway, as a good programming habit (some protocol families, like Unix domain, require it) /* bind to any local address and to a system-assigned port bzero((char *)&my_addr, sizeof(my_addr)); my_addr.sin_family = AF_INET; my_addr.sin_addr.s_addr = htonl(inaddr_any); my_addr.sin_port = hton(0); if(bind(sd, (struct sockaddr *)&my_addr, sizeof(my_addr) ) == -1) error_exit("bind error\n"); /* fill server address and UDP port number bzero((char *)&serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(ripaddress.s_addr); serv_addr.sin_port = htons(rport); /* connect to server and get served get_service(sd, &serv_addr, sizeof(serv_addr)); close(sd); exit(0); -12-

13 7. Struttura di un server multiplexato L esempio seguente illustra la struttura di base di un server multiplexato, che utilizza la chiamata select() per mantenere attive, in un unico processo, le connessioni con un numero arbitrario di processi client; al tempo stesso, il socket passivo è controllato per determinare quando è in arrivo una nuova connessione. #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <unistd.h> /* for select() /* FD_SETSIZE is max. size of an fd_set object; it is not always defined #ifndef FD_SETSIZE #define FD_SETSIZE 1024 #endif #define BACKLOG_VALUE 5 extern void log(char *,...); extern void fatal_error(char *,...); extern int serve_client(int); /* returns 0 if OK, -1 if EOF found /* argument is my own port, in host byte order void multiplexed_server(unsigned short port) int i; int maxi, maxfd, listensd, clientsd, sockfd; int client[fd_setsize]; fd_set rset, allset; struct sockaddr_in my_addr; if(listensd = socket(af_inet, SOCK_STREAM, 0) == -1) fatal_error("socket error"); /* bind to any local address and to assigned port number bzero((char *)&my_addr, sizeof(my_addr)); my_addr.sin_family = AF_INET; my_addr.sin_addr.s_addr = htonl(inaddr_any); my_addr.sin_port = htons(port); if(bind(listensd, (struct sockaddr *)&my_addr, sizeof(my_addr) ) == -1) fatal_error("bind error"); if(listen(listensd, BACKLOG_VALUE) == -1) fatal_error("listen error"); maxi = -1; /* index into client[] array for (i = 0; i < FD_SETSIZE; ++i) client[i] = -1; /* -1 indicates available entry FD_ZERO(&allset); -13-

14 /* initially, this is the only channel to select FD_SET(listensd, &allset); maxfd = listensd; /* initialize for (;;) int nready; size_t client_addr_len; struct sockaddr_in client_addr; rset = allset; /* structure assignment nready = select(maxfd+1, &rset, NULL, NULL, NULL); if(nready == -1) log("warn: select error"); continue; /* FIRST: check if data available from listening socket; if yes, we go and issue an accept() to get the new connection if (FD_ISSET(listensd, &rset)) /* a new client connection is arrived client_addr_len = sizeof(client_addr); clientsd = accept(listensd, (struct sockaddr *) &client_addr, &client_addr_len); if(clientsd < 0) log("warn: accept error"); goto secondpart; log("got connection from client: %s/%d", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); /* look for first empty slot in client[], and save this new socket descriptor for (i = 0; i < FD_SETSIZE; ++i) if (client[i] < 0) client[i] = clientsd; break; if (i == FD_SETSIZE) fatal_error("too many clients"); /* add new descriptor to set FD_SET(clientsd, &allset); /* update max. descriptor, for select() if (clientsd > maxfd) -14-

15 maxfd = clientsd; /* update max. index in client[] array if (i > maxi) maxi = i; /* now, one less selected channel; if there are no more such channels, don t go to second step if (--nready <= 0) continue; /* no more readable descriptors secondpart: /* SECOND: check all the active client socket connections for data available; if yes, go and serve the client for (i = 0; i <= maxi; ++i) /* skip empty slots in client[] if ( (sockfd = client[i]) < 0) continue; if (FD_ISSET(sockfd, &rset)) if(serve_client(sockfd) == -1) /* connection closed by client close(sockfd); FD_CLR(sockfd, &allset); client[i] = -1; if (--nready <= 0) break; /* no more readable descriptors 8. Comunicazione di dati Per la lettura e scrittura di dati attraverso una rete mediante un socket si possono utilizzare le seguenti funzioni: Connessione TCP: read(), write(); recv(), send() Connessione UDP: recvfrom(), sendto() 8.1 Funzioni recv: int recv(int sd, void *buf, size_t len, int flags); -15-

16 Riceve dati dal socket sd su una connessione TCP. I primi tre argomenti sono identici a quelli di read(); l argomento flags specifica delle opzioni, ed è costruito con uno o più flags messi in OR tra loro, tra cui: MSG_WAITALL - ritorna solo quando tutti i len bytes di dati richiesti sono disponibili (N.B. non è supportato da tutte le versioni di Unix) MSG_PEEK - legge i dati senza toglierli dai buffer di input; la prossima lettura ritornerà quindi gli stessi bytes MSG_OOB - leggi dati Out-Of-Band, anzichè i dati normali. I dati OOB sono in pratica messaggi urgenti, che vengono trasmessi all entità corrispondente scavalcando i dati in coda di trasmissione. Si noti che la presenza di dati OOB può essere rivelata usando la chiamata select(): infatti in questo caso il socket descriptor viene posto nello fd_set delle eccezioni; ad es.: fd_set read_set, except_set; FD_SET(sd, &read_set); FD_SET(sd, &except_set); nready = select(maxdes, &read_set, NULL, &except_set, NULL); if(fd_isset(sd, &read_set)) /* normal data available nb = recv(sd, buf, message_len, MSG_WAITALL); if(fd_isset(sd, &except_set)) /* OOB data available nb = recv(sd, buf, message_len, MSG_WAITALL MSG_OOB); send: int send(int sd, const void *buf, size_t len, int flags); Invia dati al socket sd su una connessione TCP. I primi tre argomenti sono identici a quelli di write(); l argomento flags specifica delle opzioni, ed è costruito con uno o più flags messi in OR tra loro, tra cui: MSG_OOB - scrivi dati Out-Of-Band, anzichè dati normali. recvfrom: int recvfrom(int sd, void *buf, size_t len, int flags, struct sockaddr *from, int *fromlen); Riceve dati dal socket sd su una connessione UDP. I primi quattro argomenti sono identici a quelli di recv() (sono identici anche i valori legali di flags); gli ultimi due argomenti specificano un indirizzo socket (tramite un puntatore alla struttura generica sockaddr) che al ritorno dalla funzione viene riempito con l indirizzo IP e la porta dell entità corrispondente che ha inviato i dati. Questi due argomenti sono sostanzialmente analoghi agli ultimi due argomenti di accept() sendto: int sendto(int sd, const void *buf, size_t len, int flags, const struct sockaddr *to, int tolen); -16-

17 Invia dati al socket sd su una connessione UDP. I primi quattro argomenti sono identici a quelli di send() (sono identici anche i valori legali di flags); gli ultimi due argomenti specificano un indirizzo socket (tramite un puntatore alla struttura generica sockaddr) che specificano l indirizzo IP e la porta dell entità corrispondente a cui si inviano i dati. Questi due argomenti sono sostanzialmente analoghi agli ultimi due argomenti di connect; si noti, come già evidenziato a proposito di connect() e di accept(), che l ultimo argomento di sendto() è un intero, mentre l ultimo di recvfrom() è l indirizzo di un intero. 8.2 Uso di read() e write() I sockets TCP generano un comportamento, per le primitive read() e write(), diverso da quello delle normali operazioni di I/O. Il numero di bytes effettivamente trasferiti può essere inferiore a quello specificato, senza che ciò sia una condizione di errore; ciò èdovuto al raggiungimento del limite del buffer di sistema, e per passare al buffer successivo ciò che si deve fare è semplicemente rilanciare un altra read() o write() per i bytes rimanenti. Le seguenti tre funzioni organizzano le letture e scritture nel modo detto; ritornano solo quando tutti i bytes specificati sono stati trasferiti, oppure in caso di errore. Questo codice mostra anche un esempio di trattamento delle chiamate sistema interrotte da un segnale Readn() /* library routine. read "n" bytes from a descriptor. return value: number of bytes read (equal to the number asked for with the third argument, or possibly a lesser amount if EOF was found); 0 on EOF; -1 on error int readn(int fd, void *vptr, size_t n) size_t nleft; int nread; char *ptr; ptr = vptr; nleft = n; while (nleft > 0) if ( (nread = read(fd, ptr, nleft)) < 0) /* interrupted system call if (errno == EINTR) nread = 0; /* and call read() again else return -1; else if (nread == 0) break; /* EOF nleft -= nread; ptr += nread; return(n - nleft); /* return >= 0-17-

18 8.2.2 Writen() /* library routine. write "n" bytes to a descriptor. return value: number of bytes written (always equal to the number asked for with the 3.rd argument); -1 on error int writen(int fd, const void *vptr, size_t n) size_t nleft; int nwritten; const char *ptr; ptr = vptr; nleft = n; while (nleft > 0) if ( (nwritten = write(fd, ptr, nleft)) <= 0) /* interrupted system call if (errno == EINTR) nwritten = 0; /* and call write() again else return -1; /* error nleft -= nwritten; ptr += nwritten; return n; -18-

19 8.2.3 Readline() /* library function -- reads a line from a socket-descriptor, and returns it as a character string, just like fgets(). data are read up to and including the terminating \n, or until the specified number of bytes has been reached. return value: number of bytes read; 0 on EOF; -1 on error int readline(int fd, void *vptr, size_t maxlen) int n, rc; char c, *ptr; ptr = vptr; for (n = 1; n < maxlen; ++n) if ( (rc = my_read(fd, &c)) == 1) *ptr++ = c; if (c == \n ) break; /* newline is stored, like fgets() else if (rc == 0) if (n == 1) return 0; /* EOF, no data read else break; /* EOF, some data was read else return -1; /* error, errno set by read() *ptr = \0 ; /* null terminate like fgets() return n; /* read one character; actually, do a read-ahead and bufferize input static int my_read(int fd, char *ptr) static int read_cnt = 0; static char *read_ptr; static char read_buf[maxline]; again: if (read_cnt <= 0) if ( (read_cnt = read(fd, read_buf, sizeof(read_buf))) < 0) if (errno == EINTR) goto again; return -1; -19-

20 else if (read_cnt == 0) return 0; read_ptr = read_buf; --read_cnt; *ptr = *read_ptr++; return 1; 9. Opzioni dei sockets A ciascun socket sono associate varie opzioni che ne determinano alcune particolarità di funzionamento. Le funzioni applicabili, per leggere il valore delle opzioni e per posizionarne il valore, sono le seguenti: Funzioni applicabili solo ai sockets: getsockopt(), setsockopt() Funzioni generiche, applicabili a qualunque tipo di file descriptor o socket descriptor: fcntl(), ioctl(). In questa dispensa vengono presentate solo le prime due. Esiste un gran numero di opzioni possibili; qui se ne descrivono solo alcune. 9.1 Funzioni setsockopt: int setsockopt(int sd, int level, int optname, const void *optval, int optlen); Posiziona il valore di un opzione del socket sd. Le opzioni possono essere manipolate a diversi livelli, specificati in level (livello generico o di protocollo specifico); il caso normale è il liv ello generico, corrispondente alla costante manifesta SOL_SOCKET, oppure a livello TCP, corrispondente a IPPROT O_TCP. L argomento optname specifica l opzione, mentre optval punta al valore da impostare, che a seconda delle opzioni può essere un intero o una struttura di dati; alcune opzioni sono di tipo booleano (sì/no; il valore è un intero diverso oppure uguale a 0). L ultimo argomento, optlen, specifica la lunghezza del valore puntato da optval. Valore di ritorno: 0 se OK, -1 in caso di errore. getsockopt: int getsockopt(int sd, int level, int optname, void *optval, int *optlen); Legge e ritorna il valore di un opzione del socket sd. Gli argomenti level, optname, optval e optlen hanno gli stessi significati del caso precedente, salvo ovviamente che gli ultimi due sono riempiti dalla funzione al suo ritorno (e infatti anche qui, come nel caso di connect() e accept(), l ultimo argomento è un intero per la funzione setsockopt(), un puntatore a intero per la funzione getsockopt()). Valore di ritorno: 0 se OK, -1 in caso di errore. 9.2 Principali tipi di opzioni Le opzioni più usate sono riportate nella tabella che segue; consultare i manuali appropriati per maggiori dettagli. -20-

21 level optname get set descrizione flag? tipo dati SOL_SOCKET SO_BROADCAST x x permetti invio messaggi broadcast x int SOL_SOCKET SO_DEBUG x x abilita debug tracing x int SOL_SOCKET SO_TYPE x ottieni info sul tipo di socket int SOL_SOCKET SO_LINGER x x modalità di chiusura socket struct linger SOL_SOCKET SO_REUSEADDR x x IP address riutilizzabile x int SOL_SOCKET SO_KEEPALIVE x x testa periodicamente la connessione x int SOL_SOCKET SO_RCVBUF x x dimensione buffer ricezione int SOL_SOCKET SO_SNDBUF x x dimensione buffer invio int IPPROT O_TCP TCP_MAXSEG x x max. dimensione segmento TCP x int Le opzioni SO_RCVBUF ed SO_SNDBUF permettono di specificare le dimensioni di due buffer, di invio e di ricezione, che sono associati al socket; ogni socket TCP ha entrambi i buffer, mentre ogni socket UDP ha solo il buffer di ricezione. L opzione SO_REUSEADDR è utile tra l altro in questi casi: Quando si ha a che fare con servers che per qualunque motivo possono essere fermati e fatti ripartire (ad esempio dopo una modifica alle tavole di configurazione del server); in questo caso non si vuole aspettare che tutti i processi figli abbiano chiuso il socket, prima di ripartire Per avere più servers diversi (o più istanze dello stesso server) che rispondono a differenti indirizzi IP locali della macchina. Questa è una tecnica tipica di molti server HTTP, con kernel del Sistema Operativo che permette l associazione di più indirizzi IP ad una stessa scheda di rete (IP alias technique): il server HTTP parte, su differenti indirizzi IP, con differenti configurazioni di DocumentRoot (radice dei documenti WEB), e quindi una stessa macchina fisica appare come diversi server WEB, rispondenti a diversi indirizzi IP. È buona norma, per un server, posizionare sempre questa opzione sul socket passivo, cos ì come l opzione KEEPALIVE sui sockets di connessione con i clients. L opzione SO_TYPE è utilizzata tipicamente da processi che ereditano sockets aperti dal processo padre, e devono decidere cosa farne; il valore di ritorno è una delle costanti di tipo SOCK_STREAM, SOCK_DGRAM, e simili. L opzione SO_LINGER specifica le modalità di chiusura del socket; di default, la chiamata ad una close() del socket ritorna immediatamente, ma se ci sono ancora dati nel buffer del socket, il sistema tenterà di inviarli alla controparte. Questo scenario può essere cambiato, in vari modi, posizionando opportunamente i campi della struct linger associata a questa opzione. 10. Funzioni di conversione di nomi 10.1 Conversione di nomi di hosts Le conversioni tra nomi di hosts e indirizzi IP possono farsi, per piccoli sistemi locali e isolati da Internet, tramite un file di corrispondenza, /etc/hosts; oppure, per sistemi normalmente connessi alla rete, tramite un server DNS. Il file /etc/resolv.conf indica quale meccanismo è in uso in un dato sistema. Le funzioni di questo gruppo utilizzano una struttura hostent cos ì definita: -21-

22 struct hostent char *h_name; /* official name of host (FQDN) char **h_aliases; /* alias list int h_addrtype; /* host address type: AF_INET, AF_INET6 int h_length; /* length of address (4 for AF_INET) char **h_addr_list; /* list of addresses from name server ; #define h_addr h_addr_list[0] /* first address in list FQDN è l acronimo di "Fully Qualified Domain Name", cioè il nome per esteso dell host, comprensivo del dominio di appartenenza; ad esempio, per una macchina del dominio axnet.it denominata axdbserv, il nome normale è appunto axdbserv, mentre il FQDN è axdbserv.axnet.it Gli elementi dell array puntato da h_addr_list puntano ad indirizzi IP lunghi h_length bytes ciascuno, cioè in pratica per TCP/IP 4 bytes, considerabili come struct in_addr gethostbyname: struct hostent *gethostbyname(const char *hostname); Dato un nome di host, normale o Fully-qualified, ritorna la relativa struttura hostent. Il campo di interesse, al ritorno della funzione, è normalmente h_addr gethostbyaddr: struct hostent *gethostbyaddr(const char *addr, size_t len, int family); Dato un indirizzo IP, ritorna la relativa struttura hostent. L argomento addr punta in realtà ad una struct in_addr; len è la lunghezza di questa struttura; family va posizionato ad AF_INET. Il campo di interesse, al ritorno della funzione, è normalmente h_name gethostname: int gethostname(char *name, size_t namelen); Ritorna in name il nome della macchina di lavoro (quella in cui si esegue la funzione). La lunghezza dell array name è data in namelen, che dovrebbe essere pari alla massima lunghezza possibile, specificata nel parametro MAXHOSTNAMELEN definito in sys/param.h Valore di ritorno: 0 se è OK, -1 in caso di errore. Variante: uname() 10.2 Conversione di nomi di servizi Le conversioni tra nomi di servizi e numeri di porta TCP o UDP si effettuano tramite un file di corrispondenza, /etc/services Le funzioni di conversione di servizi utilizzano una struttura servent cos ì definita: struct servent char *s_name; /* official service name char **s_aliases; /* alias list int s_port; /* port number, network byte order char *s_proto; /* protocol to use ; -22-

23 getservbyname: struct servent *getservbyname(const char *name, const char *proto); Dato un nome di servizio, in name, e un nome di protocollo da usare, in proto (normalmente "tcp" o "udp"), restituisce la relativa struttura servent. Il campo di interesse è normalmente s_port (che è già in network byte order, quindi può essere utilizzato direttamente per le funzioni socket) getservbyport: struct servent *getservbyport(int port, const char *proto); Dato un numero di porta, in port (da dare in network byte order), e un nome di protocollo da usare, in proto (normalmente "tcp" o "udp"), restituisce la relativa struttura servent. Il campo di interesse è normalmente s_name 10.3 Altre funzioni di conversione Esistono altre funzioni, raramente usate, per la conversione di nomi di reti e di nomi di protocolli. 11. Esempi 11.1 Hostcnv /* hostcnv -- convert AF_INET host names into IP addresses, and vice-versa /* usage: hostcnv -a host_name hostcnv -n host_address -a print on stdout IP Address corresponding to host_name -n print on stdout host Name corresponding to host_address #include <stdio.h> #include <netdb.h> #include <netinet/in.h> int addresstoname(char *); int nametoaddress(char *); void usage(void); main(int ac, char **av) extern char* optarg; extern int optind, optopt, opterr; int option; int ret; opterr = 0; /* disable error messages from getopt() if(ac!= 3) usage(); exit(1); while ((option = getopt(ac, av, "a:n:"))!= -1) -23-

24 switch (option) case a : /* hostcnv -a host_name ret = nametoaddress(optarg); break; case n : /* hostcnv -n host_address ret = addresstoname(optarg); break; case? : fprintf(stderr, "bad flag: -%c", optopt); usage(); exit(1); break; exit(ret? 1:0); int addresstoname(char *address) struct hostent *host; struct in_addr addr; addr.s_addr = inet_addr(address); host = gethostbyaddr((char *)&addr, sizeof(struct in_addr), AF_INET); if(host == NULL) fprintf(stderr, "no such host!\n"); else printf("%s\n", host->h_name); return(host? 0:-1); int nametoaddress(char *name) struct hostent *host; struct in_addr addr; host = gethostbyname(name); if(host == (struct hostent *)NULL) fprintf(stderr, "no such host!\n"); else bcopy(host->h_addr, (char *)&addr, host->h_length); printf("%s\n", inet_ntoa(addr)); return(host? 0:-1); -24-

25 void usage() fprintf(stderr, "usage: hostcnv -a host_name\n\ hostcnv -n host_address\n\ -a print on stdout IP Address corresponding to host_name\n\ -n print on stdout host Name corresponding to host_address\n"); -25-

26 11.2 Main per tcp_client /* a main program for the tcp_client routine, seen before #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> extern void tcp_client(unsigned short, struct in_addr); int main(int argc, char **argv) struct hostent struct servent unsigned short struct in_addr *hp; *sp; rport; ripaddress; if (argc!= 3) error_exit("usage: TCPclient <hostname> <service>"); if ( (hp = gethostbyname(argv[1])) == (struct hostent *)NULL) err_exit("hostname error for %s: %s", argv[1], hstrerror(h_errno)); /* N.B. - gethostbyname() does not use errno for errors! if ( (sp = getservbyname(argv[2], "tcp")) == (struct servent *)NULL) error_exit("getservbyname error for %s", argv[2]); rport = sp->s_port; ripaddress = *((struct in_addr *)(hp->h_addr_list[0])); /* as our routine expects arguments in host byte order, we hav e to provide the conversions here ripaddress.s_addr = ntohl(ripaddress.s_addr); tcp_client(ntohs(rport), ripaddress); exit(0); 12. Avvio di un server stand-alone Un server stand-alone, o daemon, èun programma che parte normalmente al bootstrap della macchina e rimane attivo, aspettando chiamate da serve remoti su una porta prefissata, fino allo shutdown del sistema. L alternativa al server stand-alone è un server lanciato, al momento dell arrivo di una chiamata, dal superserver inetd (v. oltre). Un server stand-alone, all avvio, deve effettuare almeno i seguenti passi base: fork il programma rigenera se stesso, e il processo padre esce immediatamente; così il server va in background ed è asincrono rispetto agli altri programmi. -26-

27 setpgrp o setsid il processo diventa session leader di una nuova sessione o gruppo di processi, e non ha nessun terminale di controllo associato. Ignore SIGHUP; fork il padre esce anche questa volta; il figlio non è un process group leader, cos ì se apre un dispositivo tty questo non diventa il suo terminale di controllo (questo meccanismo è appunto attivo solo per il process group leader); quando il padre (process group leader) esce, viene inviato SIGHUP a tutti i processi del gruppo, quindi tale segnale deve essere ignorato chdir; umask il daemon cambia la directory di lavoro, di solito a / o in qualche altra directory opportuna; ciò è importante per non essere dipendente dalla directory da cui il server è stato lanciato (ad esempio se viene lanciato da un file system montato, questo non può più essere smontato finchè il server è attivo). Viene inoltre settato il valore di umask a 0 o a qualche altro valore, in modo da non dipendere, nell eventuale creazione di files, dall umask ereditato. close fds vengono chiusi tutti i f.d.; talvolta viene aperto /dev/null e duplicato sui f.d. 0, 1 e 2. openlog viene chiamata questa routine per preparare l uso di syslog(), che è la routine standard utilizzata da un daemon per loggare messaggi vari. Altri servers naturalmente, tra cui tipicamente i servers HTTP, utilizzano propri files di log, con formati propri e diversi da quello di syslog() SIGHUP, SIGINT questi due segnali, che il kernel non invia mai ad un processo senza terminale di controllo, vengono spesso intercettati e usati come segnalazione esterna per rileggere files di configurazione del server, cos ì da evitare di doverlo fermare e far ripartire nel caso di cambiamenti di configurazione. -27-

28 12.1 Esempio /* basic steps required to start a standalone daemon #include <sys/types.h> #include <signal.h> #include <syslog.h> #define MAXFD 64 void daemon_init(const char *pname, int facility) int fd; pid_t pid; if ( (pid = fork())!= 0) exit(0); /* parent terminates /* 1st child continues setsid(); /* become session leader signal(sighup, SIG_IGN); if ( (pid = fork())!= 0) exit(0); /* 1st child terminates /* 2nd child continues chdir("/"); /* change working directory umask(0); /* clear our file mode creation mask /* unfortunately, understanding the max. value for a f.d. is not easy; some systems do not put limits. however, 64 is certainly enough for (fd = 0; fd < MAXFD; ++fd) (void)close(fd); /* prepare for use of syslog() openlog(pname, LOG_PID, facility); -28-

LIBRERIA SOCKET EFUNZIONI DI NETWORKING. Versione 1.0

LIBRERIA SOCKET EFUNZIONI DI NETWORKING. Versione 1.0 LIBRERIA SOCKET EFUNZIONI DI NETWORKING Versione 1.0 Vito Asta, febbraio 2000 N.B. La presente dispensa accenna solo brevemente agli argomenti trattati e alle funzioni viste nel corso delle esercitazioni;

Dettagli

LABORATORIO di Reti di Calcolatori

LABORATORIO di Reti di Calcolatori LABORATORIO di Reti di Calcolatori Socket in linguaggio C: nozioni preliminari 1 of 16 v slide della docente Bibliografia v testo di supporto: D. Maggiorini, Introduzione alla programmazione client-server,

Dettagli

Programmazione di Rete

Programmazione di Rete Programmazione di Rete Ing. Carlo Nobile Socket slide n 1 Sommario Berkeley's socket Socket UDP: funzioni fondamentali Esempio applicazione: Listener Sender Socket non bloccanti Indirizzo IP e Porta Sicurezza

Dettagli

Scrittura dei programmi applicativi di rete

Scrittura dei programmi applicativi di rete Scrittura dei programmi applicativi di rete Contenuti del corso La progettazione delle reti Il routing nelle reti IP Il collegamento agli Internet Service Provider e problematiche di sicurezza Analisi

Dettagli

Reti (già Reti di Calcolatori )

Reti (già Reti di Calcolatori ) Reti (già Reti di Calcolatori ) Cenni di Socket Programming Renato Lo Cigno http://disi.unitn.it/locigno/index.php/teaching-duties/computer-networks Socket API Programmazione dei socket Obiettivo:imparare

Dettagli

RETI DI CALCOLATORI. Prof. PIER LUCA MONTESSORO Ing. DAVIDE PIERATTONI. Facoltà di Ingegneria Università degli Studi di Udine

RETI DI CALCOLATORI. Prof. PIER LUCA MONTESSORO Ing. DAVIDE PIERATTONI. Facoltà di Ingegneria Università degli Studi di Udine RETI DI CALCOLATORI Prof. PIER LUCA MONTESSORO Ing. DAVIDE PIERATTONI Facoltà di Ingegneria Università degli Studi di Udine 2003 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright Questo

Dettagli

Scrittura dei programmi applicativi di rete

Scrittura dei programmi applicativi di rete Nota di Copyright RETI DI CALCOLATORI Prof. PIER LUCA MONTESSORO Ing. DAVIDE PIERATTONI Facoltà di Ingegneria Università degli Studi di Udine Questo insieme di trasparenze (detto nel seguito slide) è protetto

Dettagli

Sistemi di Elaborazione. Introduzione alla Programmazione distribuita

Sistemi di Elaborazione. Introduzione alla Programmazione distribuita Sistemi di Elaborazione Introduzione alla Programmazione distribuita Obiettivi Introdurre i concetti di base su programmazione distribuita Modello Client-Server Interfaccia Socket Progettare e realizzare

Dettagli

Programmazione socket. Queste slide sono distribuite con licenza Creative Commons Attribuzione-Non commerciale-condividi allo stesso modo 2.

Programmazione socket. Queste slide sono distribuite con licenza Creative Commons Attribuzione-Non commerciale-condividi allo stesso modo 2. Programmazione socket Queste slide sono distribuite con licenza Creative Commons Attribuzione-Non commerciale-condividi allo stesso modo 2.5 Italia Applicazioni di rete Realizzare un'applicazione di rete

Dettagli

L interfaccia socket

L interfaccia socket L interfaccia socket Application Programming Interface: API Socket API Procedure base Altre procedure Ordinamento dei byte Interazione client-server orientata alla connessione Interazione client-server

Dettagli

funzione fork() La funzione fork è usata per duplicare un processo. #include <unistd.h> pid_t fork (void);

funzione fork() La funzione fork è usata per duplicare un processo. #include <unistd.h> pid_t fork (void); La funzione fork è usata per duplicare un processo. #include pid_t fork (void); funzione fork() restituisce -1 in caso di errore. Se tutto va a buon fine restituisce 0 nel processo figlio ed

Dettagli

I Socket di Berkeley

I Socket di Berkeley I Socket di Berkeley di Francesco Licandro Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università degli studi di Catania A.A. 2004-2005 1 Programmazione su rete Le applicazioni di

Dettagli

Socket. Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server.

Socket. Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Socket Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Tale architettura consente ai sistemi di condividere risorse e cooperare per il raggiungimento

Dettagli

Internetworking with TCP/IP (Douglas E. Comer) Vol. I and Vol III.

Internetworking with TCP/IP (Douglas E. Comer) Vol. I and Vol III. Internetworking with TCP/IP (Douglas E. Comer) Vol. I and Vol III http://gapil.truelite.it/ http://www.linuxdidattica.org/docs/a ltre_scuole/planck/socket/ Client Server Esistono vari modelli di architettura

Dettagli

Esempio 1: stampa locale di file remoto

Esempio 1: stampa locale di file remoto Alcuni esempi di uso di Socket Esempio 1: stampa locale di file remoto Visualizzazione locale del contenuto di un file remoto. Il client deve richiedere la creazione della connessione e successivamente

Dettagli

Laboratorio di. Reti Informatiche. Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017. Ing. Niccolò Iardella

Laboratorio di. Reti Informatiche. Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017. Ing. Niccolò Iardella Laboratorio di Reti Informatiche Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017 Ing. Niccolò Iardella niccolo.iardella@unifi.it 1 Esercitazione 5 Programmazione con i socket Parte 2

Dettagli

Socket. Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server.

Socket. Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Socket Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Tale architettura consente ai sistemi di condividere risorse e cooperare per il raggiungimento

Dettagli

Socket Programming. Socket Programming. Università di Palermo

Socket Programming. Socket Programming. Università di Palermo Socket Programming Socket Programming 1 Architettura Processo (Messagi) HTTP, SMTP, DNS, IMAP,... Trasporto (Messagi) TCP UDP Rete (Pacchetti) ARP IP ICMP Data link (Frames) Ethernet, FDDI, 802.11,...

Dettagli

Laboratorio reti AA 2006/2007. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2006/2007. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2006/2007 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2006/2007 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

LABORATORIO di Reti di Calcolatori

LABORATORIO di Reti di Calcolatori LABORATORIO di Reti di Calcolatori Socket in linguaggio C: protocollo connectionless 1 of 14 v slide della docente Bibliografia v testo di supporto: D. Maggiorini, Introduzione alla programmazione client-server,

Dettagli

Interazione (TCP) Client-Server con le socket

Interazione (TCP) Client-Server con le socket Interazione (TCP) Client-Server con le socket Interazione TCP Client/Server Server 1. Creare una socket 2. Assegnare un local address alla socket 3. Settare la socket all ascolto 4. Iterativamente: a.

Dettagli

LABORATORIO di Reti di Calcolatori

LABORATORIO di Reti di Calcolatori LABORATORIO di Reti di Calcolatori Socket in linguaggio C: protocollo connection-oriented 1 of 15 v slide della docente Bibliografia v testo di supporto: D. Maggiorini, Introduzione alla programmazione

Dettagli

Esercitazione [7] Client/Server con Socket

Esercitazione [7] Client/Server con Socket Esercitazione [7] Client/Server con Socket Leonardo Aniello - aniello@dis.uniroma1.it Daniele Cono D'Elia - delia@dis.uniroma1.it Federico Lombardi - lombardi@dis.uniroma1.it Sistemi di Calcolo - Secondo

Dettagli

Interazione (TCP) Client-Server con le socket

Interazione (TCP) Client-Server con le socket Interazione (TCP) Client-Server con le socket D. Gendarmi Interazione TCP Client/Server Server 2. Assegnare un local address alla socket 3. Settare la socket all ascolto 4. Iterativamente: a. Accettare

Dettagli

Socket TCP. prima parte

Socket TCP. prima parte Socket TCP prima parte Cosa cambia: socket int fd = socket(pf_inet, SOCK_STREAM, 0); if (fd

Dettagli

Sviluppo di Applicazioni su Rete. Introduzione all API socket di Berkeley. Interazione tra Processi. Modello Client-Server

Sviluppo di Applicazioni su Rete. Introduzione all API socket di Berkeley. Interazione tra Processi. Modello Client-Server a.a. 2003/04 Introduzione all API socket di Berkeley Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica

Dettagli

L uso di Socket UDP. Usiamo le API Winsock incluse in <Winsock.h> A.A. 2005/06. Dott.ssa Valeria Carofiglio

L uso di Socket UDP. Usiamo le API Winsock incluse in <Winsock.h> A.A. 2005/06. Dott.ssa Valeria Carofiglio L uso di Socket UDP Usiamo le API Winsock incluse in A.A. 2005/06 TCP TCP vs. UDP UDP Interazione UDP Client/Server Server 1. (Inizializzare una WSA) 2. Creare una socket 3. Assegnare un local

Dettagli

Laboratorio di. Reti Informatiche. Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017. Ing. Niccolò Iardella

Laboratorio di. Reti Informatiche. Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017. Ing. Niccolò Iardella Laboratorio di Reti Informatiche Corso di Laurea Triennale in Ingegneria Informatica A.A. 2016/2017 Ing. Niccolò Iardella niccolo.iardella@unifi.it 1 Esercitazione 4 Programmazione con i socket Parte 1

Dettagli

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2008/2009 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2008/2009 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

*HVWLRQHDYDQ]DWDGHOOH6RFNHWLQ& ODSULPLWLYDVHOHFW

*HVWLRQHDYDQ]DWDGHOOH6RFNHWLQ& ODSULPLWLYDVHOHFW *HVWLRQHDYDQ]DWDGHOOH6RFNHWLQ& ODSULPLWLYDVHOHFW 7&3H8'3&OLHQW6HUYHUXVDQGRVHOHFW Si progetti un applicazione distribuita Client/Server per una rete di workstation UNIX (BSD oppure System V). In particolare,

Dettagli

Laboratorio di Sistemi Operativi 29-01-2009. Cognome Nome Mat.

Laboratorio di Sistemi Operativi 29-01-2009. Cognome Nome Mat. Il compito è costituito da domande chiuse, domande aperte ed esercizi. Non è consentito l uso di libri, manuali, appunti., etc. Tempo massimo 2 ore. Domande chiuse: ogni domanda corrisponde ad un punteggio

Dettagli

Domain Name Service. Mapping nomi/indirizzi con Socket API in C

Domain Name Service. Mapping nomi/indirizzi con Socket API in C Domain Name Service Mapping nomi/indirizzi con Socket API in C 1 Risoluzione di nomi simbolici TCP/IP ha bisogno di rappresentazioni numeriche per gli indirizzi (es. 193.204.187.189) e per le porte (es.

Dettagli

Laboratorio reti AA 2007/2008. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2007/2008. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2007/2008 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2007/2008 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

Progettazione di un client TCP. Progettazione di un server TCP. Esempio: daytime TCP. Client TCP daytime

Progettazione di un client TCP. Progettazione di un server TCP. Esempio: daytime TCP. Client TCP daytime Progettazione di un client TCP Progettazione di un server TCP Passi per la progettazione di un client TCP 1. Creazione di un endpoint Richiesta al sistema operativo 2. Creazione della connessione Implementazione

Dettagli

Programmazione di applicazioni di rete

Programmazione di applicazioni di rete Programmazione di applicazioni di rete Valeria Cardellini Università di Roma Tor Vergata Applicazioni di rete Applicazioni di rete - forniscono i servizi di alto livello utilizzati dagli utenti - determinano

Dettagli

P3-05: Socket Options

P3-05: Socket Options Autunno 2002 Prof. Roberto De Prisco -05: Socket Options Università degli studi di Salerno Laurea e Diploma in Informatica Socket options 05.2 Ogni socket aperto ha delle proprietà che ne determinano alcuni

Dettagli

Socket TCP. seconda parte

Socket TCP. seconda parte Socket TCP seconda parte Schema della connessione Computer 1 127.43.18.1 indirizzo I1 indirizzo I2 Computer 2 143.225.5.3 porta 45000 socket porta 5200 socket processo client processo server socket(...)

Dettagli

COMUNICAZIONE TRA PROCESSI REMOTI IN UNIX

COMUNICAZIONE TRA PROCESSI REMOTI IN UNIX A cura del prof. Gino Tombolini 1 COMUNICAZIONE TRA PROCESSI REMOTI IN UNIX Il sistema UNIX TCP/IP fornisce un meccanismo di comunicazione tra processi residenti su nodi distinti di una rete, compatibili

Dettagli

Sistemi di Elaborazione. Introduzione alla Programmazione distribuita

Sistemi di Elaborazione. Introduzione alla Programmazione distribuita Sistemi di Elaborazione Introduzione alla Programmazione distribuita Obiettivi Introdurre i concetti di base su programmazione distribuita Modello Client-Server Interfaccia Socket Progettare e realizzare

Dettagli

Esercitazione [08] Server multi-process/multi-thread

Esercitazione [08] Server multi-process/multi-thread Esercitazione [08] Server multi-process/multi-thread Leonardo Aniello aniello@dis.uniroma1.it Daniele Cono D'Elia delia@dis.uniroma1.it Giuseppe Laurenza laurenza@dis.uniroma1.it Federico Lombardi lombardi@dis.uniroma1.it

Dettagli

Guida all' uso dei sockets nella programmazione in C

Guida all' uso dei sockets nella programmazione in C Guida all' uso dei sockets nella programmazione in C ( pseudo-traduzione personalizzata di "Beej's Guide to Network Programming" ) (Prima parte) INTRODUZIONE Finalmente ho trovato una guida chiara e semplice

Dettagli

Introduzione ai socket

Introduzione ai socket Introduzione ai socket Socket locali Contiene lucidi tratti da: 2006-2007 Marco Faella, Clemente Galdi, Giovanni Schmid (Università di Napoli Federico II), 2004-2005 Walter Crescenzi(Universita di Roma

Dettagli

Esercitazione [7] Server multi-process/multi-thread

Esercitazione [7] Server multi-process/multi-thread Esercitazione [7] Server multi-process/multi-thread Leonardo Aniello - aniello@dis.uniroma1.it Daniele Cono D'Elia - delia@dis.uniroma1.it Sistemi di Calcolo - Secondo modulo (SC2) Programmazione dei Sistemi

Dettagli

INTERNET DOMAIN SOCKETS (Cap.59)

INTERNET DOMAIN SOCKETS (Cap.59) INTERNET DOMAIN SOCKETS (Cap.59) Internet Domain Stream Socket TCP Internet Domain Datagram Socket UDP A differenza degli UDDS I datagrams possono essere persi duplicati o arrivare in un ordine diverso

Dettagli

request reply richiesta client processo di servizio processo server principale From - Valeria Cardellini, Corso Sist. Distr. A.A.

request reply richiesta client processo di servizio processo server principale From - Valeria Cardellini, Corso Sist. Distr. A.A. Applicazioni di rete Forniscono i servizi di alto livello utilizzati dagli utenti Determinano la percezione di qualità del servizio (QoS) che gli utenti hanno della rete sottostante Programmazione di applicazioni

Dettagli

TECN.PROG.SIST.INF. UDP socket in Windows. Roberta Gerboni

TECN.PROG.SIST.INF. UDP socket in Windows. Roberta Gerboni Roberta Gerboni Schema logico della comunicazione UDP in linguaggio C mediante Datagram socket. bind () Con i datagram socket (SOCK_DGRAM) viene realizzata una comunicazine che permette di scambiare dati

Dettagli

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2008/2009 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2008/2009 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

Esempio 1: stampa locale di file remoto

Esempio 1: stampa locale di file remoto Alcuni esempi di uso di Socket Esempio 1: stampa locale di file remoto Visualizzazione locale del contenuto di un file remoto. Il client deve richiedere la creazione della connessione e successivamente

Dettagli

I Socket. Laboratorio Software 2008-2009 M. Grotto R. Farina

I Socket. Laboratorio Software 2008-2009 M. Grotto R. Farina M. Grotto R. Farina Sommario 1. Applicazioni Distribuite 2. I Socket Introduzione Interfacce e protocolli Descrizione Stile di comunicazione Namespace e protocollo Include e system call Creazione e chiusura

Dettagli

Socket per TCP: Fondamenti

Socket per TCP: Fondamenti Socket per TCP: Fondamenti Network Applications Molte applicazioni di rete sono formate da due programmi distinti (che lavorano su due diversi host) uno detto server ed uno detto client. Il server si mette

Dettagli

Socket per TCP: Fondamenti

Socket per TCP: Fondamenti Socket per TCP: Fondamenti Network Applications Molte applicazioni di rete sono formate da due programmi distinti (che lavorano su due diversi host) uno detto server ed uno detto client. Il server si mette

Dettagli

Esercitazione Laboratorio di Sistemi Operativi 20-01-2014. Cognome Nome Mat.

Esercitazione Laboratorio di Sistemi Operativi 20-01-2014. Cognome Nome Mat. Il compito è costituito da domande chiuse e domande aperte. Non è consentito l uso di libri, manuali, appunti., etc. Tempo massimo 2 ore. Domande chiuse: ogni domanda corrisponde ad un punteggio di 1 punto

Dettagli

Il sistema operativo LINUX Inter Process Communication. Sommario. popen ( ) PIPE. pipe ( ) popen ( ) Sistemi operativi Modulo II

Il sistema operativo LINUX Inter Process Communication. Sommario. popen ( ) PIPE. pipe ( ) popen ( ) Sistemi operativi Modulo II Il sistema operativo LINUX Inter Process Communication Sommario Giorgio Di Natale Stefano Di Carlo Politecnico di Torino Dip. Automatica e Informatica dup FIFO

Dettagli

L uso di Socket UDP. TCP vs. UDP UDP

L uso di Socket UDP. TCP vs. UDP UDP L uso di Socket UDP TCP TCP vs. UDP UDP 1 Interazione UDP Client/Server Server 1. Creare un socket 2. Assegnare un local address al socket 3. Iterativamente: a. Inviare e ricevere dati 4. Chiudere il socket

Dettagli

IPC: InterProcess Communication

IPC: InterProcess Communication IPC: InterProcess Communication Uso di segnali Uso di file processo invia limitata quantità info (solo un tipo di segnale) e manca il mittente del segnale solo tra processi che condividono un file system

Dettagli

I/O su Socket TCP: read()

I/O su Socket TCP: read() I/O su Socket TCP: read() I socket TCP, una volta che la connessione TCP sia stata instaurata, sono accedibili come se fossero dei file, mediante un descrittore di file (un intero) ottenuto tramite una

Dettagli

Reti di Calcolatori - Laboratorio. Lezione 5. Gennaro Oliva

Reti di Calcolatori - Laboratorio. Lezione 5. Gennaro Oliva Reti di Calcolatori - Laboratorio Lezione 5 Gennaro Oliva Server basato su I/O Multiplex Per realizzare un server è possibile utilizzare l'i/o Multiplex Un unico processo iterativo gestisce il socket che

Dettagli

Funzioni bloccanti e soluzioni

Funzioni bloccanti e soluzioni Funzioni bloccanti e soluzioni La funzione accept() e le funzioni per la gestione dell I/O (ad es., read() e write()) sono bloccanti Ad es., le funzioni read() e recv() rimangono in attesa finché non vi

Dettagli

(VHUFLWD]LRQLGLEDVHVXOOH6RFNHWLQ&

(VHUFLWD]LRQLGLEDVHVXOOH6RFNHWLQ& (VHUFLWD]LRQLGLEDVHVXOOH6RFNHWLQ& 3ULPRHVHUFL]LR6RFNHWVWUHDPFRQULGLUH]LRQH Si progetti un applicazione distribuita Client/Server per una rete di workstation UNIX (BSD oppure System V). In particolare,

Dettagli

Le socket di Berkeley

Le socket di Berkeley Corso di Reti di Calcolatori I Simon Pietro Romano (spromano@unina.it) Antonio Pescapè (pescape@unina.it) Giorgio Ventre (giorgio@unina.it) Roberto Canonico (roberto.canonico@unina.it) Le socket di Berkeley

Dettagli

IPC: InterProcess Communication

IPC: InterProcess Communication IPC: InterProcess Communication Uso di segnali Uso di file processo invia limitata quantità info (solo un tipo di segnale) e manca il mittente del segnale solo tra processi che condividono un file system

Dettagli

Corso di Laurea in Ingegneria Informatica. Corso di Reti di Calcolatori a.a. 2009/10

Corso di Laurea in Ingegneria Informatica. Corso di Reti di Calcolatori a.a. 2009/10 Corso di Laurea in Ingegneria Informatica Corso di Reti di Calcolatori a.a. 2009/10 Roberto Canonico (roberto.canonico@unina.it) Antonio Pescapè (pescape@unina.it) Le socket di Berkeley Le socket di Berkeley

Dettagli

Timeout. Socket Avanzati. Funzione alarm() Client echo UDP con alarm

Timeout. Socket Avanzati. Funzione alarm() Client echo UDP con alarm I semestre 02/03 Socket Avanzati Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Timeout Abbiamo visto

Dettagli

Esercitazione [6] Client/Server con Socket

Esercitazione [6] Client/Server con Socket Esercitazione [6] Client/Server con Socket Leonardo Aniello - aniello@dis.uniroma1.it Daniele Cono D'Elia - delia@dis.uniroma1.it Sistemi di Calcolo - Secondo modulo (SC2) Programmazione dei Sistemi di

Dettagli

Reti Informatiche. Quarta esercitazione

Reti Informatiche. Quarta esercitazione Reti Informatiche Quarta esercitazione Introduzione Richiami di Programmazione C Differenze principali C/C++ 2 Definizioni di variabili Le variabili possono essere definite solo all inizio di un blocco

Dettagli

I.I.S. G.B. PENTASUGLIA MATERA ISTITUTO TECNICO SETTORE TECNOLOGICO LICEO SCIENTIFICO SCIENZE APPLICATE. Classe: 5Ci

I.I.S. G.B. PENTASUGLIA MATERA ISTITUTO TECNICO SETTORE TECNOLOGICO LICEO SCIENTIFICO SCIENZE APPLICATE. Classe: 5Ci I.I.S. G.B. PENTASUGLIA MATERA ISTITUTO TECNICO SETTORE TECNOLOGICO LICEO SCIENTIFICO SCIENZE APPLICATE Disciplina: Tecnologie e Progettazione di Sistemi Informatici e di Telecomunicazione Cognome e Nome:

Dettagli

Lo strato di applicazione in Internet

Lo strato di applicazione in Internet Lo strato di applicazione in Internet Prof. Ing. Carla Raffaelli a.a. 2004/2005 Protocolli applicativi Sono i protocolli utilizzati dalle applicazioni per scambiarsi informazioni Esempi: HTTP per il web,

Dettagli

Laboratorio di Reti di Calcolatori

Laboratorio di Reti di Calcolatori Laboratorio di Reti di Calcolatori Funzioni utili, server ricorsivi, echo client ed echo server. Paolo D Arco Abstract Scopo della lezione è presentare alcune funzioni di utilità generale (e.g., funzioni

Dettagli

funzione close() La funzione close è utilizzata normalmente per chiudere un descrittore di file, è utilizzata per chiudere un socket e terminare una

funzione close() La funzione close è utilizzata normalmente per chiudere un descrittore di file, è utilizzata per chiudere un socket e terminare una funzione close() La funzione close è utilizzata normalmente per chiudere un descrittore di file, è utilizzata per chiudere un socket e terminare una connessione TCP. int close (int socketfd); restituisce

Dettagli

Laboratorio Reti di Calcolatori (A.A ) Delfina Malandrino.

Laboratorio Reti di Calcolatori (A.A ) Delfina Malandrino. Laboratorio Reti di Calcolatori (A.A. 2008-2009) I/O Multiplexing Delfina Malandrino delmal@dia.unisa.it it http://www.dia.unisa.it/professori/delmal/ Problema 2 Un applicazione deve gestire più input

Dettagli

Interazione con il DNS Conversioni di Nomi ed Indirizzi

Interazione con il DNS Conversioni di Nomi ed Indirizzi a.a. 2003/04 Interazione con il DNS Conversioni di Nomi ed Indirizzi Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in

Dettagli

SERVER CLIENT. Struttura di un Applicazione UDP. Socket UDP. Parametri di sendto. Funzioni di Input/Output. Prof. Vincenzo Auletta

SERVER CLIENT. Struttura di un Applicazione UDP. Socket UDP. Parametri di sendto. Funzioni di Input/Output. Prof. Vincenzo Auletta I semestre 03/04 Struttura di un Applicazione UDP Socket UDP socket() bind() Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ CLIENT socket() sendto() Dati (richiesta)

Dettagli

IPC Inter Process Communication

IPC Inter Process Communication Il protocollo TCP controlla che la trasmissione tra due end points avvenga correttamente. Non stabilisce alcun criterio su chi deve iniziare la comunicazione. Questo compito è svolto dalle applicazioni

Dettagli

Funzioni bloccanti e soluzioni. Funzioni bloccanti e soluzioni (2) Parametri della funzione select() Funzione select()

Funzioni bloccanti e soluzioni. Funzioni bloccanti e soluzioni (2) Parametri della funzione select() Funzione select() Funzioni bloccanti e soluzioni La funzione accept() e le funzioni per la gestione dell I/O (ad es., read() e write()) sono bloccanti Ad es., le funzioni read() e recv() rimangono in attesa finché non vi

Dettagli

Opzioni del Socket. Socket Options. Opzioni di Livello Socket. Livello delle Opzioni

Opzioni del Socket. Socket Options. Opzioni di Livello Socket. Livello delle Opzioni a.a. 2003/04 Opzioni del Socket Socket Options Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1 Ogni socket

Dettagli

Programmazione di applicazioni di rete con socket - parte 1

Programmazione di applicazioni di rete con socket - parte 1 Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Programmazione di applicazioni di rete con socket - parte 1 Corso di Sistemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Applicazioni

Dettagli

Corso di Sistemi Operativi Esercitazioni

Corso di Sistemi Operativi Esercitazioni Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica Corso di Sistemi Operativi Esercitazioni Lezione IX Esempio di progetto Server HTTP 0.9 Server HTTP 0.9 Specifiche Si chiede di

Dettagli

Laboratorio reti AA 2007/2008. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2007/2008. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2007/2008 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2007/2008 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

Una semplice applicazione client/server 1

Una semplice applicazione client/server 1 Una semplice applicazione client/server 1 Il nostro obiettivo In questa parte del corso implementeremo un applicazione client/server che usa i socket Internet disponibili nei sistemi Unix/Linux. Nello

Dettagli

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2008/2009. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2008/2009 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2008/2009 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

Laboratorio reti AA 2006/2007. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione

Laboratorio reti AA 2006/2007. Dott. Matteo Roffilli Ricevimento in ufficio dopo la lezione Laboratorio reti AA 2006/2007 Dott. Matteo Roffilli roffilli@csr.unibo.it Ricevimento in ufficio dopo la lezione 1 Laboratorio reti AA 2006/2007 Per esercitarvi fate SSH su: alfa.csr.unibo.it si-tux00.csr.unibo.it.

Dettagli

Creare una applicazione Winsock di base

Creare una applicazione Winsock di base Creare una applicazione Winsock di base Usiamo le API Winsock incluse in Creare un progetto per una Socket Windows (in Dev C++) Selezionare la file New Projects Selezionare Empty Project Salvare

Dettagli

Comunicazioni fra processi remoti: i socket nello UNIX di Berkeley

Comunicazioni fra processi remoti: i socket nello UNIX di Berkeley Comunicazioni fra processi remoti: i socket nello UNIX di Berkeley La base per l I/O di rete in UNIX BSD (unix di Berkeley) è un astrazione chiamata socket (letteralmente "presa"). Si può considerare il

Dettagli

SISTEMI OPERATIVI. Processi in Linux. Giorgio Giacinto Sistemi Operativi

SISTEMI OPERATIVI. Processi in Linux. Giorgio Giacinto Sistemi Operativi SISTEMI OPERATIVI Processi in Linux 2 Creazione di processi concorrenti» La creazione di un processo figlio consente di far eseguire alcune funzionalità del programma in modo concorrente» Opzione 1 il

Dettagli

SCUOLA DI INGEGNERIA DELL INFORMAZIONE. Corso di Piattaforme Software per la rete MODULO 2 Anno Accademico Prof. William FORNACIARI

SCUOLA DI INGEGNERIA DELL INFORMAZIONE. Corso di Piattaforme Software per la rete MODULO 2 Anno Accademico Prof. William FORNACIARI SCUOLA DI INGEGNERIA DELL INFORMAZIONE Corso di Piattaforme Software per la rete MODULO 2 Anno Accademico 2016-2017 Prof. William FORNACIARI SOLUZIONE D1 D2 D3 TOT Laureando SI NO NOTE PER LO SVOLGIMENTO

Dettagli

Acknowledgment: Prof Vincenzo Auletta, Università di Salerno. Approfondimento alla programmazione distribuita

Acknowledgment: Prof Vincenzo Auletta, Università di Salerno. Approfondimento alla programmazione distribuita Reti Informatiche Approfondimento alla programmazione distribuita Acknowledgment: Prof Vincenzo Auletta, Università di Salerno Introduzione API send e receive bloccanti e non API select Socket UDP Esempio

Dettagli

programmazione distribuita Introduzione Introduzione alla programmazione distribuita

programmazione distribuita Introduzione Introduzione alla programmazione distribuita Reti Informatiche Introduzione alla programmazione distribuita Introduzione Richiami di Programmazione C Differenze principali C/C++ 2 1 Definizioni di variabili Le variabili possono essere definite solo

Dettagli

Corso di Reti di Calcolatori T

Corso di Reti di Calcolatori T Università degli Studi di Bologna Scuola di Ingegneria Corso di Reti di Calcolatori T Esercitazione 5 (svolta) Server Multiservizio: Socket C con select Luca Foschini Anno accademico 2017/2018 Esercitazione

Dettagli

Sistemi Operativi (M. Cesati)

Sistemi Operativi (M. Cesati) Sistemi Operativi (M. Cesati) Compito scritto del 17 febbraio 2014 Nome: Matricola: Corso di laurea: Cognome: Crediti da conseguire: 5 6 9 Scrivere i dati richiesti in stampatello. Al termine consegnare

Dettagli

TECN.PROG.SIST.INF. I Socket Roberta Gerboni

TECN.PROG.SIST.INF. I Socket Roberta Gerboni 2015 - Roberta Gerboni Socket e porte I sistemi operativi multitasking possono fare girare contemporaneamente più processi dove ogni processo può rendere disponibili anche più servizi. Questi devono essere

Dettagli

API Socket di Berkeley

API Socket di Berkeley Laboratorio Reti di Calcolatori (A.A. 2008-2009) Programmazione di rete ed interfaccia API socket di Berkeley Delfina Malandrino delmal@dia.unisa.it http://www.dia.unisa.it/professori/delmal/ API Socket

Dettagli

Laboratorio di Programmazione in Rete

Laboratorio di Programmazione in Rete Laboratorio di Programmazione in Rete a.a. 2005/2006 http://www.di.uniba.it/~lisi/courses/prog-rete/prog-rete0506.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì ore 10-12

Dettagli

Applicazione distribuita

Applicazione distribuita La programmazione di applicazioni distribuite in C Il concetto di applicazione distribuita L architettura di una applicazione distribuita Il paradigma a scambio di messaggi Il paradigma client-server Il

Dettagli

Socket per TCP: Fondamenti

Socket per TCP: Fondamenti Socket per TCP: Fondamenti Network Applications Molte applicazioni di rete sono formate da due programmi distinti (che lavorano su due diversi host) uno detto server ed uno detto client. Il server si mette

Dettagli

Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it

Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it Socket Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Tale

Dettagli

5 Esercitazione (svolta):

5 Esercitazione (svolta): 5 Esercitazione (svolta): Socket C con select Sviluppare un applicazione C/S in cui uno stesso server fornisce due servizi, richiesti da due tipi di client: il conteggio del numero di file contenuti in

Dettagli

Computazione su Rete Socket Internet Applications (Client-Server Concept, Use of Protocol Ports, Socket API, DNS, , TELNET, FTP)

Computazione su Rete Socket Internet Applications (Client-Server Concept, Use of Protocol Ports, Socket API, DNS,  , TELNET, FTP) Internet Applications (Client-Server Concept, Use of Protocol Ports, Socket API, DNS, E-mail, TELNET, FTP) Funzionalità Livello di trasporto e livelli sottostanti Comunicazione base Disponibilità Livello

Dettagli