|
|
Institut National des Télécommunications
Télécom INT 2è année
TP Noté CSC4508/M2 du 05/10/06
(2è session)
(Corrigés)
Modalités
Durée : 1 heure 30
Les quatre questions sont indépendantes les unes des autres.
Le barême est donné à titre indicatif des poids
entre les différentes questions.
La «livraison» de votre travail en fin de TP
noté se fera par remise de votre copie à l'enseignant et
par
envoi d'un mail à Michel.Simatic@int-evry.fr
(sujet «CSC4508/M2:TP noté session 2») avec en pièce
jointe le fichier d'extension tgz constitué de
la manière suivante :
cd votreRepertoireDeTravailPourCS22M1 tar cvfz $USER.tgz TPNote2006Session2
Préparation
cd votreRepertoireDeTravailPourCS22M1 cp ~simatic/CS22M1/tPNote2006Session2.tgz . tar xvfz tPNote2006Session2.tgz cd TPNote2006Session2
Introduction
Au cours de ce TP noté (inspiré d'un stage
effectué par un étudiant de Télécom-INT),
on souhaite concevoir
(ce travail de conception nécessitant 1h30, ce TP noté ne
peut inclure de codage) un "serveur de tatouage d'image". Le
rôle de ce serveur est de permettre à des applications
clientes de lui soumettre des images. Ce serveur tatoue
chaque image (c'est-à-dire qu'il intègre des éléments
spéciaux dans l'image) avant de renvoyer cette image
tatouée au client.
Question 1 : Nombre maximum de tatouages simultanés (2 points)
La machine qui hébergera le serveur disposera de 1 Go de RAM
(250 Mo
étant utilisés par le système et les applications
autres que
le "serveur de tatouage") et de 1 Go de swap. L'application serveur
aura besoin de 500 Mo de RAM par tatouage à effectuer.
Sur votre copie
ou
bien dans le fichier Q1/reponse1.txt (dans ce dernier
cas, indiquez sur votre copie "Réponse dans Q1/reponse1.txt "
) :
- Estimez le nombre de tatouages simultanés que la machine serveur pourra effectuer,
- Justifiez votre réponse.
---beginCorr
Barême envisagé :
- 0,5 point pour la valeur
- 1,5 point pour la justification
La machine serveur disposera de 1 Go de RAM - 250 Mo déjà
utilisés + 1Go de swap = 1,75 Go pour faire tourner les
différentes applications serveur.
Chaque application serveur nécessitant 500 Mo, on peut donc en faire tourner 1,75 div 0,5 = 3 simultanément.
---endCorr
Question 2 : Borne inférieure pour la
durée d'exécution pour un tatouage quand le serveur
travaille à pleine charge (2,5 points)
L'application serveur (qui est une application CPU-intensive) a besoin
de 1 minute CPU pour réaliser un tatouage, si toutes ses
données résident en mémoire vive. Sachant que
la machine serveur est mono-processeur et ne permet pas d'hyper-threading,
proposer une borne inférieure pour la durée
d'exécution d'un tatouage lorsque l'application
serveur exécute simultanément le nombre de tatouages
trouvé à la question 1. Justifiez votre
réponse.
NB : vous pouvez répondre sur votre copie
ou
bien dans le fichier Q2/reponse2.txt (dans ce dernier
cas, indiquez sur votre copie "Réponse dans Q2/reponse2.txt "
).
---beginCorr
Barême envisagé :
- 1 point pour la borne inférieure
- 1,5 point pour la justification
L'application serveur étant CPU-intensive, la durée
d'exécution d'un tatouage est sensiblement équivalente au
temps CPU requis par ce tatouage. Si on a 3 (cf. réponse
à la question 1) tatouages simultanés, alors la CPU est
partagée entre ces 3 tatouages. Si les données
correspondant aux tatouages pouvaient résider
simultanément en mémoire vive, il faudrait donc 3 fois
plus de temps, soit 3x1 minute = 3 minutes. Mais une partie de ces
données est probablement swappée pendant le calcul du
tatouage. Il y aura donc un délai induit par les attentes de
données swappées temporairement sur disque. La
durée d'exécution sera donc probablement
supérieure. La borne inférieure est donc 3 minutes.
---endCorr
Question 3 : Evaluation d'une première solution (6,5 points)
La solution suivante est envisagée :
- Tout client exécute l'algorithme suivant :
Début
connexionAuServeur(référenceClient)
envoyerAuServeur(imageATatouer)
recevoirDuServeur(imageTatouee)
rompreConnexionAuServeur()
Fin
- Le serveur travaille de la manière suivante :
Début
faire
attenteConnexionDUnClient(référenceClient)
recevoirDuClient(référenceClient,imageATatouer)
P(sem)
démarrerUneTâcheDeTatouageDImage(référenceClient,imageATatouer)
tant que VRAI
Fin
-
Le serveur démarre des tâches de tatouage d'image dont l'algorithme est le suivant :
Tâche tatouageDImage(Données : réferenceClient : Référence
imageATatouer : Image)
Début
réaliserTatouage(imageATatouer, imageTatouée)
envoyerAUnClient(référenceClient, imageTatouée)
V(sem)
Fin
Sur votre copie
ou
bien dans le fichier Q3/reponse3.txt (dans ce dernier
cas, indiquez sur votre copie "Réponse dans Q3/reponse3.txt "
) :
- Expliquez le rôle du sémaphore sem
---beginCorr
Barême envisagé : 2 points
On est dans le cadre d'un paradigme de type "cohorte". En effet, il
faut éviter qu'il y ait plus de 3 tatouages s'exécutant
simultanément (cf. réponse à la question 1), sous
peine de ne pas avoir assez de mémoire dans l'ordinateur.
---endCorr
- Indiquez la valeur initiale de ce sémaphore. Justifier votre réponse.
---beginCorr
Barême envisagé :
- 1 point pour la valeur initiale
1 point pour la justification
On doit avoir au plus 3 tatouages s'exécutant
simultanément (cf. réponse à la question 1). La
valeur initiale du sémaphore est donc 3.
---endCorr
- On considère le cas où 10
clients demandent presque simultanément le tatouage d'une image.
Montrez que 3 de ces clients restent bloqués pendant
au moins 3 minutes entre l'instruction connexionAuServeur()et l'instruction recevoirDuServeur(imageTatouee), 3 autres pendant au moins 6 minutes, 3 autres pendant au moins 9 minutes, et le 10è pendant au moins 10 minutes.
---beginCorr
Barême envisagé : 2,5 points
On suppose que 10 clients demandent presque simultanément le
tatouage d'une image. Le serveur reçoit la demande de connexion
du premier client et lance une tâche tatouageDImage. Il prend ensuite en compte la demande de connexion du deuxième client et lance une deuxième tâche tatouageDImage. Idem pour le troisième client. Le serveur reste ensuite bloqué sur le P(sem) en attendant qu'une des tâches fasse V(sem),
ce qui nécessitera au moins 3 minutes (cf. question 2). Les
autres clients sont donc bloqués pendant au moins 3 minutes. En
reproduisant ce raisonnement avec les autres clients, on constate que
le dixième client attend au moins 3 + 3 + 3 + 1 (cette minute
correspondant au temps minimum (si la demande de tatouage d'image est
la seule à être traitée à ce
moment-là) de traitement de la demande de tatouage du
dixième client) = 10 minutes.
---endCorr
Question 4 : Mise au point d'une solution de meilleure qualité (9 points)
Cette éventuelle attente sans aucune information du serveur
apparaît inacceptable pour les développeurs de ce "serveur
de tatouage d'image".
La solution suivante est donc envisagée :
- Un client qui souhaite soumettre le tatouage d'une image exécute l'algorithme suivant :
Début
connexionAuServeur(référenceClient)
envoyerAuServeur(REQUETETATOUAGE)
envoyerAuServeur(imageATatouer)
recevoirDuServeur(estimationDélaiTraitement)
rompreConnexionAuServeur()
affichage("Temps d'attente estimé :", estimationDélaiTraitement)
Fin
- Un client qui souhaite savoir où en est le tatouage de l'image qu'il a soumise exécute l'algorithme suivant :
Début
connexionAuServeur(référenceClient)
envoyerAuServeur(STATUTTATOUAGE)
recevoirDuServeur(statut)
rompreConnexionAuServeur()
affichage("Status tatouage :", statut)
Fin
- Un client qui souhaite récupérer une image tatouée exécute l'algorithme suivant :
Début
connexionAuServeur(référenceClient)
envoyerAuServeur(RECUPERATIONIMAGE)
recevoirDuServeur(imageTatouée)
rompreConnexionAuServeur()
Fin
- Le serveur travaille de la manière suivante :
Début
Pour i=1:Naturel à NBMAXTACHESTATOUAGE faire
démarrerTâcheDeTatouageDImage()
Fait
faire
attenteConnexionDUnClient(référenceClient)
recevoirDuClient(typRequête)
cas où typRequête vaut :
REQUETETATOUAGE:
recevoirDuClient(imageATatouer)
stockerDansStructureDeDonnées(référenceClient, imageATatouer, estimationDélaiTraitement)
envoyerAUnClient(référenceClient, estimationDélaiTraitement)
break
STATUTTATOUAGE:
interrogerStructureDeDonnées(référenceClient, statut)
envoyerAUnClient(référenceClient, statut)
RECUPERATIONIMAGE:
récupérationDansStructureDeDonnées(référenceClient, imageTatouée)
envoyerAUnClient(référenceClient, imageTatouée)
fincas
tant que VRAI
Fin
-
Le serveur démarre des tâches de tatouage d'image dont l'algorithme est le suivant :
Tâche tatouageDImage()
Début
rechercherDansStructure(imageATatouer)
réaliserTatouage(imageATatouer, imageTatouée)
stockerDansStruture(imageTatouée)
Fin
Sur votre copie
ou
bien dans le fichier Q4/reponse4.txt (dans ce dernier
cas, indiquez sur votre copie "Réponse dans Q4/reponse4.txt "
) :
- Décrivez les grandes lignes de la structure de données qui serait manipulée par les procédures stockerDansStructureDeDonnées(), interrogerStructureDeDonnées() et récupérationDansStructureDeDonnées() : tableau de structures ? liste de structures ? champs contenus dans ces structures ? Justifiez votre réponse.
---beginCorr
Barême envisagé :
- 1 point pour la structure globale (et sa justification)
- 1 point pour les différents champs
On peut travailler avec un tableau de structures comme avec une liste
de structures. La liste de structures présente l'avantage de ne
pas être limitée en taille. Mais comme on va probablement
travailler avec de la mémoire partagée, il faudra avoir
une taille maximale de mémoire partagée. Le tableau de
structures semble donc préférable.
En ce qui concerne les champs contenus dans ces structures, il faut
pouvoir stocker l'image à tatouer, l'image tatouée (ces
deux champs peuvent peut-être être confondus dans un souci
d'économie de place), la référence du client, le statut du tatouage (ENATTENTE, ENCOURS, TERMINE,
STRUCTUREDISPONIBLEPOURNOUVEAUTATOUAGE) et éventuellement un
champ date/heure (pour purger les demandes de tatouage soumises par des
clients, traitées par le serveur et non
récupérées par ces clients depuis tellement
longtemps que ces clients ne les récupéreront sans doute
jamais).
---endCorr
- Quel(s) paradigme(s) de synchronisation distinguez-vous dans cette solution ?
---beginCorr
Barême envisagé : 1,5 point par paradigme (et l'explication de qui est qui)
- Il y a un paradigme producteur/consommateur, le serveur
qui traite des REQUETETATOUAGE étant un producteur et les
tâches tatouageDImage étant des consommateurs quand elles invoquent rechercherDansStructure .
- De plus, il y a un paradigme lecteur/rédacteur, les lecteurs étant le serveur qui traite des STATUTTATOUAGE et les rédacteurs étant le serveur qui traite des REQUETETATOUAGE et des RECUPERATIONIMAGE plus les tâches quand elles exécutent rechercherDansStructure ou stockerDansStruture.
---endCorr
- Ajoutez les déclarations de sémaphores, leurs initialisations et leurs manipulations (P() et V()) dans les algorithmes ci-dessus
---beginCorr
Barême envisagé :
- 1 point pour les déclarations
- 1 point pour les initialisation
- 2 points pour le placement des P et V
Corrigé à compléter
---endCorr
|