Network Programming in C

Transcription

1 Network Programming in C Stefan Bruda, Bishop s University, Winter 2007 I. Principes des clients / serveurs Application Transport Network Link Physical C/C++ TCP IP Ethernet Twisted pair On a 5 niveaux, chacun ayant une interface avec la couche inférieure et la couche supérieure. ESMTP est au niveau application et utilise la couche transport pour fonctionner telnet turing.ubishops.ca 25 ehlo parl.qc.ca mail from : steve@parl.qc.ca rcpt to: bruda data quit Un subnet est un ensemble de machines connectées les unes aux autres directement. Au niveau du Network, on a des subnet ; plusieurs subnet raccordés par des routeurs font un internet. Internet est le plus grand des internet. Tout le principe du réseau tourne autour de la communication. Pour que deux programmes puissent se comprendre, ils doivent parler un langage commun, i.e. un protocole. Les protocoles sont standards s ils sont définis dans l ensemble des protocoles TCP/IP (transferts de fichiers et mail y sont), ou non-standards. L application level protocol consiste à parler directement à un serveur ; on identifie le programme auquel on s adresse car il est sur un certain port. Dans l exemple ci-contre, on parle sur le port 25 qui est responsable de la transmission des s. Le serveur est un programme qui écoute les communications entrantres ; il attend des clients. Le client va se lancer peut se lancer quand il veut et parler, car le serveur sera en écoute. Si le client veut parler et qu il n y a personne ou que le serveur démarre et que le client est parti Le serveur se lance avant les clients

2 Quand un client veut se connecter à un serveur, il veut qu il connaisse l adresse de la machine et un numéro de port (il y a ports possibles). Bien évidemment, le client doit parler la langue du serveur. Certains clients ne font qu une seule chose, par exemple gérer des transferts de fichiers ; d autres clients sont paramétrables, comme telnet qui est complètement paramétrables : il peut enclencher une connexion sur n importe quel port, et ce sera à l utilisateur de parler le protocole de façon adéquate. Les serveurs sur le protocole TCP partent du principe que tous les paquets de données arrivent correctement et dans l ordre d émission. TCP s occupe de la fiabilité pour gérer l accumulation des paquets arrivants, les paquets perdus et ceux arrivés plusieurs fois (acknoweldgment & retransmission). En raison de ceci, le coût d utilisation de TCP est de 10 à 25% de la bande passante. Dans des situations où on a une bande passante limitée (plutôt historique ), on utilise UDP : le protocole n est pas très fiable (best effort delivery) car il peut perdre des paquets et n a pas de buffer, mais son coût d utilisation est quasi nul. Le protocole UDP est aussi utilisé dans le streaming : quand on regarde une vidéo sur internet, on peut accepter de perdre certaines frames car on les obtient par interpolation ou on ne les voit simplement pas (perdre 1 frame alors qu il y en a 24 par secondes n est pas un gros soucis). On utilise aussi UDP lorsqu on a besoin de vitesse plus que de fiabilité : dans les jeux en ligne, on presse un bouton et on veut que ça réagisse rapidement. TCP/IP Machine TCP/IP Modem ADSL ATM DSLAM Voice Internet Emballe le paquet TCP/IP en ATM, et il sera déballé de l autre côté d où une charge supplémentaire Switch Networks : cells (telephone ) instead of packet network (point to point) Le serveur peut conserver une information sur l état du client, ou non. Un stateless serveur ne se rappelle pas de ce que le client a fait : un client envoie une commande, et c est tout, il n y a pas de notion de «commande précédente». Un stateful serveur garde en mémoire les informations du client : le client peut faire les choses en plusieurs fois car les requêtes sont liées entre elles ; c est par exemple le système du mail : une requête précise le destinataire, une autre le contenue, etc., et donc les requêtes sont liées entre elles et imposent de mémoriser l état du client. Un serveur peut-être stateless à cause du protocole, mais avoir besoin de garder des informations à propos du client. Ainsi, on a les cookies : HTTP est stateless mais sur un site de shopping, on peut avoir un chariot et donc on le stockera dans le cookie. On peut aussi avoir une base de données du côté du serveur et le cookie est un identifiant. Ainsi, en ajoutant des choses au niveau application, on peut avoir un protocole stateless mais dont l utilisateur est statefull. POP 1 (retirer du courrier) et HTTP sont stateless. NFS 2 (envoi de fichiers) a évolué : les versions 1 et 2 (sur UDP) et 3 sont stateless, mais la version 4 est stateful. La dernière version est incompatible avec les précédentes, mais comporte de grandes améliorations sur la sécurité et le fait d être stateful permet notamment de faire de la reprise sur incident. Les protocoles comme SMTP 3 et FTP 4 sont statefull. 1 Post Office Protocol : voir RFC 1939 pour la définition de la version 3. 2 Network File System : voir RFC 3010 pour la définition de la version 4, et RFC 1813 pour la définition de la version 3. 3 Simple Mail Transfer Protocol : voir RFC 2821 pour la définition. Extensions RFC Les 821, 1869, 1891 sont obsolètes. 4 File Transfer Protocol : voir RFC 959 pour la définition. Extensions RFC 1579, 2228 et 3659.

