Notes préliminaires :

• Supports de cours au format pdf : sockets (1,6Mo)
• Sur une machine "System V" (par exemple, sur Solaris), ajouter les options suivantes lors de la compilation :
  -lsocket (pour charger la bibliothèque des sockets)
  -lnsl (pour charger les utilitaires htons...)
  
• Les fichiers sources des exemples sont dans : ~domas/sockdir

On enverra le(s) fichier(s) source(s) traitant l'exercice et le makefile permettant leur bonne utilisation à :

• I.SOCKETS : RAPPELS
  • I.1Fonctionnement
• II.COMMUNICATION CLIENT/SERVEUR
  • II.1Code du serveur (serv_fork.c)
  • II.2Code des clients (cli_fork.c)
• III.EXERCICE PREPARATOIRE : UTILISATION DE SELECT
  • III.1Code à compléter pour le serveur (sel_serv.file)
  • III.2Code à compléter pour les clients (sel_cli.file)
• IV.EXERCICE A RENDRE
  • IV.1 Fonctionnement de l'application
  • IV.2 Comment tester l'application

I.SOCKETS : RAPPELS

I.1Fonctionnement

On remarquera sur le schéma suivant :

• sin_port, le numéro de port,
  
• sin_addr, le(s) numéro(s) Internet de la machine, numéro attribué par l'administrateur système (un par carte Ethernet sur la machine)
  
• le numéro Ethernet de la carte, numéro unique attribué (matériel) par le constructeur,
  

II. COMMUNICATION CLIENT/SERVEUR

C'est sur ce type de canevas que l'on construit de nombreuses applications distribuées.

Ici, le serveur se contente d'attendre les demandes des clients distants. La gestion de la communication sera prise en charge par un processus fils, pendant que le serveur se remet en attente de demande de connexions d'autres clients.

Schéma de principe, après fin de l'attente sur accept, le serveur créé un processus fils, ce dernier fermera le socket d'écoute, tandis que le serveur fermera celui de communications :

Le serveur se libère ainsi de la gestion des communications pour se consacrer à l'écoute des demandes de connexions. Le nombre de ces demandes en attente est borné par listen , le nombre de communications en parallèle étant, lui, limité par le nombre de processus que le serveur peut créer :

On vous demande de faire tourner les deux programmes suivants et d'en comprendre le fonctionnement afin de pouvoir mener à son terme l'exercice qui vous est proposé par la suite.

Le serveur sera de préférence lancé :
- sur une machine différente de celle des clients,
- dans une autre fenêtre, sur la machine courante.

On utilisera la commande netstat ou netstat -P tcp -f inet pour suivre les dialogues entre les clients et les serveurs.

Remarques :

• la fonction socket ne fait qu'allouer les structures de données nécessaires, mais ne réserve pas de numéro de port. Ce numéro de port est attribué de façon explicite lors du bind, ou de façon transparente lors du connect.
• dans l'exemple proposé, SIGCHLD n'est pas géré. La commande ps permettra de voir les zombies (processus dans l'état Z) résultant de la terminaison des processus qui ont été créés par le serveur.

II.1 Code du serveur (serv_fork.c)

• Cliquez ici pour le recopier
• Après l'avoir modifié, vous vérifierez son fonctionnement en l'interrogeant à l'aide de la commande telnet.

II.2 Code des clients (cli_fork.c)

• Cliquez ici pour consulter cli_fork.c.
• Vérifier que ce client transmet bien au serveur les informations qu'on lui a données en utilisant le clavier.
• On peut aussi rediriger stdin (on suppose que le fichier exécutable s'appelle cli_fork) :
  ls -il | cli_fork ... ...
  cat *.c | cli_fork ... ...
  man ls | cli_fork ... ...
  

1. Faire interroger simultanément le serveur par plusieurs clients situés sur des machines différentes, ceci pour en vérifier le fonctionnement parallèle
2. Dans l'exemple proposé pour le serveur, le signal SIGCHLD n'est pas géré. La commande ps permettra de voir les zombies résultant de la terminaison des processus créés par le serveur.
3. Utiliser la commande netstat ou netstat -P tcp -f inet pour tracer les communications entre clients et serveur. Observer les autres communications entrantes et sortantes.

III. EXERCICE PREPARATOIRE : UTILISATION DE SELECT

select permet de se mettre à l'écoute sur plusieurs fichiers simultanément, c'est à dire de multiplexer les entrées-sorties. Nous allons étudier l'écriture d'un serveur utilisant cette fonction.

Utiliser la commande :
man -s 3c select
pour avoir les détails du fonctionnement de select.

Pour comprendre le mécanisme de cet appel système, on vous demande de compléter le code du client et du serveur dont on donne les squelettes ci-dessous.

On créera de nombreux processus clients pour constater le bon fonctionnement du serveur.

III.1 Code à compléter pour le serveur (sel_serv.file)

III.2 Code à compléter pour les clients (sel_cli.file)

IV. EXERCICE A RENDRE

IV.1 Fonctionnement de l'application

Fonctionnement de l'application :

• le processus se bloque en select sur stdin et le (ou les) ports d'entrée lus dans le fichier de configuration, comme cela est fait dans l'exercice précédent,
• quand il recoit un message sur un port (ou sur stdin) il le renvoie vers les sites dont il a lu l'adresse IP et le numéro de port dans le fichier de configuration,
• on lancera plusieurs processus dans des fenêtres se trouvant sur des sites différents et on initialisera la communication en rentrant un texte au clavier pour l'un des processus,

Comment obtenir le(s) port(s) d'entrée et l'(es) adresse(s) des destinataires :

• l'application va lire dans un fichier de configuration les numéros de port sur lesquels elle attend et les couples (adresse-IP, port) du (ou des) destinataire(s) vers lequel (ou lesquels) elle émet.

===Pour le processus qui s'exécute sur M1 :
  sortie M3   UDP 30287
  entree **** TCP 54678
===Pour le processus qui s'exécute sur M2 :
  sortie M1   TCP 54678
  entree **** UDP 48521
===Pour le processus qui s'exécute sur M3 :
  sortie M2   UDP 48521
  entree **** UDP 30287

IV.2 Comment tester l'application

©(Copyright) dupouy at telecom-paristech.fr