Inter-Process Communication (Réseau, Sockets)

Cours de Systèmes d exploitation IFIPS-3 Inter-Process Communication (Réseau, Sockets) T. Hérault herault@lri.fr Université Paris XI Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.1/48

Rappels de Réseau Couches OSI 7 Application 6 Présentation 5 Session 4 Transport 3 Réseau 2 Liens 1 Physique Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.2/48

TFTP over UDP client TFTP Protocole TFTP Serveur TFTP UDP Protocole UDP UDP IP Protocole IP IP Ethernet Protocole Ethernet Ethernet Sur chaque ligne (sauf la ligne la plus basse), chaque protocole communique virtuellement, en sachant peu ou pas de choses sur le protocole du dessous Le flux passe de l un à l autre, en descente ou en remontée Les protocoles de niveau applicatif attendent une qualité de service des protocoles de transport, qui attendent une qualité de service des transports de routage, etc... Ethernet pourrait être remplacé par token ring, etc... Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.3/48

Ordre Réseaux Problème : transfert de données binaires entre machines Soit x un entier codé sur 16 bits dont la valeur est 0xAABB (en hexa) il est constitué de deux octets : l un vaut 0xAA, l autre 0xBB. soit &x l adresse de x. Quelle est l adresse de l octet de poids fort de x (l octet qui vaut 0xAA) Quelle est l adresse de l octet de poids faible de x (l octet qui vaut 0xBB) Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.4/48

Endian Ca dépends de la représentation interne de la machine On distingue 2 types : Big et Little Endian Big Endian (Sparc, IBM 370,...) : *((char *)&x) == 0xAA Little Endian (x86, VAX,...) : *((char *)&x) == 0xBB Et pour les entiers de 32 Bits? C est pire : certains systèmes de représentation échangent en plus les couples de bytes Et pour les flottants? Il y a presque autant de représentation que de constructeurs machines Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.5/48

Et alors? Le champs port du paquet UDP est un entier sur 16 bits. quand j envoie un paquet UDP depuis mon PC x86 vers mon serveur TFTP, je le contact sur le port TFTP : 69 = 0x0045. si mon serveur TFTP est un Sparc, il reçoit 0x4500 = 17664... Il faut donc se mettre d accord sur une norme lorsqu on communique sur le réseaux pour faire passer les valeurs qui ont un sens groupées C est ce qu on appelle l XDR : external Data Representation RFC 1014. Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.6/48

Faut-il coder la RFC à la main? Pour les entiers jusqu à 32 bits : non. En C : 5 formes d entiers : char, short, long, int, long long ntohl = Network TO Host Long htonl = Host TO Network Long ntohs = Network TO Host Short htons = Host TO Network Short et pour les char? Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.7/48

Encapsulation Que se passe t il quand j envoie un block de 400 octets par TFTP? 400 Octets de données dans TFTP + 4 d en tête TFTP = 404 Octets de données pour UDP + 8 d en tête UDP = 412 Octets de données pour IP + 4 d en tête IP = 416 Octets de données pour Ethernet + 14 Octets d en tête et 4 Octets de queue pour Ethernet = 434 Octets de Trame Ethernet Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.8/48

Gestion de l encapsulation en C Autant que faire se peut, via des structures : struct tftp_hdr { unsigned short opcode; unsigned short block_number; unsigned char data[0]; }; et du mappage : unsigned char message[404]; struct tftp_hdr *tftp_message; unsigned char *message_data; tftp_message = (struct tftp_hdr *)message; message_data = message + sizeof(struct tftp_hdr); Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.9/48

Gestion de l encapsulation en C le C n invente rien : si la structure contient un short, puis un char, puis un long, il y a 2 octets, puis 1, puis 4. Les champs sont quand même byte aligned struct strange { unsigned char b:2, z:6; }; ne pas oublier l endianess : tftp_message -> opcode = htons(data); tftp_message -> block_number = htons(1); memcpy(tftp_message -> data, blocks[1], 400); Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.10/48