3 II. La concurrence avec plusieurs processus Un appel à fork() dupplique le processus courant. Le processus initial est dit parent, et le résultat est le fils. Les deux processus continuent à partir du point où ils ont été dupliqués. En général, on fait prendre à chacun des actions différentes juste après la dupplication. while(1){ fork() ; // comment surcharger un système et le faire crasher Les processus sont identifiés par un entier, le Process Identifier (PID). fork() retourne deux entiers différents dans le fils et le père : dans le fils on a 0, et dans le père on a le PID du fils. Supposons qu on veuille lancer une commande externe et continuer le programme par la suite, mais une fois seulement que la commande aura été faite. En bref, pour une certaine raison, le processus père a besoin d attendre que le processus fils ait fini son travail. On utilise la commande waitpid. Il est conseillé de mettre une sécurité après execve, au cas où un problème se passe et l appel ne soit pas fait. Ainsi, on le continu par perror( FILE ) si on veut que le nom du fichier s affiche, ou perror(«exec») si on veut la raison. Enfin, on quitte le processus avec exit(1). L appel execve remplace complètement le processus actuelle avec l exécutable passé en paramètre. Si on veut lancer une commande extérieure mais continuer également le programme principal, alors on fait un fork() et dans le fils on fait un execve. int childp = fork(); if (childp == 0) { // child execve(command, argv, envp); else { // parent // code that continues our program int run_it (char* command, char* argv [], char* envp[]) { int childp = fork(); int status; if (childp == 0) { // child execve(command, argv, envp); else { // parent waitpid(childp, &status,0); // waitpid attend UN child, wait les attend tous return status; L appel execve a plusieurs autres variantes utiles : - execv, où on donne le chemin complet de l exécutable - execvp où on donne juste le nom et ça trouve l endroit - voir aussi execl, execlp, execle superserveur L argument «envp» de exec est null-terminated (pas besoin de donner la taille), de même pour argv.

4 Quand on fait de la programmation système, il faut toujours vérifier le résultat des appels systèmes. Ainsi, si fork() retourne -1 alors il vaut mieux tuer le programme ; cela peut signifier un manque d espace, impossible de créer plus de processus, et donc on va tenter de libérer un peu le système Il y a une explication aux problèmes dans errno.h, qui défini extern int errno. Errno est modifié en cas d erreur seulement, ainsi il contient le code de la dernière erreur (i.e. la plus récente). Si on regarde la page du manuel, on voit quantités de macros sur la valeur de errno, dont : - EAGAIN : l échec n est probablement que temporaire, vous devriez essayer à nouveau car vous avez des chances de réussir. - EDEADLOCK, perror est la fonction conseillée pour afficher un problème de façon lisible. On a sterror(int) qui retourne une chaîne décrivant le code d erreur fourni. Pour les threads, on utilisera strerror_r car il y a un buffer. En effet, un 2 nd appel à sterror() modifie la 1 ère chaîne rendue, ce qu il faut éviter si on utilise des threads! Si on veut connaître le dernier code de sortie d un programme, on tapera «echo $?» dans la console linux. Si on veut mettre plusieurs types en écoute, il suffit de mettre plusieurs ports en écoute. Un superserveur (c.f. fin de la page précédente) ne sait parler aucun protocole, mais il connaît les serveurs capable de le faire : il délègue les tâches. C est un groupement des services qui sont supposés être lancés rarement. III. Connaître les appels systèmes #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include <stdio.h> #include <unistd.h> int main (int argc, char** argv) { int file = open(argv[1],o_wronly O_CREAT O_APPEND,S_IRUSR S_IWUSR); int i = 0; char prefix[12]; char message[256] = "something"; if (file == -1) return 1; while (true) { i++; printf("message: "); fgets(message,255,stdin); if (message[strlen(message)-1] == \n ) message[strlen(message)-1] == \0 ; if (strlen(message) == 0) break; snprintf(prefix,12,"%d: ",i); write(file,prefix,strlen(prefix)); write(file,message,strlen(message)); write(file,"\n",1); close(file); O_CREAT permet de spécifier en 3 ème argument les permissions. S_IRUSR donne la permission de lecture (read). On a S_IXYYY avec X = {R,W,X, YYY = {USR,GRP,OTH (il suffit de combiner). snprintf est une fonction très pratique qui marche comme printf et écrit dans une chaîne de caractère. Très efficace pour faire le cast d un int en char*, par exemple. sprintf : pas limite.

5 #include <string> #include <iostream> #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <sys/types.h> using namespace std; int main(int argc, char **argv){ if(argc <= 1){ version there must be no input prompt.» cerr << "You must provide the file name to store the results.\n"; exit(1); cout << "1) First implementation using system\n"; while(1){ string s = ""; cout << "{File to look for"; getline(cin,s); if(s == "") break; string invocation = "file " + s + " >> "; for(char *c = argv[1]; *c!= '\0'; c++) invocation += *c; cout << invocation << endl; system(invocation.c_str()); «The following asks you to write a wrapper for the Unix command file, as follows: Your program reads from the standard input a number of file names, one per line. For each input, the program invokes the command file and prints to the standard output the result. The program terminates when it reads an empty string. Create two versions of the program, one what waits for a file command to complete before issuing the next command, and another that does not wait (instead, the command file will be called on the file name given by the just read line before processing the remainder of the input). No matter the cout << "2) Second implementation using execvp...\n"; int fd = open(argv[1],o_wronly O_CREAT O_APPEND,S_IRUSR S_IWUSR); if(fd == -1){ // This solution is the most secure because we try BEFORE closing! perror("wrong access to the file"); exit(1); // we open a file. It finds the first free place in the table, and give the number int templocation = dup(1); close(1); // or fclose(stdout). The 1st place, for the output is free! dup2(fd,1); // the old file descriptor is set in 1. Default output! while(1){ char *s = (char *)malloc(30*sizeof(char)); cout.flush(); // fflush(stdout); cin.getline(s,30); if(*s == '\0') break; char *cmd[] = {"-f", s, 0; int childp = fork(); if(childp==0){ // child execvp("file",cmd); // execvp replaces the code in the child perror( FILE ); // never reached exit(1); // waitpid(childp) to simulate like in system close(1); // we close our 'file' dup2(templocation,1); // restore the default stdout La commande dup(entry) permet de dupliquer une entrée de la descriptor table. L entrée duppliquée va se placer dans la première place libre qu elle rencontre, donc à la fin. L autre commande est dup2(source, target) qui dupliquer une entrée de la description table et la met à un endroit donnée ; elle renvoie -1 s il y a erreur (i.e. la destination n est pas un numéro de descripteur valide). Ici, on se sert de ces fonctions pour rediriger la sortie courante. On commence par la copier : int templocation = dup(1) ; On la ferme afin de créer un trou, avec close(1). On redirige la sortie courante vers le fichier que l on a ouvert, par dup2(fd, 1). A la fin, on restore la sortie courante en fermant le fichier et en remettant le bon descripteur. On voit qu on protège en cas d erreur du execvp par un perror et un exit. On voit également la structure d un execvp : le nom de la commande, et les arguments null-terminated (i.e. un 0 à la fin). Si le père attend le processus fils alors notre application se transforme en console (foreground), sinon le fils exécute en background.

6 #include <stdio.h> #include <libgen.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #include <stdlib.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include "tokenize.h" #include "tcp-utils.h" // for `readline' only /* * Global configuration variables. */ // path, null terminated (static) const char* path[] = {"/bin","/usr/bin",0; const char* prompt = "sshell> "; // prompt const char* config = "shconfig"; // configuration file /* * Typical reaper. */ void zombie_reaper (int signal) { int ignore; while (waitpid(-1, &ignore, WNOHANG) >= 0) /* NOP */; /* * Dummy reaper, set as signal handler in those cases when we want * really to wait for children. Used by run_it(). * * Note: we do need a function (that does nothing) for all of this, we * cannot just use SIG_IGN since this is not guaranteed to work * according to the POSIX standard on the matter. */ void block_zombie_reaper (int signal) { /* NOP */ «Le but de ce premier devoir était de construire une console, capable d exécuter des commandes en background ou en foreground. On utilise fork() pour créer un processus qui exécutera la commande. Si on veut la lancer en arrière-plan (background), la commande est précédée de &. Afin de s assurer qu on ait un certain niveau de protection, la commande exécute dans les répertoires que l on autorise. Quand on programme des clients (et surtout les serveurs), on tente de restreindre au maximum les droits : si notre programme est cracké par quelqu un, on veut minimiser les dégâts. Le «tokenizer sur place» employé met des séparateurs \0 dans l argument, et le renvoit sous forme d interprétation de char**.» /* * run_it(c, a, e, p) executes the command c with arguments a and * within environment p just like execve. In addition, run_it also * awaits for the completion of c and returns a status integer (which * has the same structure as the integer returned by waitpid). If c * cannot be executed, then run_it attempts to prefix c successively * with the values in p (the path, null terminated) and execute the * result. The function stops at the first match, i.e., it executes * at most one external command. */ int run_it (const char* command, char* const argv[], char* const envp[], const char** path) { // we really want to wait for children so we inhibit the normal // handling of SIGCHLD signal(sigchld, block_zombie_reaper); int childp = fork(); int status = 0; if (childp == 0) { // child does execve #ifdef DEBUG fprintf(stderr, "%s: attempting to run (%s)", FILE, command); for (int i = 1; argv[i]!= 0; i++) fprintf(stderr, " (%s)", argv[i]); fprintf(stderr, "\n"); #endif execve(command, argv, envp); // attempt to execute with no path prefix... for (size_t i = 0; path[i]!= 0; i++) { //... then try the path prefixes char* cp = new char [strlen(path[i]) + strlen(command) + 2]; sprintf(cp, "%s/%s", path[i], command); #ifdef DEBUG fprintf(stderr, "%s: attempting to run (%s)", FILE, cp); for (int i = 1; argv[i]!= 0; i++) fprintf(stderr, " (%s)", argv[i]); fprintf(stderr, "\n"); #endif execve(cp, argv, envp); delete [] cp; // ASSERT: all execve calls failed (errno set) char* message = new char [strlen(command)+10]; sprintf(message, "exec %s", command); perror(message); delete [] message; exit(errno); // need to exit so that the function does not // return twice! else { // parent just waits for child completion waitpid(childp, &status, 0); // we restore the signal handler now that our baby answered signal(sigchld, zombie_reaper); return status;

7 int main (int argc, char** argv, char** envp) { size_t hsize = 0, vsize = 0; // terminal dimensions, read from the config file char command[129]; // buffer for commands command[128] = '\0'; char* com_tok[129]; // buffer for the tokenized commands size_t num_tok; // number of tokens printf("simple shell v1.0.\n"); int confd = open(config, O_RDONLY); // Parsing of config starts here if (confd < 0) { perror("config"); fprintf(stderr, "config: cannot open the configuration file.\n"); fprintf(stderr, "config: will now attempt to create one.\n"); confd = open(config, O_WRONLY O_CREAT O_APPEND, S_IRUSR S_IWUSR); if (confd < 0) { // cannot open the file, giving up. perror(config); fprintf(stderr, "config: giving up...\n"); return 1; close(confd); Main : partie 1 // re-open the file read-only confd = open(config, O_RDONLY); if (confd < 0) { //cannot open the file, we'll PROBABLY never reach this one perror(config); fprintf(stderr, "config: giving up...\n"); return 1; // read terminal size while (hsize == 0 vsize == 0) { int n = readline(confd, command, 128); if (n == recv_nodata) break; if (n < 0) { sprintf(command, "config: %s", config); perror(command); break; num_tok = str_tokenize(command, com_tok, strlen(command)); // note: VSIZE and HSIZE can be present in any order in the // configuration file, so we keep reading it until the // dimensions are set (or there are no more lines to read) if (strcmp(com_tok[0], "VSIZE") == 0 && atol(com_tok[1]) > 0) vsize = atol(com_tok[1]); else if (strcmp(com_tok[0], "HSIZE") == 0 && atol(com_tok[1]) > 0) hsize = atol(com_tok[1]); // lines that do not make sense are hereby ignored close(confd); if (hsize <= 0) { // invalid horizontal size, will use defaults (and write them // in the configuration file) hsize = 75; confd = open(config, O_WRONLY O_CREAT O_APPEND, S_IRUSR S_IWUSR); write(confd, "HSIZE 75\n", strlen( "HSIZE 75\n")); close(confd); fprintf(stderr, "%s: no valid horizontal terminal size, will use the default\n", config); printf("terminal set to %ux%u.\n", (unsigned int)hsize, (unsigned int)vsize); // install the typical signal handler for zombie cleanup // (we will inhibit it later when we need a different behaviour, see run_it) signal(sigchld, zombie_reaper); // Command loop: while(1) { Main : partie 2 printf(prompt); // Read input: fflush(stdin); fgets(command, 128, stdin); // fgets includes newline in the buffer, get rid of it if(strlen(command) > 0 && command[strlen(command) - 1] == '\n') command[strlen(command) - 1] = '\0'; // Tokenize input: char** real_com = com_tok; //may need to skip 1 st token, so use a pointer to access tokenized command num_tok = str_tokenize(command, real_com, strlen(command)); real_com[num_tok] = 0; // null termination for execve int bg = 0; if (strcmp(com_tok[0], "&") == 0) { // background command coming #ifdef DEBUG fprintf(stderr, "%s: background command\n", FILE ); #endif bg = 1; // discard the first token now that we know that it // specifies a background process... real_com = com_tok + 1; // ASSERT: num_tok > 0 and process input if (strlen(real_com[0]) == 0) // no command, luser just pressed return continue; else if (strcmp(real_com[0], "exit") == 0) { printf("bye\n"); return 0; else if (strcmp(real_com[0], "more") == 0) { // note: more never goes into background (any prefixing`&' is ignored) if (real_com[1] == 0) printf("more: too few arguments\n"); // list all the files given in the command line arguments for (size_t i = 1; real_com[i]!= 0; i++) do_more(real_com[i], hsize, vsize); else { // external command if (bg) { // background command, we fork a process that awaits for compl int bgp = fork(); if (bgp == 0) { // child executing the command int r = run_it(real_com[0], real_com, envp, path); printf("& %s done (%d)\n", real_com[0], WEXITSTATUS(r)); if (r!= 0) printf("& %s completed with a non-null exit code\n", real_com[0]); return 0; else continue; // parent goes ahead and accepts the next command else { // foreground command, we execute it and wait for completion int r = run_it(real_com[0], real_com, envp, path); if (r!= 0) printf("%s completed : non-null exit code (%d)\n", real_com[0], WEXITSTATUS(r));

8 IV. TCP/IP API Le standard TCP/IP ne précise pas l API mais seulement les fonctionnalités. L interface doit permettre : - d allouer et de libérer des ressources pour la communication - spécifier les endpoints (i.e. les deux extrémités de la communication : qui parle avec qui) - à un client d initier une connexion, ou à un serveur d attendre une connexion - envoyer et recevoir des données - identifier l arrivée de données - générer des données urgentes et savoir gérer l arrivée de données urgentes - terminer une connexion et annuler une communication - gérer les conditions d erreurs La communication en TCP/IP est full duplex, c est-à-dire dans les deux sens. On utilise l implémentation appelée Berkeley Sockets (pratiquement la seule sur Linux). En fait, la seule autre version des sockets que l on trouve couramment est celle de Windows. Les Berkeley Sockets retournent un descriptor dans la descriptor table (comme lorsqu on fait un open avec un fichier), ainsi : int sd = socket(pf_inet, SOCK_STREAM, 0) (PF_INET : Protocol Family Internet. SOCK_STREAM : TCP Socket, vs SOC_DGRAM : UDP socket, i.e. datagramme) En principe, il y a des familles d adresses pour contenir différents types d adresse. En pratique, TCP/IP n utilise que la famille AF_INET. L adresse (dans une famille d adresses) doit contenir au moins l adresse d une machine et un numéro de port. L API contient des structures C pour cela. struct sockaddr_in {... sa_family_t sin_family; /* Address family, AF_INET for us */ unsigned short int sin_port; /* Port number */ struct in_addr sin_addr; /* Internet address */... ; struct in_addr { unsigned int s_addr; /* 32 bits, i.e., 4 bytes */ ; #include <stdio.h> #include <netdb.h> extern int h_errno; int main (int argc, char** argv) { struct hostent* host_info = gethostbyname(argv[1]); if (host_info!= NULL) { printf("%s is", argv[1]); for (int i = 0; i < host_info -> h_length; i++) printf("%d.", (int)((host_info -> h_addr)[i])); printf("\n"); else printf("host lookup error %d: %s\n", h_errno, hstrerror(h_errno)); L adresse d un serveur est donnée avec un nom de machine ou une adresse IP. Quelle que soit la façon dont elle est donnée, il faut qu on obtienne l adresse IP actuelle. Pour cela, on utilise gethostbyname qui met le résultat dans une structure de type hostent. L appel est : struct hostent* host_info = gethostbyname(argv[1]); struct hostent { char *h_name; /* Official name of host. */ char **h_aliases; /* Alias list. */ int h_addrtype; /* Host address type. */ int h_length; /* Longueur d adresse en norme d IP donnée */ char **h_addr_list;/* List of addresses from name server. */ #define h_addr h_addr_list[0] /* Address, for backward compatibility.*/ ; h_addr_list est un tableau contenant les bytes de l adresse organisé en network byte order (big endian : les plus les plus significants sont en tête)

9 Si on connaît le nom d un service standard, on peut trouver le port qui lui est associé en utilisant getservbyname. De même que gethostbyname, on va mettre le résultat dans une structure qui est ici servent. struct servent { char *s_name; /* Official service name. */ char **s_aliases; /* Alias list. */ int s_port; /* Port number. */ char *s_proto; /* Protocol to use. */ ; struct servent* service = getservbyname("ftp","tcp"); if (service!= NULL) { printf("%s\n%d\n%s\n", service -> s_name, service -> s_port, service -> s_proto); < godel:slides/code >./a.out ftp 21 tcp Résultat à la console Exemple d utilisation L adresse du serveur peut-être spécifiée de plusieurs façons, selon ce que l on fait : - codée directement comme un entier (rare) - en argument (lors de l appel du programme ou dans un fichier de configuration). On utilise alors gethostbyname. - en utilisant un protocole séparé (broadcast, multicast, ) pour trouver un server De même il y a plusieurs spécifications du port : - Codée directement (quand on fabrique nous-même l application client/serveur) - Le port est connu : getservbyname - En argument. Pratique pour avoir des clients complètement paramétrables! On a besoin d une adresse IP locale puisque la connexion se fait dans les deux sens. Attention choisir une adresse IP n est pas trivial : elle doit permettre de router les paquets dans la bonne direction, ce qui peut-être aussi bien Internet qu un réseau local (on utilise x.x). Le choix de l adresse IP se fait après un dialogue avec IP. L appel système connect s en charge pour nous. #include <errno.h> extern int errno; struct sockaddr_in sin; int rc = connect(sd, (struct sockaddr *)&sin, sizeof(sin)); if (rc < 0) { perror("connect"); exit(1); De même qu il faut spécifier une adresse locale, on doit spécifier un port local. Le choix de ce port n a pas une grande importance, tant qu il n est pas utilisé par un autre processus ou n entre pas au conflit avec le port donné pour un service bien connu. On pourrait essayer aléatoirement jusqu à trouver un port libre, mais comme le système garde trace de l utilisation des ports, ce serait du travail inutile. Ainsi, connect encore. int connect(int sockfd, struct sockaddr *serv_addr, socklen_t addrlen); int connectbyportint(const char* host, const unsigned short port) { struct hostent *hinfo; struct sockaddr_in sin; const int type = SOCK_STREAM; int sd; memset(&sin, 0, sizeof(sin)); sin.sin_family = AF_INET; hinfo = gethostbyname(host); if (hinfo == NULL) return err_host; memcpy(&sin.sin_addr, hinfo->h_addr, hinfo->h_length); sin.sin_port = (unsigned short)htons(port); sd = socket(pf_inet, type, 0); if ( sd < 0 ) return err_sock; int rc = connect(sd, (struct sockaddr *)&sin, sizeof(sin)); if (rc < 0) { close(sd); return err_connect;

10 On envoie des données avec send, dont la signature est int send(int s, const void *msg, size_t len, int flags). Le flag est habituellement laissé à 0, mais on peut par exemple spécifier MSG_DONTROUTE qui demande à ne pas router le paquet car on a l intention de rester sur le réseau local. On a aussi MSG_DONTWAIT ; une opération qui devrait bloquer nous donnera le code d erreur EAGAIN à la place. On reçoit des données en utilisant recv. Attention : les données arrivent en pièces détachées, même si c est dans le bon ordre. En particulier, rien ne nous dit qu on va trouver une fin de ligne dans ce qu on lit : elle viendra peut-être après. On accepte donc les données de retour par groupe de bytes. Il n y a pas de marqueur de fin, donc on lit des données tant que le serveur décide de nous en envoyer, i.e. on lit des données jusqu à ce qu il n y en ait plus. Pour cela, on utilise une de nos fonctions recv_nonblock qui nous renvoie recv_nodata si le serveur n a plus rien envoyé après un certain timeout (la communication n est pas instantanée). const int ALEN = 128; char* req = "some sort of request"; char ans[alen]; char* ans_ptr = ans; int ans_to_go = ALEN, n = 0; send(sd,req,strlen(req),0); while ( ( n = recv(sd,ans_ptr,ans_to_go,0) ) > 0 ) { ans_ptr += n; ans_to_go -= n; const int recv_nodata = -2; // -2 s il n y a plus de données, 0 si fin de fichiers // sinon, >0 est le nombre de caractères lus int recv_nonblock (int sd, char* buf, size_t max, int timeout) { struct pollfd pollrec; pollrec.fd = sd; pollrec.events = POLLIN; int polled = poll(&pollrec,1,timeout); if (polled == 0) return recv_nodata; if (polled == -1) return -1; return recv(sd,buf,max,0); Une fois la connexion terminée, on fait close ce qui va fermer la connexion et détruire le socket. Quand un client a fini de dialoguer avec le serveur, il le prévient en utilisant shutdown, avec l appel suivant : int err = shutdown(sd, 1) ; Le second argument de shutdown est à choisir dans : - SHUT_RD(0) refus de réceptions futures - SHUT_WR(1) refus d envoi dans le futur - SHUT_RDWR(2) ni envoi ni réception int do_communicate(int sd, char* const request[], const char* host, const unsigned short port, const int keepalive) { #ifdef DEBUG fprintf(stderr, "%s: received descriptor %d.\n", FILE, sd); #endif // connect unless already connected if (sd < 0) sd = connect_it(host, port); if (sd < 0) { // failed connection attempt. You should report the error. return sd; for (int i = 0; request[i]!= 0; i) { // have socket, will deliver send(sd, request[i], strlen(request[i]), 0); if (request[i 1]!= 0) send(sd, " ", 1, 0); send(sd, "\n", 1, 0); Début de la fonction // should probably check for sending errors, but they are so // unlikely, and we will probably detect the problems when we // attempt to receive anyway Fonction utilisée pour envoyer une requête à un serveur en utilisant un socket qu on choisit parfois de garder en vie après la fin de la connexion, pour le réutiliser. // receive and print answer const int ALEN = 256; char ans[alen]; int n; while ((n = recv_nonblock(sd, ans, ALEN-1, 500))!= recv_nodata) { if (n == 0) { close(sd); printf("connection closed by %s.\n", host); return -1; if (n < 0) { perror("recv_nonblock"); shutdown(sd, SHUT_WR); close(sd); return -1; ans[n] = '\0'; printf("%s", ans); fflush(stdout); if (!keepalive) { shutdown(sd, SHUT_WR); close(sd); return -1; return sd; // problem with receiving, socket probably unusable Fin de la fonction // close socket if applicable

11 V. Introduction aux serveurs L adresse IP et le numéro de port sont spécifiés en utilisant la structure sockaddr_in. On utilise INADDR_ANY, qui est une sorte de «joker» correspondant à toutes les adresses IP de l hôte. Serveur réellement itératif : un seul client à la fois. Deux en même temps : l un patiente Serveur itératif avec une fausse concurrence Serveurs réellement concurrents en créant de nouveaux processus Un serveur réellement itératif souffre d un gros handicap : si deux clients arrivent presque en même temps, l un des deux devra probablement attendre longtemps. On simule donc une forme de concurrence ; comme le serveur reste itératif, il faut être conscient qu on a une fausse concurrence Ces serveurs sont surtout très prompts aux deadlock : si un client se connecte mais n envoie aucune donnée, le serveur complet est en attente au lieu de simplement un processus/thread. Ainsi, on met en place des serveurs vraiment concurrents qui fabriquent de nouveaux processus. Le seul processus qui peut se retrouver bloqué est celui en train de servir le client qui se comporte mal ; le processus qui gère le serveur n en sera pas inquiété. Ceci étant, on peut quand même faire sauter le serveur : un client peut envoyer des requêtes sans jamais lire les réponses jusqu à saturer le buffer TCP. Notons que lorsqu un processus fait un appel système et que le système ne peut pas l exécuter, alors le processus va se bloquer. Comme on fait des fork pour créer de nouveaux processus, on va se retrouver avec des processus non terminés (zombie). Dans un serveur, il faut absolument les nettoyer. Un processus fils envoie SIGCHLD quand il termine à son parent : on gère ce signal avec zombie_reaper. void zombie_reaper (int sig) { int status; while (waitpid(-1,&status, WNOHANG) >= 0); signal(sigchld,zombie_reaper); // avant le fork

12 VI. Communication : Fichiers, signaux et pipes On a un serveur concurrent, qui peut accéder à des fichiers. Pour éviter que tout le monde se mette à y écrire même temps, on verrouille le fichier avant de faire une opération et on le libère après. Si un fichier est verrouillé par un autre processus, write sera bloquant (attention aux deadlock ). On utilise : lockf(fd, F_LOCK, 0) ; // retourne -1 si déjà verrouillé et errno à EAGAIN lockf(fd, F_TEST, 0) ; // vérifier si le fichier est déjà verrouillé lockf(fd, F_ULOCK, 0) ; // déverrouillé le fichier Le lock est assuré car codé dans le noyau, mais il ne marche que pour l écriture : un processus peut toujours lire d un fichier vérouillé. On peut verrouiller simplement certains morceaux d un fichier, en utilisant le troisième argument qui est l offset. Si on veut des locks plus flexibles, on utilise fcntl : struct flock lock; fcntl(fd,f_getlk,&lock); // get the lock status in l_type (below), or fcntl(fd,f_setlk,&lock); // tries to lock, returns -1 on insuccess, or fcntl(fd,f_setlkw,&lock); // tries to lock, wait as long as necessary (deadlock possible!) La structure flock a les champs suivants : l_type type of lock: F_RDLCK, F_WRLCK, or F_UNLCK (set by F_GETLK) l_whence where l_start is relative to (like third argument of lseek) l_start offset where the lock begins l_len size of the locked area (zero means until EOF) l_pid process holding the lock Pour communiquer, les processus peuvent simplement s envoyer des signaux, qui sont des entiers. Les signaux sont envoyés automatiquement par le système dans la plupart des cas (exemple SIGCHLD) mais SIGUSR1 et SIGUSR2 sont définis par l utilisateur. On utilise int kill(pid_t pid, int sig); où pid est l identité d un processus ou 0 (signal à tous les processus du groupe), ou -1 (signal à tous les processus sauf init). Pour recevoir le signal, on établit un signal handler en utilisant la fonction signal(nom du signal, fonction). Si les signaux ne sont pas assez et qu on a surtout besoin de passer des informations, on utilise des pipes. #include <unistd.h> int pipe(int filedes[2]); // filedes[1] pour écriture, filedes[2] pour lecture #include <stdio.h> #include <unistd.h> #include <sys/types.h> int main(void) { int fd[2], nbytes; // déclare pid_t childpid; char string[] = "Hello, world!\n"; char readbuffer[80]; pipe(fd); // met en pipe if((childpid = fork()) == -1) { perror("fork"); exit(1); if(childpid == 0){ /* Child process closes up input side of pipe */ close(fd[0]); /* Send "string" through the output side of pipe */ write(fd[1], string, (strlen(string)+1)); exit(0); else{ /* Parent process closes up output side of pipe */ close(fd[1]); /* Read in a string from the pipe */ nbytes = read(fd[0], readbuffer, sizeof(readbuffer)); printf("received string: %s", readbuffer); return(0); Fork, exec et pipes sont les outils de bases en Unix. La philosophie Unix est de faire un programme qui fait une seule chose et la fait bien : on peut lier les programmes entre eux car les fork sont peu coûteux (contrairement à Windows ou on évite de créer les processus ). Pour faire discuter les programmes, on utilise les pipes.

13 VII. Critical Sections Certaines parties du code doivent être exécutées par un seul processus à un moment donné. On parle de sections critiques (Critical Sections). Afin de s assurer qu il n y ait qu un seul processus, on entoure la section critique avec un verrou : on demande à verrouiller un fichier et on le relâche une fois fini. int enter_critical (int fd) { struct flock lock_info; lock_info.l_type = F_WRLCK; lock_info.l_whence = SEEK_SET; lock_info.l_start = lock_info.l_len = 0; int status; while ( (status = fcntl(fd,f_setlkw,&lock_info)) == -1 && berrno == EINTR ) { // reconstruct lock_info: lock_info.l_type = F_WRLCK; lock_info.l_whence = SEEK_SET; lock_info.l_start = lock_info.l_len = 0; if (status == -1) perror("enter_critical"); return status; Fonction de verrou int exit_critical (int fd) { struct flock lock_info; lock_info.l_type = F_UNLCK; lock_info.l_whence = SEEK_SET; lock_info.l_start = lock_info.l_len = 0; int status; while ( (status = fcntl(fd,f_setlkw,&lock_info)) == -1 && errno == EINTR ) { // reconstruct lock_info: lock_info.l_type = F_UNLCK; lock_info.l_whence = SEEK_SET; lock_info.l_start = lock_info.l_len = 0; if (status == -1) perror("exit_critical"); return status; Déverrouiller int main (int argc, char** argv) { char lock1name[256], lock2name[256]; snprintf(lock1name,255,"/tmp/lock-%d-1",getpid()); snprintf(lock2name,255,"/tmp/lock-%d-2",getpid()); int lock1 = open(lock1name,o_wronly O_CREAT O_APPEND,S_IRWXU S_IRWXG S_IRWXO); int lock2 = open(lock2name,o_wronly O_CREAT O_APPEND,S_IRWXU S_IRWXG S_IRWXO); if (lock1 == -1 lock2 == -1) { perror("cannot create locks"); return 1; // Do something involving two critical regions... // clean up close(lock1); close(lock2); Ou, tout à la main unlink(lock1name); unlink(lock2name); Les locks POSIX sont donnés par la fonction lockf. Par contre, le lock n est pas bloquant : si on veut mettre un lock sur un fichier alors qu il est déjà verrouillé, on ne se fait pas bloquer. Ca évite les deadlock, et on est censé faire le test nous-même On a une dernière variante qui est flock : ce sont des locks conseillés, que le programme peut choisir de prendre en compte ou non. On les évite généralement en faveur des locks POSIX Notons que les flock sont hérités par les processus fils, mais pas au travers de execv. int fd = open("aaa", O_RDWR); if (fork() == 0) { lockf(fd,f_lock,0); printf("child locked \"aaa\"\n"); else { sleep(1); write(fd,"stuff",4); printf("parent wrote into \"aaa\"\n");

14 VIII. Threads On a vu comment avoir de la concurrence en créant de nouveaux processus. On peut aussi le faire en utilisant des threads (appelés light processes) ; ceux-ci partagent les variables globales et la descriptor table du processus dans lequel ils tournent, donc si un thread ouvre un descriptor les autres pourront y avoir accès, et de même s il ferme un descriptor il en prive les autres. Les threads Linux suivent la norme Posix , exécutent de façon concurrente et préemptive (ils ne peuvent donc pas bloquer le CPU). On inclus la librairie <pthread.h> et il faut préciser le lien lorsqu on compile avec g++ par l option lthread. Les threads sont efficaces, car le context switching est moins coûteux qu entre les processus ; la communication en utilisant la mémoire partagée est aussi un plus, et l implémentation des critical sections ne demandent pas d utiliser des verrous sur des fichiers. En revanche, il peut y avoir des problèmes d interférences lorsque plusieurs threads veulent la même variable globale. Si un thread fait une opération illégale, le processus complet est tué, y compris les autres threads qui se comportaient gentiment. Certains appels peuvent ne pas être thread safe (on a vu strerror) ; dans le doute, on utilise une critical section. Ceci étant, il ne faut pas abuser des critical sections : ils font décroître le temps de réponse, et un read dans une critical section peut facilement engendrer un deadlock du serveur. Une condition variable est faite d un mutex et d une condition. Des threads ont besoin d acquérir une zone (mutex), et une fois qu on l a il faut qu une certaine condition soit remplie. Pendant qu il attend pour cette condition, le thread relâche le mutex pour que d autres threads puissent avoir l occasion de satisfaire. Quand on travaille avec des processus, on ne s inquiète que de l accès concurrent aux fichiers ; ici, les variables globales sont partagées donc il faut en général se soucier de toute ressource. On utilise des mutex pour fournir un accès exclusif à une donnée partagée, avec les fonctions définies ci-dessus. Les (counting) sémaphores sont pareil à des mutex, mais pour n accès à la ressource. Il faut inclure <semaphore.h>. Lorsqu on fait pthread_cancel pour tuer un thread, celui-ci peut ignorer, mourir immédiatement, ou attendre jusqu à atteindre un cancellation point. Seules l appel aux fonctions suivantes défini les cancellation point : pthread_join, pthread_cond_wait, pthread_cond_timedwait, pthread_testcancel, sem_wait, sigwait Quand la cancellation s effectue, le thread tué fait comme s il exécutait l appel pthread_exit(pthread_cancel). Tous les appels systèmes pouvant bloquer sont aussi des cancellation points (d après le standard POSIX). La cancellation est envoyée par signal, interrompant tous les appels systèmes bloquants (retour avec EINTR) donc pthread_cancel après un appel système est sûr et aura l effet désiré.