Network Programming in C

Dimension: px
Commencer à balayer dès la page:

Download "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 : 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é.

Fabien Garcia ELR. int domain, /* Domaine de la socket */ int type, /* Type de socket */ int protocol); /* Protocole utilisé */

Fabien Garcia ELR. int domain, /* Domaine de la socket */ int type, /* Type de socket */ int protocol); /* Protocole utilisé */ API Socket Fabien Garcia ELR 1 int socket( int domain, /* Domaine de la socket */ int type, /* Type de socket */ int protocol); /* Protocole utilisé */ Création d un TSAP Crée une socket du type demandé

Plus en détail

Systèmes d exploitation

Systèmes d exploitation Cours no. 7 Jean-Sébastien Coron Université du Luxembourg coron@clipper.ens.fr Communications inter-processus Méthodes de communications inter-processus: Les signaux. Pas de données transmises. Les tuyaux:

Plus en détail

Programmation des sockets de Berkeley en C

Programmation des sockets de Berkeley en C Programmation des sockets de Berkeley en C 26 février 2012 IUT de Lyon - La Doua - Département Informatique 1 Introduction aux sockets Généralités Description 2 Programmation des sockets en C Gestion de

Plus en détail

L3 informatique TP Réseaux n o 4 : Programmation client-serveur en C

L3 informatique TP Réseaux n o 4 : Programmation client-serveur en C L3 informatique TP Réseaux n o 4 : Programmation client-serveur en C Sovanna Tan Octobre 2009 1/27 Sovanna Tan L3 informatique TP Réseaux n o 4 : Programmation client Plan 1 Les fonctions pour les sockets

Plus en détail

TD 4 - Sockets et Client / Serveur

TD 4 - Sockets et Client / Serveur TD 4 - Sockets et Client / Serveur Exercice 1 Serveur d echo Écrire en Java un serveur TCP d echo (fichier echoserver.java) qui retourne aux clients ce que ces derniers lui émettent. Dans cette première

Plus en détail

Programmation système de commandes en C

Programmation système de commandes en C Programmation système de commandes en C Cours de Programmation système Tuyêt Trâm DANG NGOC Université de Cergy-Pontoise 2012 2013 Tuyêt Trâm DANG NGOC Programmation système de commandes

Plus en détail

Réseau et Communication Notes de Cours/TD/TP autorisées; autres documents, calculettes, ordinateurs interdits.

Réseau et Communication Notes de Cours/TD/TP autorisées; autres documents, calculettes, ordinateurs interdits. Département d Informatique Faculté des Sciences de Luminy Réseau et Communication Lundi 9 mai 2011 Durée 3h Licence MI, UE INF15, E. Thiel Notes de Cours/TD/TP autorisées; autres documents, calculettes,

Plus en détail

Les Sockets/1. samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Les Sockets/1. samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) - Les Sockets/1 La version Berkeley 4.2 d Unix a été la première à inclure TCP/IP dans le noyau du système d exploitation et à proposer une interface de programmation de ces protocoles : les sockets. Les

Plus en détail

Traducteur mot à mot

Traducteur mot à mot Traducteur mot à mot CORRECTION Ce document, ainsi que le programme C et un exemple de programme trad-fr-us, peut être trouvé en ligne à l'addresse suivante : http ://www.lifl.fr/hauspie/hauspie/teaching.

Plus en détail

Interface des sockets

Interface des sockets Interface des sockets IUT Bordeaux I 08/12/2008 Interface des Sockets 1 A quoi servent les sockets? Applications client/serveur Transfert de fichiers, Connexion à distance, Courrier électronique, Groupe

Plus en détail

Programmations des Sockets. Benmoussa Yahia Université M hamed Bougara de Boumerdès Yahia.benm@gmail.com

Programmations des Sockets. Benmoussa Yahia Université M hamed Bougara de Boumerdès Yahia.benm@gmail.com Programmations des Sockets Benmoussa Yahia Université M hamed Bougara de Boumerdès Yahia.benm@gmail.com Objectifs Différencier entre les modes de transport orientés connexion et non-orientés connexion

Plus en détail

M3101 Principes des systèmes d exploitation. Les sockets

M3101 Principes des systèmes d exploitation. Les sockets M3101 Principes des systèmes d exploitation Les sockets IUT d Orsay DUT Informatique 2015 / 2016 Les sockets Une interface de communication bidirectionnelle entre les processus résidant dans le même système

Plus en détail

Programmation client/serveur