Gestion de l encapsulation en C struct iphdr { #if BYTE_ORDER == LITTLE_ENDIAN unsigned int ihl:4; unsigned int version:4; #elif BYTE_ORDER == BIG_ENDIAN unsigned int version:4; unsigned int ihl:4; #endif u_int8_t tos; u_int16_t tot_len; u_int16_t id; u_int16_t frag_off; u_int8_t ttl; u_int8_t protocol; u_int16_t check; u_int32_t saddr; u_int32_t daddr; /*The options start here. */ }; Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.11/48

Berkeley Sockets Premières implémentations de TCP/IP : BSD Unix, 1981 API Socket normalisée par Berkeley dans 4.1cBSD Unix Cette API est maintenant implantée partout (Un*x, Windows, Mac...) c est donc le standard de fait. Au coeur de cette API : la notion de socket, un objet du noyau qui relie un service réseau à un programme utilisateur, à la manière des descripteurs de fichiers Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.12/48

Comparaison avec les fichiers Fichiers : 6 appels systèmes principaux open, creat, close, read, write et lseek. Utilisent un descripteur de fichier (équivalent du Handle) Dans un monde idéal : les sockets fonctioneraient pareil (Credo UN*X: tout est un fichier) Ce n est pas complétement possible. Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.13/48

Comparaison avec les fichiers Relations client/serveur : asymétriques Communication réseau : peut être orientée connection ou pas. Open n a pas toujours de sens. Les noms sont plus important en réseau qu en fichiers : on doit pouvoir savoir à qui on s adresse à tout moment Une association réseau = (def) {protocol, local addr, local process, foreign addr, foreign process} : plus de paramètres qu un fichier Pour certaines communications, les frontières doivent être respectées (2 émissions = 2 réceptions de même tailles) Une même interface réseau peut supporter différents protocoles de communication : techniques génériques d adressage, un peu équivalent à avoir différentes techniques d accès pour les fichiers. Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.14/48

IP : rappels Adresse IP (v4) : 32 bits, notés xxx.xxx.xxx.xxx (0 xxx 255) Adressage hierarchique pour le routage. Adresse hôte / Adresse de réseau / Masque de réseau 192.168.1.2 / 192.168.1.0 / 255.255.255.0 Adresse de broadcast : 192.168.1.255 Passerelle par défaut routes Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.15/48

Adressage Berkeley : principe Adressage hierarchique Objet conçu à une époque où les langages à objets n étaient pas très populaires interface avec le système : C! Donc plein de void* et de cast Adresse de base : la struct sockaddr dans <sys/socket.h> struct sockaddr { u_short sa_family; /* address family : AF_xxx value * char sa_data[14]; /* up to 14 bytes of protocol-*/ /* specific address*/ }; bug de l an-200, ou des 640Kb qui seront toujours suffisant Le contenu de sa_data dépends du protocole. Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.16/48

Adressage Berkeley : Internet Pour IPv4, la structure spécifique d adresse est définie dans <netinet/in.h> : struct in_addr { u_long s_addr; /* 32-bit netid/hostid */ /* network byte orders */ }; struct sockaddr_in { short sin_family;/* AF_INET */ u_short sin_port; /* 16-bit port number (networ struct in_addr sin_addr; /* 32-bit netid/hostid (netwo char sin_zero[8]; /* unused */ }; int inet_aton(const char *cp, struct in_addr *inp); Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.17/48

Adressage Berkeley : Unix Sockets unix, dans <sys/un.h> : struct sockaddr_un { short sun_family; /* AF_UNIX */ char sun_path[108]; /* pathname */ }; dépassement de capacité de certaines fonctions (table de routage suppose 16 octets de données par exemple) sun_path n est pas forcément 0 terminé (spécification!) Comment indiquer la taille exacte du nom de fichier, et éviter les SEGFAULTS? chaque fois qu on passe une adresse sockaddr_xxx à une fonction, on doit lui passer aussi la taille de la structure en argument Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.18/48

Adressage Berkeley : Argument Pourquoi tous ces cast, et cet argument supplémentaire? Union : taille de l union = taille du plus grand des membres. Perte de place (110 octets même pour IPv4) sockaddr_un : devrait contenir son propre champs length... raisons historiques : inventées avant les autres IPC. Leur intégration s est fait avec compatibilité ascendante Solution choisie : solution de compromis. Taille minimum (16 octets), mais plus grand accepté pour certaines fonctions. cast au lieu d union pour implanter cela paramètre supplémentaire de taille Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.19/48

Création d une socket Pour s allouer une socket, on utilise l appel système socket. La socket obtenue n est connectée à rien (différence avec open pour les fichiers) c est juste un descripteur de fichier qu on peut utiliser pour les autres syscall il faut quand même s allouer la socket dans le bon espace. int socket(int family, int type, int protocol); family : la famille de protocoles utilisés : PF_UNIX Protocles IPC unix PF_INET Protocoles Internet PF_NS Xerox NS PF_IMPLINK IMP link PF_PACKET interface paquets à paquets Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.20/48

Création d une socket type : le type de communication parmis : SOCK_STREAM flux (orienté connection) SOCK_DGRAM datagram (orienté paquets) SOCK_RAW sockets raw SOCK_SEQPACKET paquets séquentiels Toutes les combinaisons ne sont pas possibles. On a notamment les combinaisons suivantes : PF_UNIX PF_INET PF_PACKET SOCK_STREAM Yes TCP SOCK_DGRAM Yes UDP IP SOCK_RAW Yes Eth Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.21/48

Création d une socket Les boîtes Yes sont des combinaisons possibles pour lesquelles il n existe pas d acronyme IP : intégralité du paquet, à partir de l en-tête IP Eth : intégralité du paquet, y compris l en-tête physique TCP/SOCK_RAW : ancienne combinaison pour obtenir le niveau physique (moins pratique) Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.22/48

Création d une socket protocol : sert à spécifier le protocole utilisé. On peut mettre à 0 (protocole par défaut pour la combinaison type/famille) dans la plupart des cas famille type identifiant de protocole Protocole réel PF_INET SOCK_DGRAM IPPROTO_UDP UDP PF_INET SOCK_STREAM IPPROTO_TCP TCP PF_INET SOCK_RAW IPPROTO_ICMP ICMP PF_INET SOCK_RAW IPPROTO_RAW (raw) PF_RAW SOCK_PACKET htons(eth_p_xxx) paquets du protocole ethernet XXX Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.23/48

Création d une socket solution alternative, pour le domaine UNIX uniquement : socketpair(int family, int type, int protocol, int sockvec[2]); Crée deux descripteurs de socket UNIX connectées et anonymes. similaire à pipe, mais les deux sockets sont accessible en lecture et écriture family doit être PF_UNIX type peut être SOCK_STREAM, ou SOCK_DGRAM protocol devrait être 0 Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.24/48

Associer : bind cas simple : protocole non connecté (UDP) Deux problèmes : si je suis serveur comment dire que je veux recevoir les messages sur le port 1024? si je suis client, comment dire que je veux recevoir des réponses à mes requêtes? Un appel système : bind bind associe le descripteur de socket à une adresse (de retour) dans la famille concernée les messages envoyés à cette adresse associée seront passés à la socket Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.25/48

UDP/IP Serveur (protocole sans connection) Client socket() bind() socket() bind() données (requête) recvfrom() sendto() données (réponse) sendto() recvfrom() Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.26/48

TCP/IP : rappels Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.27/48

TCP/IP Serveur (protocole avec connection) socket() bind() listen() Client socket() établissement de la connection accept() connect() read() recv() write() send() données (requête) données (réponse) write() send() read() recv() Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.28/48

Appels système : bind int bind(int sockf, struct sockaddr *myaddr, int addrlen) 1. Les serveurs enregistrent leur adresse auprès du système avec bind. 2. les clients peuvent enregistrer une adresse spécifique grace à bind 3. un client sans connection doit enregistrer (s allouer) une adresse pour recevoir des réponses à ses requêtes bind définis les paramètres local-addr et local-process du quintuplet associé à une communication réseau Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.29/48

Appels système : bind Pour la famille AF_INET, il existe deux valeurs particulières : 1. INADDR_ANY pour le champs sin_addr : associe le descripteur de fichiers à toutes les adresses IP. Sens : accepter un message de n importe qui sur l internet 2. 0 pour le champs sin_port. Sens : allouer un port libre, quelqu il soit. On se sert alors de getsockname pour connaitre le port alloué Peut échouer (renvoie alors -1). Erreur la plus probable : un autre processus est déjà associé à cette adresse sur la machine Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.30/48

Appels système : connect int connect(int sockfd, struct sockaddr *serveraddr, int addrlen) Pour les protocoles orientés connections (STREAM), connect établis la connection côté client si le bind n est pas fait avant (cas normal), connect associe le quadruplet local-addr, local-process, foreign-addr, foreign-process du client Pour les protocoles orientés sans connection (DGRAM), connect peut être utilisé Il ne crée pas de message de connection, mais associe à la socket une unique adresse de retour et d émission ainsi, un processus client peut ensuite faire du read/write ou send/recv sur la socket de plus, dans certaines implémentations, cela augmente le niveau d information fourni par les messages d erreur Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.31/48

Appels système : listen int listen(int sockfd, int backlog) Utilisé seulement par les protocoles orientés connections généralement juste après le bind, et de toute façon avant le premier accept signale que la socket sockfd est utilisée pour recevoir des connections entrantes backlog: nombre maximal de connections en attente que le noyau doit gérer avant de renvoyer automatiquement le connection refused Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.32/48

Appels système : accept int accept(int sockfd, struct sockaddr *peer, int *addrlen) Accept prends la première demande de connection de la queue de sockfd, et crée une nouvelle socket avec les mêmes propriétés que sockfd, mais connectée avec peer si aucune demande de connection ne se trouve dans la queue, bloque sockfd doit être en mode listen *addrlen doit être initialisé à la taille réelle de *peer, et contient à la sortie de accept la taille utilisée dans *peer Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.33/48

Appels système : accept *peer contient l adresse (au format dépendant de la famille de sockfd) de l hôte avec lequel la connection est établie *peer doit être initialisé à zéro (tous les champs sauf la famille) avant l appel accept définit les quatre paramètres du quintuplet de la communication réseau. foreign-addr, et foreign-process restent indéfinis dans sockfd, ce qui permet de le réutiliser tout de suite pour accepter une nouvelle connection Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.34/48

Appels système : send, sendto, recv, recvfrom int send(int sockfd, char *buf, int nbytes, int flags) int sendto(int sockfd, char *buf, int nbytes, int flags, struct sockaddr *to, int addrlen) int recv(int sockfd, char *buf, int nbytes, int flags) int recvfrom(int sockfd, char *buf, int nbytes, int flags, struct sockaddr *from, int *addrlen) Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.35/48

Appels système : send, sendto, recv, recvfrom sockfd, buf et nbytes fonctionnent exactement comme read et write flags est un ou logique des constantes suivantes (il y en a d autres qu on verra plus tard) : 1. MSG_OOB : emet ou recoit des données hors bande 2. MSG_PEEK : ne retire pas le message lu de la file des messages 3. MSG_DONTROUTE : envoie le paquet sans tenir compte des règles de routage (send ou sendto) Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.36/48

Appels système : close int close(int fd) int shutdown(int fd, int how) close libère la ressource allouée au descripteur de fichier. Pour les socket connectées : ferme une connection. Dans les deux sens pour close, selon how pour shutdown. how = SHUT_RD SHUT_WR SHUT_RDWR Les données restantes sont envoyées ou acknowledgées avant que le noyau ne libère complétement les ressources pour les protocoles fiables (TCP) il est cependant toujours préférable que le protocole applicatif ferme la connection à la two-way-handshake Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.37/48

Segmentation et fusion dans les flux Serveur char c[65536]; int i; for(i = 0; i < 65536; i+=1024) send(sockfd, c+i, 1024, 0); Client char r[65536]; int i; for(i = 0; i < 65536; i+=1024) recv(sockfd, r+i, 1024, 0) 1. send n emets pas forcément 1024 octets en une seule fois 2. recv ne reçoit pas forcément 1024 octets à chaque fois Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.38/48

Segmentation et fusion dans les flux fusions : deux sends peuvent se transformer en un seul recv (pas dans ce code) segementation : un send peut se transformer en plusieurs recv send : on emets de 1 à n octets recv : on reçoit de 1 à n octets ceci est vrai aussi pour read, write, sendto, recvfrom ce n est pas vrai pour les sockets en mode DGRAM : là, la décision est binaire toutes ces opérations sont de plus bloquantes! Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.39/48

Emission bloquante static int bsend(int sockfd, char *c, int tosend) { int sent, n; sent = 0; while(tosend > 0) { n = send(sockfd, c, tosend, 0); if( n == -1 ) { perror("bsend"); return sent; } sent += n; tosend -= n; c += n; } return sent; } Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.40/48

Reception bloquante static int brecv(int sockfd, char *c, int toreceive) { int received, n; received = 0; while(toreceive > 0) { n = recv(sockfd, c, toreceive, 0); if( n == -1 ) { perror("brecv"); return received; } received += n; toreceive -= n; c += n; } return received; } Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.41/48

Exemples de clients et serveurs Client UDP Serveur UDP Client TCP Serveur TCP multi process multi thread Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.42/48

DNS : résolution de noms #include <netdb.h> extern int h_errno; struct hostent *gethostbyname(const char *name); void herror(const char *s); const char *hstrerror(int err); DNS : Domain Name Service résouds une FQDN en adresse IP (Fully Qualified Domain Name) www.lri.fr => 129.175.15.10 Des fois pas si simple www.google.fr -> www.google.com -> www.l.google.com -> (216.239.59.147, 216.239.59.99, 216.239.59.103, 216.239.59.104) Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.43/48

DNS : résolution de noms struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ }; #define h_addr h_addr_list[0] /* for backward compatibility les tableaux sont zéro terminés tout est alloué par gethostbyname, et rien ne doit être désalloué deux appels consécutifs à gethostbyname écrasent les valeurs précédentes! Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.44/48

