iUT

ORSAY
DUT Informatique
Module Systme S4 C
Dpartement Informatique 2009 / 2010
Travaux Pratiques n
o
5 : Sockets Stream
Nom(s) :
Groupe :
Date :
Objectifs : manipuler les primitives relatives la communication par sockets
stream, tre capable dimplanter des systmes client-serveur sur ce mode de
communication.
1 Avant propos : messagerie instantane ou chat
La technologie de messagerie instantane, ou chat, permet lchange quasiment en temps rel
de messages textuels entre diffrents ordinateurs dun mme rseau informatique (typique-
ment lInternet). Ce type dapplication, qui remonte au temps des premiers systmes multi-
utilisateurs (milieu des annes 60), est bas sur larchitecture client/serveur. Le fonctionnement
gnral est le suivant : un logiciel client se connecte un serveur de messagerie instantane,
une fois la connexion tablie, lorsque le serveur reoit un message de la part dun client, il
le relaie tous ses clients connects. Les clients peuvent donc communiquer intractivement
entre eux. Tous les clients peuvent lire les messages envoys par tous les autres. Dans les ap-
plications volues, on dispose de la liste des clients connects ainsi que de leur disponibilit
pour discuter.
Pourquoi le mode connect (TCP avec lutilisation des sockets stream) est adapt ce type
dapplication ?
Le but de ce TP est de raliser une application de chat simple par internet en utilisant les
sockets stream. Un exemple de programme avec son serveur et son client vous est propos
sur la page du Systme S4 http://www.lri.fr/~bastoul/systeme. Le serveur se lance
par la commande ./chat_serveur (sans argument). Un client se lance par la commande
./chat_client IP_serveur pseudo, o IP_serveur est ladresse IP de lordinateur
o fonctionne le serveur et pseudo est une chane de caractres correspondant au pseudonyme
que souhaite utiliser le client.
Travaux Pratiques n
o
5 Sockets Stream 2/6
Testez lapplication. Quel port utilise cette application pour communiquer (utilisez la com-
mande netstat -et sa page de man- pour le dcouvrir) ? Quelle option de netstat avez-
vous utilis ?
De combien de processus lapplication serveur est-elle compose pour grer 1, 2, n clients
(utilisez la commande ps -et sa page de man- pour le dcouvrir) ? De combien de processus
est compose une application client ?
2 Implantation de la partie client
Le rle du programme client est tout dabord dtablir une connexion avec le serveur de messa-
gerie instantane. Une fois que la connexion est ralise, les rceptions et missions dinforma-
tions (purement textuelles) seffectuent de manire interactive. Dune part, le client attend des
informations en provenance de lutilisateur sur lentre standard : lutilisateur tape une chane
de caractres sur le terminal et lorquil appuie sur la touche entre , la chane est envoye au
serveur via la socket de communication. Dautre part, le serveur peut tout moment envoyer
sur la socket de communication des messages en provenance des autres clients. Les messages
doivent safcher ds reception.
Proposez une organisation de votre programme (avec un schma si besoin) pour que les
tches de communications interactives puissent se drouler en parallle.
Implantez un programme client pouvant communiquer avec le serveur fourni en exemple en
vous aidant des indications ci-aprs et du squelette client.c fourni. Vous joindrez le code
source votre compte-rendu.
IUT dOrsay DUT Informatique 2009 / 2010 Module Systme S4 C
Travaux Pratiques n
o
5 Sockets Stream 3/6
Indications :
La communication seffectue de manire trs simple : seul du texte est chang. Le client envoie
des chanes de caractres qui commencent par le pseudo de lutilisateur. Le serveur envoie les
chanes de caractres quil a reues des diffrents clients. Les conseils suivre suivants vous
faciliteront la tche :
Compilez votre programme rgulirement (aprs chaque tape de lalgorithme) en utilisant
loption -Wall de gcc, qui vous donnera le maximum davertissements.
Testez systmatiquement le code de retour des fonctions appeles pour dtecter et com-
prendre les erreurs lexcution. En cas derreur, utilisez la primitive perror() pour obtenir
le maximum dinformations (voir page de man associe ou TP 3).
Pour lire une chane de caractres complte (et non seulement un mot avec scanf()), utilisez
la primitive fgets() (voir page de man associe).
3 Implantation de la partie serveur
Le serveur dune application ddie la messagerie instantane est un programme relativement
complexe. Ce serveur doit grer autant de connexions quil y a de clients (sur des sockets
de service) et de plus tre en permanence en attente de nouvelles connexions (sur la socket
dcoute). Pour tre en mesure de grer les connexions en parallle, un processus est ddi
chacune dentre elles : ds quune connexion est accepte par le serveur, un nouveau processus
est cre et cest ce processus qui assurera la gestion de la communication avec le client. Le
processus pre se charge quant lui de lacceptation de nouvelles connexions entrantes et de la
transmission des messages vers lensemble des clients (lui seul connat tous les processus ls
ou toutes les sockets de service).
Nous allons construire lapplication serveur en plusieurs versions, de la plus simple (qui ne
lest dj pas tant) la plus complexe.
3.1 Premire version du serveur : dlgation partielle
Dans un premier temps, nous allons construire une application simplie mais peu lgante :
le processus serveur pre va dlguer uniquement la gestion de la rception sur les sockets
de service des processus ls. Lorsquun processus serveur ls recevra une information, il la
transmettra au processus serveur pre via un tube. Le pre se chargera lui-mme de retrans-
mettre le message tous les clients (y compris, pour des raisons de simplicit, au client qui a
envoy le message). Le schma des communications est dcrit en Figure 1.
Socket 2
Socket 1
Socket n
Client n
Client 2
Client n
Tube
pre
Serveur
... ...
Serveur
fils 1
Serveur
fils 2
Serveur
fils n
FIGURE 1 Schma des communications dans la version dlgation partielle
IUT dOrsay DUT Informatique 2009 / 2010 Module Systme S4 C
Travaux Pratiques n
o
5 Sockets Stream 4/6
La principale difcult laquelle le processus serveur pre doit faire face est de raliser le
double travail dattente de nouvelles connexions sur la socket dcoute et de messages re-
transmettre sur le tube. Il y a plusieurs manires de traiter cela, en voici deux :
Le processus serveur pre peut recourir la primitive select() qui lui permet dattendre des
informations sur plusieurs descripteurs la fois. Cest lobjet du TD 4 multiplexage qui ne
devrait pas avoir encore t trait au dbut de ce TP. On nutilisera pas encore cette solution.
Le processus serveur pre peut effectuer normalement son travail dattente de nouvelles
connexions et vrier seulement priodiquement (en droutant le signal SIGALRM) la pr-
sence dans le tube dinformations retransmettre et en assurer la retransmission si besoin. On
a alors besoin de rendre la lecture sur le tube non bloquante, ce qui est possible par un appel
la primitive fcntl(), par exemple par linstruction fcntl(tube[0],F_SETFL,O_NDELAY);
(voir page de man relative la primitive fcntl()). On utilisera cette solution dans cette ver-
sion.
Dautres difcults existent, lies en particulier la dconnexion des clients. Tout dabord, lors-
quun client se dconnecte, le processus serveur ls sarrte. Il envoie donc un signal SIGCHLD
son pre (qui lignore par dfaut) pour lui signier quil meurt. Si le pre ne traite pas ce signal,
le ls devient un zombie tant que le pre na pas utilis la primitive wait() (ou waitpid())
pour tre averti de la mort de son ls.
Pourquoi est-il important dliminer les zombies ? Comment procder pour cette applica-
tion ?
Une deuxime difcult lie la dconnexion est que le processus serveur pre risque de cher-
cher envoyer des messages sur des sockets fermes ( moins quun protocole soit mis en
place entre le processus serveur pre et ses ls lors dune dconnexion, mais on ne le demande
surtout pas). Cela le tuera.
Pourquoi le processus serveur serait-il tu en crivant sur une socket ferme (regardez la
page de man de la primitive write() et en particuler lerreur EPIPE) ? Proposez une solution
pour que cela narrive pas.
IUT dOrsay DUT Informatique 2009 / 2010 Module Systme S4 C
Travaux Pratiques n
o
5 Sockets Stream 5/6
Implantez un programme serveur pouvant communiquer avec votre client en vous aidant du
squelette serveur.c fourni. Ce programme subira au moins une volution avant dtre rendu.
3.2 Deuxime version du serveur : dlgation totale
La premire version du serveur tait fonctionnelle et relativement simple. Pour autant elle
ntait pas vraiment lgante cause de la dlgation uniquement partielle aux processus ls
des communications avec les clients. Dans une seconde version plus propre, on souhaite que le
processus serveur pre se dgage de toute communication directe avec les clients. Lorsquun
message est envoy par un client, le processus serveur ls associ envoie ce message au travers
dun tube au processus serveur pre (comme dans la premire version). Le serveur pre (seul
connatre tous les ls) va envoyer ce message aux diffrents ls au travers dautres tubes
comme montr sur le schma des communications en Figure 2. Chaque ls retransmettra alors
ce message vers le client dont il a la charge.
Client n
Client 2
Client n
pre
Serveur
... ...
Serveur
fils 1
Serveur
fils 2
Serveur
fils n
Socket n
Socket 1
Socket 2
Tube pre vers fils 1
Tube pre vers fils 2
Tube pre vers fils n
Tube fils vers pre
FIGURE 2 Schma des communications dans la version dlgation totale
Comment les processus serveur ls vont-ils pouvoir assurer leurs communications inter-
actives (on ne peut prvoir quand le processus serveur pre ou le client demanderont de
transmettre un message, il faudra donc grer le tube et la socket en parallle) ?
Modiez votre programme serveur pour implanter la dlgation totale. Vous prendrez bien
garde ne pas laisser des descripteurs inutilement ouverts. Vous joindrez le code source
votre compte-rendu.
3.3 Troisime version du serveur : version ultime
La seconde version est satisfaisante, mais les clients, les serveurs ls et le serveur pre doivent
tous grer simultanment deux descripteurs et utilisent pour cela des solutions trop lourdes ou
inadaptes. Les clients doivent grer simultanment lentre standard et une socket, les serveurs
IUT dOrsay DUT Informatique 2009 / 2010 Module Systme S4 C
Travaux Pratiques n
o
5 Sockets Stream 6/6
ls doivent grer simultanment un tube et une socket, le serveur pre doit grer simultanment
la socket dcoute et un tube. Clients et serveurs ls utilisent deux processus pour grer le trac
en parallle, ce qui est une solution lourde, le serveur pre utilise le signal SIGALRM, ce qui est
assez inadapt.
La solution pour un travail sur si peu de descripteurs est dutiliser la primitive select(), sujet
du TD 4 multiplexage (ce ne serait par contre pas adapt au traitement de toutes les connexions
dans le serveur car elle sont potentiellement nombreuses).
Modiez votre programme serveur pour que clients et serveurs ls nutilisent plus quun
processus et que le serveur pre nait plus utiliser le signal SIGALRM, grce la primitive
select(). Vous joindrez le code source votre compte-rendu.
Commentaires personnels sur le TP (rsultats attendus, difcults, critiques etc.).
IUT dOrsay DUT Informatique 2009 / 2010 Module Systme S4 C