Programmation client/serveur Les sockets Programmation client/serveur Le serveur est la machine à l écoute des requêtes des clients auxquelles il doit répondre. Il exécute une boucle infinie qui attend une requête d un client. Il

Plus en détail

I. Moniteur POP3 de emails en C

I. Moniteur POP3 de emails en C Année universitaire 2014/2015 Site : Luminy St-Charles St-Jérôme Cht-Gombert Aix-Montperrin Aubagne-SATIS Sujet de : 1 er semestre 2ème semestre Session 2 Examen de : L3 Code du module : SIN5U3 Calculatrices

Plus en détail

TP 3 Mini client/serveur ftp

TP 3 Mini client/serveur ftp TP 3 Mini client/serveur ftp 1 But Le but du TP est de réaliser un client et un serveur de transfert de fichiers à distance. Pour transférer un fichier (par exemple obtenir un fichier depuis une machine

Plus en détail

Langage C et programmation système

Langage C et programmation système Langage C et programmation système DUT Informatique Villetaneuse Module : Système d'exploitation christophe.cerin@iutv.univ-paris13.fr Variables d environnement Votre problème : vous développez une application

Plus en détail

Sujet Projets 2 nd Semestre

Sujet Projets 2 nd Semestre Sujet Projets 2 nd Semestre Seuls les appels systèmes vus en cours sont autorisés. L usage d autres fonctions doit impérativement être validé par l enseignant. La date d ouverture pour l assignation de

Plus en détail

La programmation client-serveur

La programmation client-serveur La programmation client-serveur Olivier Aubert 1/32 Sources http://www.info.uqam.ca/~obaid/inf4481/a01/plan.htm http://bat710.univ-lyon1.fr/~exco/cours/clientserveur.html man 2 socket http://www.developerweb.net/sock-faq/

Plus en détail

Projet du cours d ARCHITECTURE Gestion distribué d un parking

Projet du cours d ARCHITECTURE Gestion distribué d un parking Projet du cours d ARCHITECTURE Gestion distribué d un parking 3 GI, INSA de Lyon Janvier 2004 1 Objectifs du projet Ce projet a pour but d apprendre à manipuler une application multitâche où les différentes

Plus en détail

Cours 6 : Tubes anonymes et nommés

Cours 6 : Tubes anonymes et nommés Cours 6 : Tubes anonymes et nommés Mécanisme de communications du système de fichiers I-node associé. Type de fichier: S_IFIFO. Accès au travers des primitives read et write. Les tubes sont unidirectionnels

Plus en détail

GESTION DES FICHIERS C/UNIX

GESTION DES FICHIERS C/UNIX Licence IG Page 1 sur 6 GESTION DES FICHIERS C/UNIX Introduction Deux modes d appel - Par la bibliothèque standard C (appel de haut niveau) - Par appels système (bas niveau) Nécessite les includes suivant

Plus en détail

Rapport de TP sur le mini-serveur HTTP. Maxime Chambreuil - Sébastien Le Digabel

Rapport de TP sur le mini-serveur HTTP. Maxime Chambreuil - Sébastien Le Digabel Rapport de TP sur le mini-serveur HTTP Maxime Chambreuil - Sébastien Le Digabel 16 janvier 2003 Table des matières 1 Détails sur nos travaux 2 1.1 But du TP............................. 2 1.2 La fonction

Plus en détail

Architecture Client/Serveur. andreu@lirmm.fr 1

Architecture Client/Serveur. andreu@lirmm.fr 1 Architecture Client/Serveur andreu@lirmm.fr 1 Qu'est-ce qu'un serveur? un «logiciel serveur» offre un service sur le réseau, le «serveur» est la machine sur laquelle s'exécute le logiciel serveur, le serveur

Plus en détail

Département de génie informatique et génie logiciel

Département de génie informatique et génie logiciel INF2610 Chapitre 2 : Processus Département de génie informatique et génie logiciel Hiver 2014 Chapitre 2 - Processus Qu est ce qu un processus? États d un processus Hiérarchie des processus Processus UNIX-Linux

Plus en détail

Le prototype de la fonction main()

Le prototype de la fonction main() Le prototype de la fonction main() 1. Introduction...1 2. Paramètres et type de retour de la fonction main()...1 3. Exemple 1...2 4. La fonction exit() du C...2 5. Détecter le code de retour d un programme

Plus en détail

Systèmes répartis : les Remote Procedure Calls p.1/25

Systèmes répartis : les Remote Procedure Calls p.1/25 Systèmes répartis : les Remote Procedure Calls Fabrice Rossi http://apiacoa.org/contact.html. Université Paris-IX Dauphine Systèmes répartis : les Remote Procedure Calls p.1/25 Les Remote Procedure Calls

Plus en détail

TP Développement Réseau n 2 : Socket UDP

TP Développement Réseau n 2 : Socket UDP TP Développement Réseau n 2 : Socket UDP 2012 tv - v.1.0 Sommaire L interface socket 2 Pré-requis............................................... 2 Définition...............................................

Plus en détail

Mode client - serveur Généralités dur les différents modes de communications

Mode client - serveur Généralités dur les différents modes de communications Mode client - serveur Généralités dur les différents modes de communications» Socket» Stream» RPC Les Sockets source : Réseaux locaux et Internet (Laurent Toutain)[HERMES] Mécanisme d'interface de programmation»

Plus en détail

Travaux pratiques. Protocoles de la couche transport et de la couche applications

Travaux pratiques. Protocoles de la couche transport et de la couche applications Travaux pratiques Protocoles de la couche transport et de la couche applications Objectif Ce laboratoire se veut une introduction aux protocoles de la couche transport et de la couche application du modèle

Plus en détail

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Dirigés n o 3 : Sockets Stream

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Dirigés n o 3 : Sockets Stream iut ORSAY DUT Informatique Département Informatique 2009 / 2010 Travaux Dirigés n o 3 : Sockets Stream Objectifs : comprendre les principes et les mécanismes de communication par sockets stream, être capable

Plus en détail

1.1 Remote Procedure Call (RPC)

1.1 Remote Procedure Call (RPC) 1.1 Remote Procedure Call (RPC) Le modèle Client-Serveur est un modèle simple à utiliser pour la structuration des systèmes répartis. Mais ce modèle s appuie sur des communications de type entrée/sortie

Plus en détail

TP N 2. Programmation des sockets

TP N 2. Programmation des sockets TP N 2. Programmation des sockets Exercice 1 : Troubleshooting de TCP & UDP - Que contient le fichier /etc/services? - Quels ports sont utilisés par les protocoles ftp, telnet, smtp, http? - Quel est le

Plus en détail

Cours de Réseau et communication Unix n 4

Cours de Réseau et communication Unix n 4 Cours de Réseau et communication Unix n 4 Edouard THIEL Faculté des Sciences Université d Aix-Marseille (AMU) Septembre 2014 Les transparents de ce cours sont téléchargeables ici : http://pageperso.lif.univ-mrs.fr/~edouard.thiel/ens/rezo/

Plus en détail

Cours Programmation Système

Cours Programmation Système Cours Programmation Système Filière SMI Semestre S6 El Mostafa DAOUDI Département de Mathématiques et d Informatique, Faculté des Sciences Université Mohammed Premier Oujda m.daoudi@fso.ump.ma Février

Plus en détail

Programmation Multithread

Programmation Multithread Programmation Multithread Partie 3 Professeur : Bruno De Kelper Département Génie Électrique Synchronisation Les Threads partagent les ressources Besoin de synchroniser pour: - Garder la cohérence des

Plus en détail

Cours de Réseau et communication Unix n 7

Cours de Réseau et communication Unix n 7 Cours de Réseau et communication Unix n 7 Edouard THIEL Faculté des Sciences Université d Aix-Marseille (AMU) Septembre 2014 Les transparents de ce cours sont téléchargeables ici : http://pageperso.lif.univ-mrs.fr/~edouard.thiel/ens/rezo/

Plus en détail

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Pratiques n o 5 : Sockets Stream

DUT Informatique Module Système S4 C Département Informatique 2009 / 2010. Travaux Pratiques n o 5 : Sockets Stream iut ORSAY DUT Informatique Département Informatique 2009 / 2010 Travaux Pratiques n o 5 : Sockets Stream Nom(s) : Groupe : Date : Objectifs : manipuler les primitives relatives à la communication par sockets

Plus en détail

Communication entre processus avec des tuyaux Fils Java. Partie A La communication entre processus avec tuyaux

Communication entre processus avec des tuyaux Fils Java. Partie A La communication entre processus avec tuyaux Systèmes d exploitation CSI3531 Labo 2 Communication entre processus avec des tuyaux Fils Java Partie A La communication entre processus avec tuyaux Objectif : Explorer le IPC avec les tuyaux UNIX/Linux

Plus en détail

Examen. Les processus. Examen : systèmes d exploitation L3, parcours informatique, 2004-2005

Examen. Les processus. Examen : systèmes d exploitation L3, parcours informatique, 2004-2005 Mercredi 5 janvier 2005 Durée : 3 heures Documents autorisés Examen : systèmes d exploitation L3, parcours informatique, 2004-2005 Corrigé préliminaire et partiel. Examen Les valeurs de retour des primitives

Plus en détail

UE NSY 103 Programmation Système. EXAMEN 2007-2008 Session Septembre. documents autorisés : Non. Session 2008 NSY 103 (S. Cherrier) Page 1 / 9

UE NSY 103 Programmation Système. EXAMEN 2007-2008 Session Septembre. documents autorisés : Non. Session 2008 NSY 103 (S. Cherrier) Page 1 / 9 UE NSY 103 Programmation Système EXAMEN 2007-2008 Session Septembre documents autorisés : Non Session 2008 NSY 103 (S. Cherrier) Page 1 / 9 Une sonde WEB L'équipe de développement dans laquelle vous travaillez

Plus en détail

Première étape : Le modèle client/serveur avec le protocole TCP (client unique)

Première étape : Le modèle client/serveur avec le protocole TCP (client unique) École de technologie supérieure Responsable du cours : Hassan Zeino Département de génie logiciel et des TI Chargés de laboratoire : Fatna Belqasmi (A-3326) Session : Automne 2010 LOG610 - RÉSEAUX DE TELECOMMUNICATION

Plus en détail

IMPLEMENTATION DE TCP/UDP LES SOCKETS

IMPLEMENTATION DE TCP/UDP LES SOCKETS IMPLEMENTATION DE TCP/UDP LES Les sockets sont le mécanisme fondamental de communications sous UNIX. Ils permettent des communications au sein du même système comme vers l'extérieur. La création d'une

Plus en détail

Cours. Majeure Informatique Ecole Polytechnique. Applications client/serveur

Cours. Majeure Informatique Ecole Polytechnique. Applications client/serveur Cours Système et Réseaux Majeure Informatique Ecole Polytechnique 7 Applications client/serveur François Bourdoncle Francois.Bourdoncle@ensmp.fr http://www.ensmp.fr/ bourdonc/ 1 Plan Les sockets d Unix

Plus en détail

Communication dans le domaine Internet sous Unix à l aide de sockets

Communication dans le domaine Internet sous Unix à l aide de sockets Communication dans le domaine Internet sous Unix à l aide de sockets 1. Introduction Une socket est un point de communication par lequel un processus peut émettre ou recevoir des informations à partir

Plus en détail

Programmation Réseau

Programmation Réseau TC 3TC PRS Programmation Réseau Département Télécommunications Services & Usages Programmation Réseau - Slides gracieusement mis à disposition par Fabrice Valois - Pourquoi programmation réseau? - Le concept

Plus en détail

Plan de la séance. Ports de communication physiques et virtuels. Adressage Internet. Protocoles de communication. Prise de communication : définition

Plan de la séance. Ports de communication physiques et virtuels. Adressage Internet. Protocoles de communication. Prise de communication : définition 1 Plan de la séance Ports de communication physiques et virtuels Adressage Internet Protocoles de communication Prise de communication : définition Les trois caractéristiques d une prise Les primitives

Plus en détail

IPv6. Internet Control Message Protocol ICMPv6. Objectif: Comparer ICMPv4 avec ICMPv6

IPv6. Internet Control Message Protocol ICMPv6. Objectif: Comparer ICMPv4 avec ICMPv6 IPv6 Internet Control Message Protocol ICMPv6 Objectif: Comparer ICMPv4 avec ICMPv6 v.1b IPv6 Théorie et Pratique & Microsoft Introduction to IPv6 1 ICMPv6 (RFC 2463) Trois fonctions déjà présentes en

Plus en détail

DynDNS. Qu est-ce que le DynDNS?

DynDNS. Qu est-ce que le DynDNS? DynDNS. Qu est-ce que le DynDNS? Le DynDNS (Dynamic Domain Name Server) sert à attribuer un nom de domaine à une adresse ip dynamique. Chaque ordinateur utilise une adresse ip pour communiquer sur le réseau.

Plus en détail

Documentation technique sur l utilisation des Sockets

Documentation technique sur l utilisation des Sockets Documentation technique sur l utilisation des Sockets Pascal Sicard Table des matières 1 INTRODUCTION 3 2 ENVIRONNEMENT DE PROGRAMMATION 3 3 PARAMETRES UTILISÉS DANS LES PROCEDURES 3 3.1 Le domaine d utilisation

Plus en détail

Compte rendu TP No1 : «Analyse statique de programme»

Compte rendu TP No1 : «Analyse statique de programme» LO20 : Vérification, validation et sûreté de fonctionnement http://www.genie logiciel.utc.fr/lo20/ Compte rendu TP No1 : «Analyse statique de programme» Le premier TP concerne l'analyse statique de programme.

Plus en détail

Systèmes d'exploitation

Systèmes d'exploitation Université de Nice-Sophia Antipolis Examen L2 Info 20092010 Systèmes d'exploitation Nom : Prénom : Durée : 2h Nombre d'intercalaires : Note : NB : Vos réponses aux questions doivent être brèves et synthétiques.

Plus en détail

TRAVAUX PRATIQUES Programmation Système Langage C / Système UNIX. 2 e année Génie Informatique

TRAVAUX PRATIQUES Programmation Système Langage C / Système UNIX. 2 e année Génie Informatique Communications entre Processus Communication par tubes. TRAVAUX PRATIQUES Programmation Système Langage C / Système UNIX. 2 e année Génie Informatique Exemple 1: On a deux processus Père/Fils. Le père

Plus en détail

AMESD-Puma2010-EFTS- Configuration-update-TEN (en-fr)

AMESD-Puma2010-EFTS- Configuration-update-TEN (en-fr) AMESD-Puma2010-EFTS- Configuration-update-TEN (en-fr) Doc.No. : EUM/OPS/TEN/13/706466 Issue : v3 Date : 7 May 2014 WBS : EUMETSAT Eumetsat-Allee 1, D-64295 Darmstadt, Germany Tel: +49 6151 807-7 Fax: +49

Plus en détail

Exemple : Lecture d un registre, à l offset 4, sur l équipement d ID 9, qui renvoie la valeur 5 :

Exemple : Lecture d un registre, à l offset 4, sur l équipement d ID 9, qui renvoie la valeur 5 : 1 Ethernet TCP/IP Protocole Modbus TCP 2 Ethernet TCP/IP - Protocole Modbus TCP Codage des Données Type de représentation des adresse et données utilisé par Modbus : big-endian, soit :lorsqu une quantité

Plus en détail

Le langage C. Séance n 4

Le langage C. Séance n 4 Université Paris-Sud 11 Institut de Formation des Ingénieurs Remise à niveau INFORMATIQUE Année 2007-2008 Travaux pratiques d informatique Le langage C Séance n 4 But : Vous devez maîtriser à la fin de

Plus en détail

Les réseaux : Principes de fonctionnement d Internet

Les réseaux : Principes de fonctionnement d Internet Les réseaux : Principes de fonctionnement d Internet Table des matières 1. Le modèle TCP/IP... 2 2. Couche 1 ou couche physique... 3 3. Couche 2 ou couche liaison ou couche lien... 4 4. Couche 3 ou couche

Plus en détail

Protocoles «Application»

Protocoles «Application» Protocoles «Application» POP3 (rappel) TFTP BOOTP DHCP 03/10/2007 Applications TCP/IP 1 Le protocole TFTP Trivial File Transfert Protocol Utilise UDP RFC 783 et RFC 1350 Permet uniquement le transfert

Plus en détail

3IS - Système d'exploitation linux - Programmation système

3IS - Système d'exploitation linux - Programmation système 3IS - Système d'exploitation linux - Programmation système 2010 David Picard Contributions de : Arnaud Revel, Mickaël Maillard picard@ensea.fr Environnement Les programmes peuvent être exécutés dans des

Plus en détail

Sniffing et analyse de paquets

Sniffing et analyse de paquets 1 Outils Sniffing et analyse de paquets Analyser : http://analyzer.polito.it/install/default.htm RASPPPoE : http://user.cs.tu-berlin.de/~normanb/ 2 Prérequis DSLAM (Digital Subscriber Line Multiplexer)

Plus en détail

TP N o 2 - Utilisateurs et droits

TP N o 2 - Utilisateurs et droits IUT de Villetaneuse E. Viennet GTR 2ème année Introduction au Système UNIX 22/09/03 TP N o 2 - Utilisateurs et droits Vous rédigerez un compte rendu, sur lequel vous indiquerez la réponse à chaque question,

Plus en détail

How To connect to TonVPN Max / Comment se connecter à TonVPN Max

How To connect to TonVPN Max / Comment se connecter à TonVPN Max How To connect to TonVPN Max / Comment se connecter à TonVPN Max Note : you need to run all those steps as an administrator or somebody having admin rights on the system. (most of the time root, or using

Plus en détail

Remote Control Library Librairie Remote Control

Remote Control Library Librairie Remote Control Remote Control Library Librairie Remote Control Installation File, Fichier : REMOTEVPU.EXE After installation Après installation In the toolbox : Dans la boite à outils : Files Added, Files Ajoutés : C:\API32\Modules\

Plus en détail

LE RPV DE NIVEAU RÉSEAU AVEC TINC

LE RPV DE NIVEAU RÉSEAU AVEC TINC LE RPV DE NIVEAU RÉSEAU AVEC TINC L entreprise Ilog est une petite entreprise de services informatiques située à La Défense. Les chefs de projet de l entreprise sont souvent en déplacement à travers toute

Plus en détail

TP4 : Firewall IPTABLES

TP4 : Firewall IPTABLES Module Sécurité TP4 : Firewall IPTABLES Ala Rezmerita François Lesueur Le TP donnera lieu à la rédaction d un petit fichier texte contenant votre nom, les réponses aux questions ainsi que d éventuels résultats

Plus en détail

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007

Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 Ch4 Interconnexion des postes dans un Lan Ethernet : protocoles des couches 3 à 7 du modèle OSI Dernière maj : lundi 2 avril 2007 I. RAPPEL : ADRESSAGE PHYSIQUE : (OSI 2)... 1 A. L ADRESSAGE DANS UN RESEAU

Plus en détail

Formation Unix/Linux (3) Le Shell: gestion des processus, redirection d entrée/sortie

Formation Unix/Linux (3) Le Shell: gestion des processus, redirection d entrée/sortie Formation Unix/Linux (3) Le Shell: gestion des processus, redirection d entrée/sortie Olivier BOEBION Mars 2004 1 Définition Un programme se compose d un ou plusieurs fichiers composés d instructions.

Plus en détail

Dr. M.W. Youssef Systèmes d exploitation Avancées 1ING ISI - 2009

Dr. M.W. Youssef Systèmes d exploitation Avancées 1ING ISI - 2009 Institut Supérieur d Informatique Chapitre 02 Synchronisation des processus Dr. Mohamed-Wassim YOUSSEF 2009 [www.wassimyoussef.info] Systèmes d exploitation avancées 1 ING ISI 1 ére année Ingénieur en

Plus en détail

Réseau et Communication Notes de Cours/TD/TP autorisées; autres documents, calculettes, ordinateurs interdits.

Réseau et Communication Notes de Cours/TD/TP autorisées; autres documents, calculettes, ordinateurs interdits. Département d Informatique Faculté des Sciences de Luminy Réseau et Communication Vendredi 11 mai 2012 Durée 3h Licence MI, UE INF15, E. Thiel Notes de Cours/TD/TP autorisées; autres documents, calculettes,

Plus en détail

Sujet d examen 1. Pratique du C. Novembre 2009

Sujet d examen 1. Pratique du C. Novembre 2009 Durée 1 h 30 Documents autorisés Sujet d examen 1 Pratique du C Novembre 2009 Introduction Écrivez lisiblement et n hésitez pas à commenter votre code en langage C. Vous ne pouvez utiliser que les fonctions

Plus en détail

Introduction au langage C - types et variables

Introduction au langage C - types et variables Chapitre 2 Introduction au langage C - types et variables 1 Le Langage C Le langage C est un langage de bas niveau dans le sens où il permet l accès à des données que manipulent les ordinateurs (bits,

Plus en détail

Les protocoles UDP et TCP

Les protocoles UDP et TCP 3 Les protocoles UDP et TCP TCP comme UDP s exécute au-dessus d IP et se fonde sur les services fournis par ce dernier. TCP (Transport Control Protocol) assure un service de transmission de données fiable

Plus en détail

Programmation système I Les entrées/sorties

Programmation système I Les entrées/sorties Programmation système I Les entrées/sorties DUT 1 re année Université de Marne La vallée Les entrées-sorties : E/O Entrées/Sorties : Opérations d échanges d informations dans un système informatique. Les

Plus en détail

Instructions Mozilla Thunderbird Page 1

Instructions Mozilla Thunderbird Page 1 Instructions Mozilla Thunderbird Page 1 Instructions Mozilla Thunderbird Ce manuel est écrit pour les utilisateurs qui font déjà configurer un compte de courrier électronique dans Mozilla Thunderbird et

Plus en détail

Langages et concepts de programmation

Langages et concepts de programmation Langages et concepts de programmation Séances 3 et 4 Tri d un fichier de voitures Une correction possible 1 Le sujet On dispose d un fichier contenant des informations sur des voitures d occasion : le

Plus en détail

Programmation par sockets-java

Programmation par sockets-java 2A-SI 3 Prog. réseau et systèmes distribués 3.1 - Programmation par sockets-java Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Support de cours élaboré avec l aide de l

Plus en détail

Introduction. UDP et IP UDP

Introduction. UDP et IP UDP Introduction Protocoles TCP et UDP M. Berthet. Les illustrations sont tirées de l ouvrage de Guy Pujolle, Cours réseaux et Télécom TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) assurent

Plus en détail

Internet. PC / Réseau

Internet. PC / Réseau Internet PC / Réseau Objectif Cette présentation reprend les notions de base : Objectif, environnement de l Internet Connexion, fournisseurs d accès Services Web, consultation, protocoles Modèle en couches,

Plus en détail

Couche transport TCP

Couche transport TCP Couche transport TCP Sébastien Jean IUT de Valence Département Informatique v3.1, 30 avril 2012 TCP, en bref Généralités TCP? TCP (Transmission Control Protocol, RFC 793) fournit un service de transfert

Plus en détail

Systèmes d exploitation II Chapitre 2 : Gestion des processus. www.achrafothman.net

Systèmes d exploitation II Chapitre 2 : Gestion des processus. www.achrafothman.net Systèmes d exploitation II Chapitre 2 : Gestion des processus www.achrafothman.net 1 Processus Concept de Processus Ordonnancement de Processus Opérations sur les Processus Processus Coopératifs Communication

Plus en détail

Travaux pratiques 3.4.3 : Services et protocoles de messagerie

Travaux pratiques 3.4.3 : Services et protocoles de messagerie Schéma de topologie Tableau d adressage Périphérique Interface Adresse IP R1-ISP Masque de sous-réseau Passerelle par défaut S0/0/0 10.10.10.6 255.255.255.252 S/O Fa0/0 192.168.254.253 255.255.255.0 S/O

Plus en détail

Introduction aux réseaux

Introduction aux réseaux Introduction aux réseaux Présentation de TCP/IP et de la programmation. Julien OLIVAIN julien.olivain@lsv.ens-cachan.fr> LSV - ENS de Cachan Plan Introduction générale. Protocoles de communication. Organisation

Plus en détail

Introduction. Licence MASS L3 Inf f3

Introduction. Licence MASS L3 Inf f3 Le modèle client serveur Introduction Licence MASS L3 Inf f3 Encapsulation : rappel Données Données Application En-tête En-tête Transport UDP Données TCP Données Paquet UDP Segment TCP En-tête IP Données

Plus en détail

Communications et synchronisations. Système L3, 2014-2015 1/21

Communications et synchronisations. Système L3, 2014-2015 1/21 Communications et synchronisations Système L3, 2014-2015 1/21 Le problème des philosophes (Dijkstra 1965) Cinq philosophes sont assis autour d une table ronde Chaque philosophe a devant lui un plat de

Plus en détail

INVENTAIRE INFORMATISE D'UN PARC INFORMATIQUE EN RESEAU. Client UNIX

INVENTAIRE INFORMATISE D'UN PARC INFORMATIQUE EN RESEAU. Client UNIX INVENTAIRE INFORMATISE D'UN PARC INFORMATIQUE EN RESEAU Client UNIX Session 2006 2007 Lycee de formation: Lycee Jean Lurcat Page1/17 SOMMAIRE 1. Presentation du projet 2. Description 3. Analyse UML 1.

Plus en détail

Socket Programming. (Dr. ) Sébastien Varrette

Socket Programming. (Dr. ) Sébastien Varrette Socket Programming (Dr. ) Sébastien Varrette Network Model Modèle OSI Modèle TCP/IP TYPES DE COUCHES Service Réseau Applicative Réseau Matérielle Application Presentation Session Transport Réseau Liaison

Plus en détail

Programmation sockets

Programmation sockets Programmation sockets Juliusz Chroboczek 13 octobre 2014 Table des matières 1 Fonctionnalités indépendantes du protocole de couche transport 2 1.1 Structures.......................................... 2

Plus en détail

Travaux Pratiques Réseaux Programmation réseau - Sockets, Modèle Client-serveur Septembre 2007. Eléments de programmation avec les sockets

Travaux Pratiques Réseaux Programmation réseau - Sockets, Modèle Client-serveur Septembre 2007. Eléments de programmation avec les sockets Master INFORMATIQUE / MIAGE Réseaux Faculté des Sciences - Université de Nantes 2007/2008 Travaux Pratiques Réseaux Programmation réseau - Sockets, Modèle Client-serveur Septembre 2007 Eléments de programmation

Plus en détail

UNIX COMMUNICATION INTERNE ENTRE PROCESSUS. C. Crochepeyre Cnam - Diapason Unix: communications internes 1

UNIX COMMUNICATION INTERNE ENTRE PROCESSUS. C. Crochepeyre Cnam - Diapason Unix: communications internes 1 UNIX COMMUNICATION INTERNE ENTRE PROCESSUS C. Crochepeyre Cnam - Diapason Unix: communications internes 1 1. GÉNÉRALITÉS Communications internes: entre processus sur une même machine: exec() fichiers moyens

Plus en détail

Protocoles «Application»

Protocoles «Application» Protocoles «Application» POP3 (rappel) TFTP BOOTP DHCP Applications TCP/IP 1 Application POP3 Documentation Post Office Protocol 3, RFC 1460 (Request For Comments) But Protocole TCP pour la réception des

Plus en détail

.: TP Programmation Réseaux : Couche Application :.

.: TP Programmation Réseaux : Couche Application :. .: TP Programmation Réseaux : Couche Application :. Copyright 2003 tv Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation

Plus en détail

Linux Principes et Programmation

Linux Principes et Programmation Linux Principes et Programmation 5. Programmation réseau Socket, RPC CNAM NSY103 2009/2010 Yann GAUTHERON Extraits : http://fr.wikipedia.org/, LINUX Programmation système et réseau (Joëlle DELACROIX) http://www.cnam.fr/

Plus en détail

Cours de Systèmes des Réseaux p.1/40. Master IST partie Linux

Cours de Systèmes des Réseaux p.1/40. Master IST partie Linux Cours de Systèmes des Réseaux Master IST partie Linux T. Hérault herault@lri.fr Université Paris XI Cours de Systèmes des Réseaux p.1/40 Sockets et Réseau Sockets et Réseaux Cours de Systèmes des Réseaux

Plus en détail

1 Programmation Client/Serveur basée sur TCP/IP

1 Programmation Client/Serveur basée sur TCP/IP Outils Informatique pour l ingénieur TD 1 Réseau et Web IP, Client/serveur 1 Programmation Client/Serveur basée sur TCP/IP 1.1 Buts de cette réalisation Ce TP sur la programmation client/serveur a pour

Plus en détail

LA PERSONNE SPÉCIALE

LA PERSONNE SPÉCIALE LA PERSONNE SPÉCIALE These first questions give us some basic information about you. They set the stage and help us to begin to get to know you. 1. Comment tu t appelles? What is your name? Je m appelle

Plus en détail

Interfaçage de programmation. c Olivier Caron

Interfaçage de programmation. c Olivier Caron Interfaçage de programmation 1 Le SGBD est-il suffisant? (1/2) Les pour : La puissance du langage de requêtes. 1 Le SGBD est-il suffisant? (1/2) Les pour : La puissance du langage de requêtes. L aspect

Plus en détail

WEB page builder and server for SCADA applications usable from a WEB navigator

WEB page builder and server for SCADA applications usable from a WEB navigator Générateur de pages WEB et serveur pour supervision accessible à partir d un navigateur WEB WEB page builder and server for SCADA applications usable from a WEB navigator opyright 2007 IRAI Manual Manuel

Plus en détail

1. Fonctionnement de l Internet 2. Protocoles applicatifs 3. Programmation réseau

1. Fonctionnement de l Internet 2. Protocoles applicatifs 3. Programmation réseau 1. Fonctionnement de l Internet 2. Protocoles applicatifs 3. Programmation réseau Fonctionnement de l Internet Fonctionnement de l Internet Basé sur une architecture TCP/IP du nom des deux principaux protocoles

Plus en détail

Architecture client/serveur

Architecture client/serveur Architecture client/serveur Table des matières 1. Principe du client/serveur...2 2. Communication client/serveur...3 2.1. Avantages...3 2.2. Inconvénients...3 3. HTTP (HyperText Transfer Protocol)...3

Plus en détail

Accès au support technique produits et licences par le portail client MGL de M2Msoft.com. Version 2010. Manuel Utilisateur

Accès au support technique produits et licences par le portail client MGL de M2Msoft.com. Version 2010. Manuel Utilisateur Accès au support technique produits et licences par le portail client MGL de M2Msoft.com Version 2010 Manuel Utilisateur Access to M2Msoft customer support portal, mgl.m2msoft.com, 2010 release. User manual

Plus en détail