DNS : exemple struct hostent *h; char **a; struct in_addr addr; h = gethostbyname("www.google.fr"); if(!h ) { herror("www.google.fr"); exit(1); } printf("true name : %s\n", h->h_name); Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.45/48

DNS : exemple if( *(h->h_aliases) ) { printf("aliases :\n"); for(a = h->h_aliases; *a; a++) printf(" %s\n", *a); } assert( (h->h_addrtype == AF_INET) && (h->h_length == 4) ); printf("addresses :\n"); for(a = h->h_addr_list; *a; a++) { memcpy(&addr, *a, h->h_length); printf(" %s\n", inet_ntoa(addr)); } Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.46/48

DNS : Alternative Windows, getaddrinfo int getaddrinfo( const TCHAR *nodename, const TCHAR *servicename, const struct addrinfo *hints, struct addrinfo *result ); nodename : le nom de la machine servicename : le service sous forme numérique ou acsii ("80" ou "http") hints : NULL, ou lisez le msdn result : liste chainée de résultats qui doit être libérée par freeaddrinfo Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.47/48

DNS : Alternative Windows, getaddrinfo typedef struct addrinfo { int ai_flags; int ai_family; int ai_socktype; int ai_protocol; size_t ai_addrlen; TCHAR* ai_canonname; struct sockaddr* ai_addr; struct addrinfo* ai_next; } addrinfo; ai_family, socktype et protocol peuvent être utilisé tels quels dans socket ai_addr et ai_addrlen dans les autres appels ai_next pointe vers l adresse suivante. Cours de système IFIPS-3 / (IPC - Réseau, Sockets) p.48/48