TP 3 Mini client/serveur ftp

Transcription

1 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 distante), un client établit une connexion avec le serveur situé sur cette machine, transmet sa requête, attend l'accusé de réception, puis le contenu du fichier est échangé. La connexion est fermée à la fin du transfert (il ne peut donc y avoir qu'une seule requête par connexion). 2 Un mini-client/serveur ftp Le protocole de communication à implanter est le suivant (il ne s'agit pas du vrai protocole utilisé par ftp) : Serveur lancement du serveur (ouverture du port d'écoute) attend une demande de connexion accepte une demande de connexion délègue le traitement de la requête à un fils et se remet en attente de demande de connexion le fils : lit la requête et l'identifie envoie la réponse échange les données (si nécessaire). Client demande une connexion à un serveur construit une requête envoie la requête au serveur lit la réponse du serveur vérifie la réponse échange les données (si nécessaire). 2.1 Les requêtes du client Nous spécifions seulement quelques types de requêtes (4) pour simplifier notre cahier des charges : obtention d'un fichier (REQUETE_GET), le client demande à récupérer un fichier qui est sur le serveur, envoi d'un fichier (REQUETE_PUT), le client demande à déposer un fichier sur le serveur, suppression d'un fichier sur le serveur (REQUETE_DEL), le client demande qu'un fichier du serveur soit détruit (la requête seule est envoyée, il n'y a pas de transfert de contenu), affichage du contenu d'un répertoire du serveur (REQUETE_DIR), le client demande l'exécution de «ls -la» sur un chemin du serveur 2.2 Les réponses du serveur Après avoir lu la requête, le serveur renvoie un accusé de réception au client. Cet accusé peut être : positif (ANSWER_OK), négatif (ANSWER_ERROR) ou le serveur peut ne pas avoir compris la requête (ANSWER_UNKNOWN). En outre, le client peut ne jamais récupérer d'accusé, à cause d'une coupure de la connexion. Dans le cas d'un accusé négatif, le serveur fournit aussi un code d'erreur permettant d'identifier le problème (par exemple, l'échec peut provenir d'une tentative de récupération d'un fichier inconnu sur le serveur). Pour simplifier, le serveur renvoie la valeur de la variable errno suite à l'action qui a entraîné le rejet de la requête. 2.3 La requête Lors des cas de transfert de fichier (en envoi ou en récupération), il est nécessaire de connaître la taille du fichier transféré pour savoir si, lors d'un read détectant une fin de fichier (dû à la fermeture de la connexion), tout le contenu a bien été récupéré, ou si la connexion a été rompue trop tôt. Une requête est donc de la forme : #define REQUETE_PUT 1 #define REQUETE_GET 2 #define REQUETE_DEL 3 #define REQUETE_DIR 4 G. BENAY /2008

2 struct request { int kind; char path[maxpath]; int nbbytes; /* pour PUT seulement */ ; L'entier kind doit être REQUETE_PUT, REQUETE_GET, REQUETE_DEL ou REQUETE_DIR. La chaîne path contient le nom du fichier à écrire (put), lire (get), détruire (del) ou lister (dir). L'entier nbbytes contient la taille du fichier, lors d'un PUT seulement. 2.4 La réponse Une réponse contient donc l'accusé (ack). Si la réponse est positive (ack vaut ANSWER_OK) et que la requête était un GET, nbbytes contient la taille du fichier que le serveur va envoyer. Si la réponse est négative (ANSWER_ERROR), errnum contient le code de l'erreur (valeur de la variable errno). #define ANSWER_OK 0 #define ANSWER_UNKNOWN 1 /* requete inconnue */ #define ANSWER_ERROR 2 /* erreur lors du traitement */ struct answer { int ack; int nbbytes; /* pour GET seulement */ int errnum; /* significatif ssi!= 0 et ack == ANSWER_ERROR */ ; 2.5 Ligne de commande Le serveur miniftpd est démarré sans argument. Le port est prédéfinit et imposé ; on choisira un port libre. L'exécution d'un client peut prendre l'une des formes suivantes : miniftp hostname port get distfilename localfilename miniftp hostname port put localfilename distfilename miniftp hostname port del distfilename miniftp hostname port dir distpathname 2.6 Contrôle d'accès? Un serveur ftp doit théoriquement vérifier que les fichiers sont accédés avec les droits d'accès du client, et non pas ceux du serveur (d'où une phase initiale d'authentification avec mot de passe). Dans notre cas, le serveur accède aux fichiers sous l'uid de l'utilisateur qui a lancé ce serveur. Le client peut éventuellement être d'un autre uid, mais aucun contrôle n'est effectué. 2.7 Terminaison des processus fils Pour gérer une requête, le serveur «fork» un nouveau processus. Il est intéressant de récupérer le code de retour de ce processus fils, pour pouvoir détecter, par exemple, une terminaison anormale (et cela évite en outre l'apparition de processus zombies). Il existe deux mécanismes de synchronisation avec la terminaison (qui peuvent être combinés) : l'appel système wait attend indéfiniment la terminaison d'un processus fils ; le signal SIGCHLD est envoyé au père lors de la terminaison d'un processus fils. Par défaut, ce signal est ignoré. Rappel : lorsqu'un processus est bloqué par un appel système (par exemple read ou accept) et qu'un signal lui est envoyé, l'appel système échoue et renvoie -1, avec le code d'erreur EINTR (dans la variable errno). G. BENAY /2008

3 3 Rappels sockets Un socket est un point de communication par lequel le processus peut émettre ou recevoir des informations vers ou en provenance d'un autre socket. Serveur Client cliente Le serveur crée un fils pour traiter les requêtes et lui même se remet à l'écoute socket() bind() listen() Création et attachement d'une socket d'écoute Création du service Le serveur passe en mode écoute il peut accepter des demandes de connexion socket() bind() Création de la socket Demande de connexion accept() connect() fork() read() write() recv() send() read() write() recv() send() close() close() Chaque close() ne ferme qu un seul sens de communication! 3.1 Fichiers d'en-tête #include <sys/types.h> #include <sys/param.h> #include <sys/socket.h> /* constantes, familles */ #include <netinet/in.h> /* struct sockaddr_in */ #include <arpa/inet.h> /* prototypes pour les fonctions dans inet(3n) */ #include <netdb.h> /* struct hostent */ 3.2 Le type sockaddr_in Une adresse de socket dans la famille Internet est définie par : struct sockaddr_in { short sin_family; /* la famille de protocole */ u_short sin_port; /* numero de port */ struct in_addr sin_addr; /* adresse IP de la machine */ char sin_zero[8]; /* remplissage pour faire 16 octets */ ; Rappel : L'adresse IP d'une machine (type struct in_addr) est en fait 4 octets, qu'on écrit généralement sous la forme Coté client u_long htonl (u_long hostlong); u_short htons (u_short hostshort); struct hostent *gethostbyname (char *name); G. BENAY /2008

4 int socket (int domain, int type, int protocol); int connect (int s, struct sockaddr *name, int namelen); On utilise des sockets dans la famille de protocole Internet, de type stream (fiable, fifo, bi-directionnel), créés par : socket (PF_INET, SOCK_STREAM, 0). Pour la connexion (serverhost est le nom de la machine que l'on veut contacter, port est le numéro du port sur cette machine) : { int sc; struct hostent *sp; struct sockaddr_in sins; /* Obtention d'information au sujet de la machine `serverhost' */ sp = gethostbyname (serverhost); if (sp == NULL) { fprintf (stderr, "gethostbyname: %s not found\n", serverhost); exit (1); /* Creation d'un socket Internet de type stream (fiable, bi-directionnel) */ sc = socket (PF_INET, SOCK_STREAM, 0); if (sc == -1) { perror ("socket failed"); exit (1); /* Remplissage de la structure `sins' avec la famille de protocoles Internet, * le numero IP de la machine a contacter et le numero de port. */ sins.sin_family = AF_INET; memcpy (&sins.sin_addr, sp->h_addr_list[0], sp->h_length); sins.sin_port = htons (port); /* Tentative d'etablissement de la connexion. */ if (connect (sc, (struct sockaddr *)&sins, sizeof(sins)) == -1) { perror ("connect failed"); exit (1); 3.4 Coté serveur int socket (int domain, int type, int protocol); int setsockopt (int s, int level, int optname, char *optval, int optlen); int bind (int s, struct sockaddr *name, int namelen); int listen (int s, int backlog); int accept (int s, struct sockaddr *addr, int *addrlen); Ce qui s'utilise (port est le numéro du port sur lequel écoute le serveur) : { struct sockaddr_in soc_in; int val; int ss; /* socket Internet, de type stream (fiable, bi-directionnel) */ ss = socket (PF_INET, SOCK_STREAM, 0); /* Force la reutilisation de l'adresse si non allouee */ val = 1; setsockopt (ss, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val)); /* Nomme le socket: socket inet, port PORT, adresse IP quelconque */ soc_in.sin_family = AF_INET; soc_in.sin_addr.s_addr = htonl (INADDR_ANY); soc_in.sin_port = htons (port); G. BENAY /2008

5 bind (ss, &soc_in, sizeof(soc_in)); /* Prepare le socket a la reception de connexions */ listen (ss, 5); while (1) { struct sockaddr_in from; int len; int f; /* Accepte une connexion. * Les parametres `from' et `len' peuvent etre NULL. */ len = sizeof (from); f = accept (ss, (struct sockaddr *)&from, &len); /* */ Attention : il manque le traitement d'erreur, qui est indispensable avec les sockets, du fait de la forte probabilité de défaillance. 4 Rappels Unix Tous les appels systèmes renvoient -1 en cas d'erreur. Dans ce cas, la variable errno contient le code de l'erreur. 4.1 Obtenir des informations sur un fichier : stat Pour obtenir des information sur un fichier, utiliser : int stat (char *pathname, struct stat *buf); int fstat (int fd, struct stat *buf); La structure struct stat contient de nombreux champs (voir man stat pour plus de détails), dont st_uid (propriétaire du fichier), st_size (taille du fichier), st_mode (droit d'accès), st_mtime (date de dernière modification) #include <sys/types.h> #include <sys/stat.h> main (int argc, char **argv) { struct stat buf; if (stat (argv[1], &buf) == -1) perror (argv[1]); else printf ("%s: proprietaire %d, taille %d\n", argv[1], buf.st_uid, buf.st_size); 4.2 Ouverture d'un fichier open Pour obtenir un descripteur de fichier permettant d'accèder (lecteur ou écriture) à un fichier, on utilise l'appel système open. Les trois formes d'utilisation habituelles sont : int fd = open ("toto", O_RDONLY); int fd = open ("toto", O_WRONLY O_CREAT O_TRUNC, 0644); int fd = open ("toto", O_WRONLY O_CREAT O_EXCL, 0644); if (fd == -1) { erreur La première ligne ouvre le fichier en lecture ; la deuxième ouvre le fichier pour écriture, avec création s'il n'existe pas et troncature s'il existe déjà ; la troisième ligne ouvre le fichier pour écriture, avec création s'il n'existe pas et erreur s'il existe déjà. Le troisième argument est utilisé pour définir les droits d'accès (ici rw-r--r--) s'il y a création du G. BENAY /2008

6 fichier. 4.3 Destruction d'un fichier unlink L'appel système : int unlink (char *pathname); détruit le lien spécifié par pathname. Si ce lien était le dernier lien vers le fichier, le fichier est effacé. 4.4 Lecture/écriture read/write int read (int fd, void *buf, int nbyte); int write (int fd, const void *buf, int nbyte); L'appel système read lit sur le descripteur au plus nbyte octets et les range à l'adresse buf. Il renvoie le nombre d'octets effectivement lus, ou 0 si la «fin de fichier» a été atteinte (il n'y a et il n'y aura plus rien à lire : socket fermé ou fichier complètement lu), ou -1 en cas d'erreur. L'appel système write écrit sur le descripteur au plus nbyte octets rangés à l'adresse buf. Il renvoie le nombre d'octets effectivement écrits, ou -1 en cas d'erreur. Quand read ou write sont appliqués à un fichier, le nombre d'octets lus ou écrits est toujours le nombre demandé (sauf lorsque la fin du fichier est atteinte) ; quand ils sont appliqués à un descripteur associé à un socket, le nombre d'octets lus ou écrits peut être inférieur au nombre demandé. 4.5 Les signaux Un signal est un événement asynchrone auquel il est possible d'associer un traitement spécifique (une procédure qui sera invoquée par le système à la délivrance du signal). En absence de traitement, un signal entraîne en général la mort du processus destinataire. L'association d'un traitement se fait au moyen de la primitive signal : void traitement_sig (int sig) { signal (SIGCHLD, traitement_sig); /* remise en place du traitement */ main() { signal (SIGCHLD, traitement_sig); 5 Déroulement des tps Fournis dans un paquet zip (miniftp.zip) ou tar (miniftp.tgz): requetes.h : les types et macro-définitions utiles ; common.h, common.c : deux petites procédures bien utiles, notamment copy_n_bytes ; miniftp.c : l'architecture du client ; miniftpd.c : l'architecture du serveur ; Makefile : pour compiler. 5.1 Le Client écriture du client miniftp. Le code get est déjà fourni, compiler et exécuter en utilisant le serveur sur kirov ou karkov (port 38590) ; écrire les autres requêtes ; écrire le code des autres requêtes (put, dir, del) ; valider l'ensemble. 5.2 Le Serveur écriture du serveur miniftpd. La réponse à la requête get est fournie. écrire les autres réponses aux requêtes (put, dir, del) ; valider soigneusement. 5.3 Rapport Rappel vous devez fournir un rapport avec l'ensemble des programmes : Le serveur, Le client, Une présentation des fonctions réalisées. G. BENAY /2008

7 1. Personne seule TP3 Reseau NomGrooupeEI2 Nom.zip NomGrooupeEI2 : le nom du groupe EI2 (EI2AD, EI2AG, ou EI-I2B) Nom1 votre nom si seul, 2. Binôme TP3 Reseau NomGrooupeEI2 Nom1 Nom2.zip NomGrooupeEI2 : le nom du groupe EI2 (EI2AD, EI2AG, ou EI-I2B) Nom1 le nom d'un des membres du binôme Nom2 le nom de l'autre membre du binôme Vous envoyez votre rapport par courrier électronique à l'adresse : gerard.benay@cnam.fr au plus tard le : EI I2AG : Vendredi 6 juin 2008 EI I2AD : Vendredi 30 mai 2008 EI I2B : Vendredi 30 mai 2008 G. BENAY /2008