03 99 Slides Client Serveur

Modle Client-Serveur
8-9 avril 1999
Modle client-serveur
Michel RIVEILL INP Grenoble / ENSIMAG
Projet IMAG-INRIA SIRAC 655 avenue de l Europe 38330 Montbonnot St Martin
Avril 1999
Modle client-serveur Plan

y Principe y Traitement des dfaillances y Dsignation, localisation et liaison y Intgration aux langages de programmation y Exemple de mise en uvre
x sockets x rpcgen x Java RMI
y Travaux actuels y Conclusion y Bibliographie
Avril 1999
Copyright Michel Riveill, INP Grenoble, 1999
8-9 avril 1999
Modle client-serveur dfinition

z application client/serveur
y application qui fait appel des services distants au travers dun change de messages (les requtes) plutt que par un partage de donnes (mmoire ou fichiers) y serveur
x programme offrant un service sur un rseau (par extension, machine offrant un service)
y client
x programme qui met des requtes (ou demandes de service). Il est toujours linitiateur du dialogue
Avril 1999
communication par messages

z Deux messages (au moins) changs
y Le premier message correspondant la requte est celui de l'appel de procdure, porteur des paramtres d'appel. y Le second message correspondant la rponse est celui du retour de procdure porteur des paramtres rsultats. Appel(p_in)
appel n_proc (p_in, p_out) Procdure n_proc (p_in, p_out) begin
Retour(p_out)
end
Avril 1999
client
serveur
4
8-9 avril 1999
Modle client-serveur principe

z Vu du client
client Requte Rponse Service distant
z Vu du serveur
y Gestion des requtes (priorit) y Excution du service (squentiel, concurrent) y Mmorisation ou non de l'tat du client Slection Requtes Traitement Rponses
Avril 1999
Modle client-serveur exemple

z z z z z Serveur de fichiers (aufs, nfsd) Serveur d'impressions (lpd) Serveur de calcul Serveur base de donnes Serveur de noms (annuaire des services)
Avril 1999
8-9 avril 1999
Modle client-serveur gestion des processus

z Client et serveur sont dans des processus distincts
y Le client est suspendu lors de lexcution de la requte y Eventuellement, excution concurrente de plusieurs requtes chez le serveur
x Plusieurs processus (une mmoire virtuelle associe chaque processus) x Plusieurs processus lgers (thread) dans le mme espace virtuel (contexte restreint : pile, mot d'tat, registres)
Avril 1999
Mise en uvre serveur unique

z Processus serveur unique
while (true) { receive (client_id, message); extract (message, service_id, paramtres); do_service [service_id] (paramtres, rsultats); send (client_id, rsultats); };
Slection requtes rponse

Avril 1999 8
Traitement
8-9 avril 1999
Mise en uvre 1 processus par service

z Processus veilleur
while (true) {
receive (client_id, message); extract (message, service_id, paramtres); work_to_do.put (client_id, service_id, paramtres);
z Pool d'excutant
while (true) {
work_to_do.get (client_id, service_id, paramtres); do_service [service_id] (paramtres, rsultats); send (client_id, rsultats);
};
requtes Slection
};
Activation
rponses
Traitement
Avril 1999
Mise en uvre 1 processus par service

z Processus veilleur
while (true) {
receive (client_id, message); extract (message, service_id, paramtres); p := create_thread (client_id, service_id, paramtres);
z Cration dynamique des excutants

do_service [service_id] (paramtres, rsultats); send (client_id, rsultats); exit;
};
Slection requtes
Cration
rponses
Traitement
Avril 1999
10
8-9 avril 1999
Diffrents types de service
pas de donne rmanente (ou persistante) z situation idale ou le service s excute uniquement en fonction des paramtres d entre
y pas de modification de donnes rmanente sur le serveur
z solution trs favorable

y pour la tolrance aux pannes y pour le contrle de la concurrence
z exemple :
y calcul d une fonction scientifique
Avril 1999
11
avec donne rmanente (ou persistante) z Les excutions successives manipulent des donnes persistantes
y modification du contexte d excution sur le site distant y problmes de contrle de la concurrence y difficults en cas de panne en cours d excution
z Exemples
y Etat d un objet manipul par ses mthodes y Serveur de fichier rparti
x Pose de verrou pour les oprations d criture
Avril 1999
12
8-9 avril 1999

mode sans tat z Les appels de procdure s excutent sans lien entre eux
y il peut y avoir modification de donnes globales mais l opration s effectue sans lien avec celles qui l ont prcd
z exemple
y serveur de fichiers rpartis : accs alatoire
x criture du nime article d un fichier x NFS (Network File System de SUN - SGF rparti
Avril 1999
13

mode avec tat z Les appels successifs s excutent en fonction d un tat laiss par les appels antrieurs
y gestion de l ordre des requtes est indispensable
z exemple
y serveur de fichiers rpartis : accs squentiel y appel de mthode sur un objet
Avril 1999
14
8-9 avril 1999
Appel de procdure distance (RPC)

z Outils de base pour raliser le mode client-serveur.
y L'opration raliser est prsente sous la forme d'une procdure que le client peut faire excuter distance par un autre site : le serveur.
x Forme et effet identique ceux d'un appel local
Simplicit (en l'absence de pannes) Smantique identique celle de l'appel local
y Oprations de base
x Client
doOp (IN Port serverId, Name opName , Msg *arg, OUT Msg *result )
x Serveur
getRequest (OUT Port clientId, Message *callMessage) sendReply (IN Port clientId, Message *replyMessage) opName (Msg *arg, OUT Msg *result)
Avril 1999
15
RPC Objectifs
z Retrouver la smantique habituelle de l appel de procdure
y sans se proccuper de la localisation de la procdure y sans se proccuper du traitement des dfaillances
z Objectifs trs difficiles atteindre

y ralisation peu conviviale y smantique diffrente de l appel de procdure mme en l absence de panne
Avril 1999
16
8-9 avril 1999
RPC : les piges

z Appel de procdure
z appelant et appel sont dans me mme espace virtuel
y mme mode de pannes y appel et retour de procdure sont des mcanismes internes considrs comme fiables
x sauf aspect lis la liaison dynamique de la procdure et la vrification de la protection
z Appel de procdure distance

z Appelant et appel sont dans 2 espaces virtuels diffrents
y pannes du client et du serveur sont indpendantes y pannes du rseau de communication (perte du message dappel ou de rponse) y temps de rponse du serveur long
x charge du rseau ou du site serveur
y dans certains langages

x mcanisme dexception pour transmettre les erreurs de lappel lappelant
Avril 1999
17
RPC [Birrel & Nelson 84] Principe de ralisation

Appelant
Service RPC Protocole de (talon) communication Protocole de Service RPC communication (talon)
Appel A B
appel
Appel rseau E
return
return
Avril 1999
client
serveur
18
8-9 avril 1999
RPC (A) Principe de fonctionnement

z Ct de l appelant
y Le client ralise un appel procdural vers la procdure talon client
x transmission de l ensemble des arguments
y au point A
x le talon collecte les arguments et les assembles dans un message (empaquetage - parameter marshalling) x x x x
Avril 1999
un identificateur est gnr pour le RPC Un dlai de garde est arm Pb : dtermination de l adresse du serveur le talon transmet les donnes au protocole de transport pour mission sur le rseau
19
RPC (B et C) Principe de fonctionnement

z Cot de l appel
y le protocole de transport dlivre le message au service de RPC (talon serveur/skeleton) y au point B
x le talon dsassemble les arguments (dpaquetage - unmarshalling) x l identificateur de RPC est enregistr
y l appel est ensuite transmis la procdure distante requise pour tre excut (point C). Le retour de la procdure redonne la main au service de RPC et lui transmet les paramtres rsultats (point D)
Avril 1999
20
10
8-9 avril 1999
RPC (D) Principe de fonctionnement

z Cot de l appel
y au point D
x les arguments de retour sont empaquets dans un message x un autre dlai de garde est arm x le talon transmet les donnes au protocole de transport pour mission sur le rseau
Avril 1999
21
RPC (E) Principe de fonctionnement

z Cot de l appelant
y l appel est transmis au service de RPC (point E)
x les arguments de retour sont dpaquets x le dlai de garde arm au point A est dsarm x un message dacquittement avec lidentificateur du RPC est envoy au talon serveur (le dlai de garde arm au point D peut tre dsarm) x les rsultats sont transmis l appelant lors du retour de procdure
Avril 1999
22
11
8-9 avril 1999
RPC Rle des talons

Talon client - stub z Cest la procdure dinterface du site client
y qui reoit lappel en mode local y le transforme en appel distant en envoyant un message. y reoit les rsultats aprs l'excution y retourne les paramtres rsultats comme dans un retour de procdure.
Avril 1999
Talon serveur - skeleton z Cest la procdure sur le site serveur

y qui reoit lappel sous forme de message, y fait raliser lexcution sur le site serveur par la procdure serveur (choix de la procdure) y retransmet les rsultats par message.
23
RPC Problmes
z Traitement des dfaillances
y Congestion du rseau ou du serveur
x la rponse ne parvient pas avant une date fixe par le client (systme temps critique)
z Problmes de scurit
y authentification du client y authentification du serveur y confidentialit des changes Performance
y Panne du client pendant le traitement de la requte y Panne du serveur avant ou pendant le traitement de la requte y Erreur de communication
z Dsignation et liaison, z Aspects pratiques

y Adaptation des conditions multiples (protocoles, langages, matriels) y Gestion de l'htrognit
24
Avril 1999
12
8-9 avril 1999
Diffrents types de pannes

z Panne du serveur
y attente indfinie par le client dune rponse qui ne viendra peut tre jamais
x utilisation dune horloge de garde x le client dcide de la stratgie de reprise
abandon re-essaie choix dun autre serveur
x risque dexcuter plusieurs fois la mme procdure
Diffrents types de pannes

z Panne du client
y risque de ralisation de travaux inutiles y risque de confusion aprs relance du client entre les nouvelles rponses attendues et les rponses de lancienne requte y le serveur est dit orphelin
x ncessit de dtruire les tches serveurs orphelines et de distinguer les requtes utiles des vieilles requtes
y Pbs : ltat du client et du serveur peuvent devenir inconsistants
Avril 1999
26
13
8-9 avril 1999
RPC
Smantique en cas d erreur

z En cas d'erreur : la smantique est dfinie par le mcanisme de reprise
y Indfini y Au moins une fois
x Plusieurs appels possibles si perte de la rponse x Acceptable si opration idempotente (f o f = f)
y Au plus une fois

x si expiration du dlai A alors code d erreur sinon rsultat correct x pas de mcanisme de reprise
y Exactement une fois (idal...)

Avril 1999
x si expiration du dlai A alors re-mission de l appel x si expiration du dlai D alors re-mission du rsultat
27
RPC
Traitement des dfaillances

z Congestion du rseau ou du serveur
y Panne transitoire (ne ncessite pas d intervention) y Dtection : expiration du dlai de garde A ou D y Recouvrement
x le service de RPC (point A) re-met l appel (mme id) sans intervention de l application x Le service de RPC (point C) dtecte quil s agit d une re-mission
si l appel est en cours d excution : aucun effet si le retour a dj t effectu, re-mission du rsultat
y Smantique : Exactement UN
x (en l absence de panne permanente du client, du serveur ou du rseau)
Avril 1999 28
14
8-9 avril 1999
RPC

z Panne du client aprs mission de l appel
y L appel est correctement trait
x changement d tat du serveur x l appel de procdure est dclar orphelin
y Dtection : expiration du dlai de garde D y Recouvrement

x L application cliente re-met l appel (avec id diffrent)
smantique : Au moins UN
x le serveur ne peut pas dtect qu il s agit d une rptition

service idempotent : pas d incidence service non idempotent service transactionnel (annulation par le client des effets de l appel orphelin)
Avril 1999
29
RPC

z Panne du serveur aprs mission de l appel
y L appel peut tre correctement ou partiellement trait
x avant point B, durant C ou avant point D
y Dtection : expiration du dlai de garde A y Recouvrement

x le client doit re-mettre l appel ds que le serveur redmarre
smantique : Au moins UN le client ne connat pas l endroit de la panne si avant point B : pas d incidence si entre B et D : changement d tat du serveur service transactionnel pour mmoriser id et tat avant excution
Avril 1999
30
15
8-9 avril 1999
RPC Reprsentation des donnes

z Problme classique dans les rseaux
y Conversion est ncessaire si le site client et le site serveur
x n utilise pas le mme codage (big endian, little endian) x utilisent des formats internes diffrents (type caractre, entier, flottant, ) x solution place classiquement dans la couche 6 du modle OSI prsentation
y dans rseau : passage de paramtres par valeur

x mulation des autres modes
Avril 1999
31
RPC Reprsentation des donnes

z solution normalise :
y syntaxe abstraite de transfert ASN 1
z autres solutions
y Reprsentation externe commune : XDR Sun (non optimal si mme reprsentation) y Reprsentation locale pour le client, conversion par le serveur y Choix d'une reprsentation parmi n (standard), conversion par le serveur y Ngociation client serveur
Avril 1999 32
16
8-9 avril 1999
RPC
Passage des paramtres

z Format du paquet d appel
y Appel local y Appel distant
Tas x y z
En-tte x y z
Pile
Avril 1999 33

y Valeur
x pas de problme particulier
smantiques de transmission varies
y copie/restauration
x valeurs des paramtres sont recopies x pas de difficults majeures mais redfinition des solutions dfinies pour les rseaux x optimisation des solutions pour le RPC x bonne adaptation au langage C (faiblement typ)
Avril 1999
34
17
8-9 avril 1999

y rfrence

x utilise une adresse mmoire centrale du site de l appelant aucun sens pour l appel x solutions
interdiction totale introduit une diffrence entre procdures locales et procdures distantes simulation en utilisation une copie de restauration marche dans de trs nombreux cas mais violation dans certains cas de la smantique du passage par rfrence exemple de pb : procdure double_incr (x, y) x := x+1; y := y+1; a := 0 ; double_incr (a, a) rsultat : a = 2 ou a = 1 ?
Avril 1999
35

y Rfrence
x solutions (suite)
reconstruire l tat de la mmoire du client sur le site serveur solutions trs coteuse utilisation d une mmoire virtuelle rpartie ncessite un systme rparti avec mmoire virtuelle
z Solutions gnralement prises

x IN : passage par valeur (aller) x OUT : passage par valeur (retour) x IN-OUT : interdit ou passage par copie-restauration
ATTENTION : n est pas quivalent au passage par rfrence
Avril 1999
36
18
8-9 avril 1999
RPC Dsignation
z Objets dsigner
y Le site d excution, le serveur, la procdure y Dsignation globale indpendante de la localisation
x possibilit de reconfiguration des services (pannes, rgulation de charge, )
z Dsignation
y statique ou dynamique
x statique : localisation du serveur est connue la compilation x dynamique : non connue la compilation, objectifs :
sparer connaissance du nom du service de la slection de la procdure qui va l excuter permettre l implmentation retarde
Avril 1999 37
Liaison et fonctionnement
z Liaison (dtermination de l'adresse du serveur)
y Liaison statique (pas d appel un serveur de nom ou appel lors de la compilation) y Liaison au premier appel (appel du serveur de nom lors du premier appel) y Liaison chaque appel (appel du serveur de nom chaque appel)
Programme client Talon client communication logique Service de dsignation
consultation enregistrement
Programme serveur Talon serveur
Communication client
Avril 1999
communication physique
Communication serveur
38
19
8-9 avril 1999
Liaison - solution classique DNS Internet

Client 4 Souche client 6 5 Appel : 4, 7, 8 Consultation : 5, 6
Avril 1999
Serveur 8 7 Souche serveur 3 2 Serveur d annuaire Enregistrement : 1, 2, 3

39
Liaison - solution classique DNS Internet

z Etape 1, 2 et 3
y enregistrement dans une base de donnes des noms de serveurs
x tape 2 : transmission du nom du service, adresse rseau du service, tous attributs complmentaires ncessaire (si plusieurs serveurs rendent le mme service) x tape 3 : enregistrement confirm (pas d homonymie, etc.)
z Etape 5 et 6
y liaison entre un client et un serveur
z Etape 4, 7, 8,
y ralisation de l appel de procdure souhait
Avril 1999 40
20
8-9 avril 1999
RPC
Performance : utilisation de cache

Pas de cache
Serveur Toute requte provoque un change avec le serveur noyau dfaut Serveur
Cache dans le noyau

Pas de dfaut
Cache dans le processus
Cache dans un serveur spcialis
Pas de dfaut Pas de dfaut dfaut Serveur dfaut Avril 1999 Serveur 41
Validation du contenu du cache client

z A la charge du client
y le client interroge le serveur pour savoir si sa copie est toujours valide y vrification par comparaison dune date associe la dernire modification des donnes y comparaison priodique ? chaque accs ? chaque ouverture ?
z A la charge du serveur
y la copie sur le serveur est la copie de rfrence y le serveur possde la liste des clients qui possdent une copie y le serveur prvient chaque client de la modification de la copie matre (mcanisme de call-back) y TRES LOURD
y Remarque : extension du modle client-serveur puisque le serveur prend linitiative de lchange
21
8-9 avril 1999
RPC Mise en uvre

z Directement
y Le programmeur se charge de tout
x socket Unix
z Utilisation dun langage de description dinterface

y Le programmeur spcifie l interface des services accessibles distance
x Rpcgen x Java RMI (RPC Objet)
z Intgration dans un langage de programmation

y Approche totalement transparente (tous les objets peuvent ventuellement tre accd distance):
Avril 1999
x langage Guide (RPC Objet)
43
Mise en uvre : envoi de message z Mise en uvre l aide d un mcanisme d envoi de message
y par exemple : socket UNIX
Avril 1999
44
22
8-9 avril 1999
Mise en uvre du
client/serveur laide des sockets

z Point daccs diffrents services de communication
y avec ou sans connexion y diffrentes familles de protocoles (ISO, Internet, Xerox NS, etc...)
z Socket cre dynamiquement par un processus

y s = socket (PF_UNIX/PF_INET, SOCK_STREAM/SOCK_DGRAM, 0) y A la cration on prcise
x la famille de protocoles (par exemple Unix, Inet) x le type de service (par exemple : stream ou datagram) x ventuellement lidentification du protocole choisi,
z Une fois cr une socket doit tre lie un point daccs

y ret = bind (s, monAdresse, longueurDe_monAdresse)
Avril 1999
45
Algorithme dun serveur itratif en mode non connect

z Dans ce mode le client peut envoyer des appel au serveur n importe quel moment
y mode assez lger orient
x traitement non ordonn des appels x absence de mmoire entre appels successifs (serveur sans donnes rmanentes et sans tat)
y exemple :
x calcul de fonction numrique x DNS x NFS
Avril 1999
46
23
8-9 avril 1999
Utilisation du mode non connect

z caractristiques
y pas dtablissement pralable dune connexion y adapt aux applications pour lesquelles les rponses aux requtes des clients sont courtes (un message) y protocole de transport utilis : UDP y mode dchange par messages : le rcepteur reoit les donnes suivant le mme dcoupage que celui effectu par lmetteur
z contraintes
y le client doit avoir accs ladresse du serveur (adresse IP et numro de port) y pour rpondre chaque client, le serveur doit en rcuprer ladresse : il faut pour cela utiliser les primitives sendto et recvfrom
z mode de gestion des requtes

y itratif : le processus serveur traite les requtes les unes aprs les autres
Avril 1999 47
Enchanement des oprations en mode non connect

Serveur socket() socket() bind() recvfrom() bind() recvfrom() fork() Client socket() sendto() recvfrom() close() traitement suite du programme sendto() sendto() exit ()
Avril 1999 48
traitement
24
8-9 avril 1999
Algorithme dun serveur itratif en mode connect

z Le client
y ouvre une connexion avec le serveur avant de pouvoir lui adresser des appels, puis ferme la connexion la fin de la suite d opration
x dlimitation temporelle des changes x maintien de l tat de connexion pour la gestion des paramtres de qualit de service
traitement des pannes, proprit d ordre
y orient vers
x traitement ordonn d une suite d appel
ordre local (requte d un client traite dans leur ordre d mission), global ou causal
Avril 1999
x la gestion de donnes persistantes ou de protocole avec tat
49
Utilisation du mode connect

z caractristiques
y tablissement pralable dune connexion (circuit virtuel) : le client demande au serveur sil accepte la connexion y fiabilit assure par le protocole de transport utilis : TCP y mode dchange par flots doctets : le rcepteur na pas connaissance du dcoupage des donnes effectu par lmetteur y possibilit dmettre et de recevoir des caractres urgents (OOB : Out Of Band) y aprs initialisation, le serveur est "passif", il est activ lors de larrive dune demande de connexion dun client y un serveur peut rpondre aux demandes de services de plusieurs clients : les requtes arrives et non traites sont stockes dans une file dattente
Avril 1999 50
25
8-9 avril 1999
Utilisation du mode connect

z contrainte
y le client doit avoir accs ladresse du serveur (adresse IP et numro de port)
z modes de gestion des requtes

y itratif : le processus serveur traite les requtes les unes aprs les autres y concurrent : par cration de processus fils pour les changes de chaque requte
Avril 1999
51
Enchanement des oprations en mode connect

Serveurs t = socket () bind() listen() s = accept() read() traitement write() close(s) close(t) read() close() traitement write() close(s) exit()
Avril 1999 52
t = socket () bind() listen() s = accept() fork() close(s)
Client socket () connect() write() read()
shutdown ()
26
8-9 avril 1999
Mise en uvre directe

z Permet de comprendre les mcanismes qui sont utiliss par les autres approches z A proscrire, car pour chaque application, le programmeur traite les mmes problmes
y Gnration la main des talons / squelette
x x x x empaquettage / dpaquettage des paramtres dsignation et liaison du serveur traitement de l htrognit traitement des dfaillances
Avril 1999
53
RPC
Intgration dans un langage

z Objectifs : faciliter l criture du client et du serveur
y Approche non transparente
x l appel distant est syntaxiquement diffrente d un appel local
a_type := call a_remote_proc(<args>) <one, maybe> timeout N
y Approche transparente
x dtection automatique de l appel distant
comment ? liste de noms ou lors de la liaison du cot du client : l appel la procdure est remplac par un appel au talon client (stub) gnr par le compilateur du cot du serveur : le compilateur produit un talon serveur (skeleton) capable de recevoir l appel et de le rediriger vers la procdure
y Un outil : les langages de dfinition d interface (IDL)

Avril 1999 54
27
8-9 avril 1999
RPC
IDL : spcification des interfaces

z Utilisation d'un langage
y Spcification commune au client et au serveur adapte des langages multiples
x analogie avec les modules d'Ada, Modula-2
y Dfinition des types et natures des paramtres (IN, OUT, IN-OUT)
z Utilisation de ces dfinitions pour gnrer automatiquement :

y le talon client (ou proxy, stub) y le talon serveur (ou squelette, skeleton)
Avril 1999
55
IDL
Mode opratoire
Procdure Procdure du client du client compilateur compilateur
stub stub Dfinitions communes
Programme Programme client client bibliothque
Description d interface
Gnrateur de talons Gnrateur de talons
Dfinitions communes
bibliothque
Procdure Procdure du serveur du serveur

Avril 1999
skeleton skeleton
compilateur compilateur
Programme Programme serveur serveur

56
28
8-9 avril 1999
RPC Compilation des interfaces

z Produire les talons client et serveur
y diffrents langages cibles y Talons client et serveur gnrs avec la mme version du compilateur et de la spcification
x vrification par estampille
z Cot client
y Remplacer les appels de procdure distants par des appels au talon client
z Cot serveur
y Au dmarrage le serveur se fait connatre (enregistrement dans un service de dsignation) y recevoir l appel et affectu l appel sur la procdure
z Procdure gnre
y empaquetage des paramtres y identification de la procdure appeler y procdure de reprise aprs expiration des dlais de garde
Avril 1999
57
RPC Avantage d un IDL

z Traitement de l'htrognit z Types de donnes diffrents selon les langages
y Reprsentations internes diffrentes selon les systmes y Dfinition des types indpendante de la reprsentation
z Description d'une interface

y Description des types lmentaires (arguments, rsultats, exceptions) y Noms des procdures de conversion pour types complexes (avec pointeurs)
Avril 1999
58
29
8-9 avril 1999
IDL exemple de mise en uvre

RPCGEN : langage C / Unix Interface.x
rpcgen
Talon_client.c
Interface.h Code_client.c
Talon_serveur.c
Code_serveur.c
cc
Avril 1999
RPC_lib.a
cc
Programme_serveur 59
Programme_client
RPCGEN
exemple d utilisation
Interface
Client
Insert ( IN Nom, IN Agenda); Lookup ( IN Nom, OUT Agenda)
Serveur
Avril 1999
60
30
8-9 avril 1999
Rpcgen : interface.x description de linterface

const MAX_NAME = 255; typedef char Name <MAX_NAME>; typedef ....... Agenda; typedef long status; struct entry {Name name; Agenda agenda;}; typedef struct entry Entry; program DISTR_AGENDA { version VERSION_NUMBER { Agenda Lookup (Name) = 1; // numro de la procdure status Insert (Entry) = 2; // numro de la procdure }=1 // numro de version } = 76 // numro de programme
rpcgen interface.x
y produit les fichiers : interface.h, interface_xdr.c, interface_svc.c et interface_clnt.c
Avril 1999
61
Rpcgen : programmation du serveur

rpcgen -Ss interface.x >serveur.c
/* This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. */ #include "interface.h" Agenda *lookup_1(argp, rqstp) Name *argp; struct svc_req *rqstp; { static Agenda result;
status *insert_1(argp, rqstp) Entry *argp; struct svc_req *rqstp; { static status result;
/* insert server code here */ printf ( "serveur : lookup %s \n", argp->Name_val);

return (&result); }
Avril 1999
/* insert server code here */ printf ( "serveur : insert %s -%d\n", argp->name.Name_val, argp->agenda);
return (&result); }
62
31
8-9 avril 1999
Rpcgen : programmation du client

rpcgen -Sc interface.x >client.c
/* This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. */ #include "interface.h" void distr_agenda_1(host) char *host; { CLIENT *clnt; Agenda *result_1; Name lookup_1_arg; status *result_2; Entry insert_1_arg; // page suivante... }
Avril 1999
main(argc, argv) int argc; char *argv []; { char *host; if (argc < 2) { printf("usage: %s server_host\n", argv[0]); exit(1); } host = argv [1]; distr_agenda_1(host); }
63
Rpcgen : programmation du client

#ifndef DEBUG clnt = clnt_create(host, DISTR_AGENDA, VERSION_NUMBER, "netpath"); if (clnt == (CLIENT *) NULL) { clnt_pcreateerror(host); exit(1); } #endif /* DEBUG */ lookup_1_arg.Name_len=strlen("Michel")+1; lookup_1_arg.Name_val="Michel"; result_1 = lookup_1(&lookup_1_arg, clnt); if (result_1 == (Agenda *) NULL) { clnt_perror(clnt, "call failed"); } printf("retour lookup : agenda = %d\n", *result_1); Avril 1999 insert_1_arg.name.Name_len=strlen("Michel")+1; insert_1_arg.name.Name_val="Michel"; insert_1_arg.agenda=12; result_2 = insert_1(&insert_1_arg, clnt); if (result_2 == (status *) NULL) { clnt_perror(clnt, "call failed"); } printf("retour insert : status = %d\n", *result_2);
64
32
8-9 avril 1999
Rpcgen : construction du makefile

z rpcgen -Sm interface.x > Makefile z Modifier les lignes :
y y y y SOURCES_CLNT.c = client.c SOURCES_SVC.c = serveur.c CLIENT = client SERVER = serveur
z make
y produit deux binaires : client et serveur
Avril 1999 65
Sun RPC : limitations

z Avec dUDP : taille d un message < 8 K octets. z Un seul paramtre d appel et un seul de retour
y si plusieurs paramtres construire une structure y formatage des paramtres complexes l aide de XDR
z Smantique en cas de panne : au moins un

y rmission jusqu la rponse ou erreur
z Aucune facilit pour crire un serveur multiplex.
Avril 1999
66
33
8-9 avril 1999
Client-serveur objet
z Motivations
y proprits de lobjet (encapsulation, modularit, rutilisation, polymorphisme, composition) y objet : unit de dsignation et de distribution
z lments d'une "invocation"

y rfrence d'objet ("pointeur" universel) y identification d'une mthode y paramtres d'appel et de retour (y compris signal d'exception)
x passage par valeur : types lmentaires et types construits x passage par rfrence
Avril 1999
z objets "langage" y reprsentation propre au langage : instance d'une classe y exemple : Java RMI z objets "systme" y reprsentation "arbitraire" dfinie par l'environnement d'excution y exemple : CORBA
67
Appel de mthode distance
Remote Method Invocation (RMI)
objet client
rfrence
objet serveur
tat Talon client Methode _1 . . Methode _n Systme de communication
appel
Talon serveur
Rfrence d'objet + mthode + arguments Rsultat ou exception
dsignation envoi de requtes excution de requte retour de rsultat 68
Avril 1999
34
8-9 avril 1999
RPC Java RMI

z Un RPC objet intgr Java z Interaction d'objets situs dans des espaces d'adressage diffrents sur des machines distinctes z Simple mettre en uvre : un objet distribu se manipule comme tout autre objet Java
Avril 1999
69
Java RMI Architecture

Objet Client Objet Client Objet Serveur Objet Serveur
Proxy Proxy
Skeleton Skeleton
JVM
Remote Reference Layer Remote Reference Layer Transport Transport
JVM
Avril 1999
70
35
8-9 avril 1999

rmiregistry rmiregistry
Naming Naming
Client Client
Serveur Serveur
JVM Client
Skeleton Skeleton
JVM Serveur
Avril 1999
71
Java RMI Mode opratoire cot serveur

z 1 - L'objet serveur s'enregistre auprs du Naming de sa JVM (mthode rebind) z 2 - L objet skeleton est cr, celui-ci cre le port de communication et maintient une rfrence vers l'objet serveur z 3 - Le Naming enregistre l'objet serveur, et le port de communication utilis auprs du serveur de noms z L'objet serveur est prt rpondre des requtes
Avril 1999 72
36
8-9 avril 1999

rmiregistry rmiregistry
Naming Naming
Naming Naming
Client Client

Stub Stub
Serveur Serveur

Skeleton Skeleton JVM Serveur
JVM Client
Avril 1999
73
Java RMI Mode opratoire cot client

z 4 - L'objet client fait appel au Naming pour localiser l'objet serveur (mthode lookup) z 5 - Le Naming rcupre les "rfrences" vers l'objet serveur, ... z 6 - cre l objet Stub et ... z 7 - rend sa rfrence au client z 8 - Le client effectue l'appel au serveur par appel l objet Stub
Avril 1999
74
37
8-9 avril 1999
Java RMI Manuel d'utilisation

z Dfinition de l'interface de l'objet rparti
y interface : "extends java.rmi.Remote" y methodes : "throws java.rmi.RemoteException y paramtres srializable : "implements Serializable"
z Ecrire une implmentation de l'objet serveur

y classe : "extends java.rmi.server.UnicastRemoteObject"
Avril 1999
75
Java RMI Mode opratoire

z codage
y description de l interface du service y criture du code du serveur qui implante l interface y criture du client qui appelle le serveur
z compilation
y compilation des sources (javac) y gnration des stub et skeleton (rmic)
z activation
y lancement du serveur de noms (rmiregistry) y lancement du serveur y lancement du client
Avril 1999
76
38
8-9 avril 1999
RPC
Java RMI : criture de l interface

z Mmes principes de base que pour l interface d un objet local z Principales diffrences
y l interface distante doit tre publique y l interface distante doit tendre l interface java.rmi.Remote y chaque mthode doit dclarer au moins l exception java.rmi.RemoteException y tout objet distant pass en paramtre doit tre dclar comme une interface (passage de la rfrence de l objet) y tout objet local pass en paramtre doit tre srialisable
Avril 1999 77
Java RMI Exemple : Interface

fichier Hello.java fichier Hello.java public interface Hello extends java.rmi.Remote { public interface Hello extends java.rmi.Remote { String sayHello() throws java.rmi.RemoteException; String sayHello() throws java.rmi.RemoteException; } }
Description de l interface
Avril 1999
78
39
8-9 avril 1999
RPC
Java RMI : criture du serveur

z Serveur = la classe qui implmente l interface
y spcifier les interfaces distantes qui doivent tre implmentes
x objets locaux passs par copie (il doivent implmenter l interface java. io.serialisable) x objets distants passs par rfrence (actuellement rfrence un stub)
y c est un objet java standard

x dfinir le constructeur de l objet x fournir la mise en uvre des mthodes pouvant tre appele distance x ainsi que celle des mthodes n apparaissant dans aucune interface implmente
y crer au moins une instance du serveur y enregistrer au moins une instance dans le serveur de nom (rmiregistry)
Avril 1999 79
Java RMI Exemple : Serveur

fichier HelloServeur.java fichier HelloServeur.java import java.rmi.*; import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.rmi.server.UnicastRemoteObject; public class HelloServeur extends UnicastRemoteObject implements Hello { public class HelloServeur extends UnicastRemoteObject implements Hello { private String msg; private String msg; // Constructeur // Constructeur public HelloServeur(String msg) throws java.rmi.RemoteException { public HelloServeur(String msg) throws java.rmi.RemoteException { super(); super(); this.msg = msg; this.msg = msg; } } // Implmentation de la mthode distante. // Implmentation de la mthode distante. public String sayHello() throws java.rmi.RemoteException { public String sayHello() throws java.rmi.RemoteException { return "Hello world: ""+ msg; return "Hello world: + msg; } }
Avril 1999
Ralisation du serveur
80
40
8-9 avril 1999
Java RMI Exemple : Serveur

fichier HelloServeur.java fichier HelloServeur.java public static void main(String args[]) { public static void main(String args[]) { try { try { // Cre une instance de l lobjet serveur. // Cre une instance de objet serveur. HelloServeur obj = new HelloServeur("HelloServeur"); HelloServeur obj = new HelloServeur("HelloServeur"); // Enregistre l'objet crer auprs du serveur de noms. // Enregistre l'objet crer auprs du serveur de noms. Naming.rebind("//suldrun/mon_serveur", obj); Naming.rebind("//suldrun/mon_serveur", obj); System.out.println("HelloServer" + "" bound in registry"); System.out.println("HelloServer" + bound in registry"); } catch (Exception exc) { } } catch (Exception exc) { } } }
Ralisation du serveur (suite)
} }
ATTENTION : dans cet exemple le serveur de nom doit tre activ avant la cration du serveur
Avril 1999 81
Java RMI
Activation du serveur de nom par le serveur

public static void main(String args[]) { public static void main(String args[]) { int port; String URL; int port; String URL; fichier HelloServeur.java fichier HelloServeur.java
try { // transformation ddune chane de caractres en entier try { // transformation une chane de caractres en entier Integer II= new Integer(args[0]); Integer = new Integer(args[0]); port = I.intValue (); port = I.intValue (); } catch (Exception ex) { } catch (Exception ex) { System.out.println(" Please enter: Server <port>"); return; System.out.println(" Please enter: Server <port>"); return; } } try { try { // Cration du serveur de nom --rmiregistry // Cration du serveur de nom rmiregistry Registry registry = LocateRegistry.createRegistry(port); Registry registry = LocateRegistry.createRegistry(port);
Ralisation du serveur (autre approche)
// Cration d une instance de l lobjet serveur // Cration d une instance de objet serveur HelloServeur obj = new HelloServeur("Coucou, je suis le serveur de port ::"+port); HelloServeur obj = new HelloServeur("Coucou, je suis le serveur de port "+port); // Calcul de l l URL du serveur // Calcul de URL du serveur URL = "//"+InetAddress.getLocalHost().getHostName()+":"+port+"/mon_serveur"; URL = "//"+InetAddress.getLocalHost().getHostName()+":"+port+"/mon_serveur"; Naming.rebind(URL, obj); Naming.rebind(URL, obj); } catch (Exception exc) { ... } catch (Exception exc) { ...
Avril 1999
82
41
8-9 avril 1999
Java RMI Exemple : Client

fichier HelloClient.java fichier HelloClient.java import java.rmi.*; import java.rmi.*; public class HelloClient { public class HelloClient { public static void main(String args[]) { public static void main(String args[]) { try { try { // Rcupration d'un stub sur l'objet serveur. // Rcupration d'un stub sur l'objet serveur. Hello obj = (Hello) Naming.lookup("//suldrun/mon_serveur"); Hello obj = (Hello) Naming.lookup("//suldrun/mon_serveur"); // Appel d'une mthode sur l'objet distant. // Appel d'une mthode sur l'objet distant. String msg = obj.sayHello(); String msg = obj.sayHello(); // Impression du message. // Impression du message. System.out.println(msg); System.out.println(msg); } catch (Exception exc) { } } catch (Exception exc) { } } } } }
Avril 1999
Ralisation du client
83
Java RMI Compilation

z Compilation de l interface, du serveur et du client
y javac Hello.java HelloServeur.java HelloClient.java
z Gnration des talons

y rmic HelloServeur
skeleton dans HelloServeur_Skel.class stub dans HelloServeur_Stub.class.
Avril 1999
84
42
8-9 avril 1999
Java RMI Dploiement

z 1) Activation du serveur de nom
y start rmiregistry (W95) ou rmiregistry & (Unix)
z 2) Activation du serveur
y java HelloImpl y java -Djava.rmi.server.codebase=http://suldrun/
x path indiquant quelle endroit la machine virtuelle cliente va pouvoir chercher le code du stub x Ncessaire si le client et le serveur ne sont pas sur la mme station
z 3) Activation du client
y java HelloClient
Avril 1999 85
Java RMI
Principe de l appel de procdure
Java VM
Client
R_objet1.m ()
Java VM
R_objet1
m ()
Stub R_objet1
Skeleton R_objet1
Avril 1999
86
43
8-9 avril 1999
Java RMI
Passage en paramtre d un objet local
Java VM
O2 Client
R_objet1.m ( O2 ) m ( O2 )
Java VM
Objet objet1 clone_O2 Skeleton R_objet1
87
Stub R_objet1
Avril 1999
Java RMI
Objet O2
Passage en paramtre d un objet distant
Java VM
Stub R_O2
Java VM
Objet objet1
m ( R objet )
Client
R_objet1.m ( R O2 )
Stub R_objet1
Skeleton R_objet1
88
Avril 1999
44
8-9 avril 1999
Java RMI
Objet O2
Passage en paramtre d un objet distant
Java VM
Stub R_O2
Java VM
Objet objet1
m ( R objet )
Client
R_objet1.m ( R O2 )
Stub R_O2
Stub R_objet1
Skeleton R_objet1
89
Avril 1999
Chargement dynamique et scurit

z Si le code du stub n est pas prsent sur le site local, le protocole RMI prvoit le chargement dynamique du stub en utilisant un serveur web et le protocole HTTP
y java -Djava.rmi.server.codebase=http://suldrun/
z Si chargement dynamique
y le chargeur dynamique utilis par RMI (RMIClassLoader) regarde si la classe demande correspond au niveau de scurit requis
x utilisation d un SecurityManager
y crer et installer le gestionnaire de scurit x System.setSecurityManager(new RMISecurityManager());
Avril 1999
90
45
8-9 avril 1999
Java RMI : bilan

z Trs bon exemple de RPC
y facilit d utilisation y intgration au langage Java et l internet y utilisation de l apport de Java
x x x x x Htrognt des plateformes -> machine virtuelle Passage par valeur -> srialisation Persistance -> srialisation Absence de talon -> chargement dynamique Dsignation -> URL
z Des ouvertures
y Serveurs multiplexs ? y Smantique en cas de panne ? y Utilisation d autres protocoles rseaux ?
Avril 1999 91
RPC Autres mises en uvre

z Migration de code
y code et donnes de la procdure distante sont amens sur le site appelant pour y tre excuts en appel normal. y Avantages Inconvnients:
x univers de systmes homognes. x faible volume de codes et de donnes globales x exclusion mutuelle entre les excutions.
Avril 1999
92
46
8-9 avril 1999
RPC Autres mises en uvre

z Mmoire virtuelle rpartie
y Appel distant ralis au dessus d'une couche de mmoire virtuelle rpartie. L'appel se fait en mmoire comme si la procdure tait locale
x Analogie avec une stratgie de chargement de pages la demande : dfaut de page sur le dbut du code de la procdure
y Avantages Inconvnients
x x x x
Avril 1999
univers de systmes homognes. Permet les gros volume de codes ou donnes peu visit usage important de pointeurs. peu de problmes d'entrelacement sur les donnes globales.
93
Performances des RPCs [Schroeder & Burrows 90]

z Client (appel)
y y y y y y y y Programme appelant (boucle pour appel rptitif) Talon client (appel & retour) Initialisation de la connexion Envoie du paquet d'appel Rception du message Talon serveur (appel & retour) Excution d'un service nul (appel & retour) Envoie des rsultats
Microseconde
16 90 128 27 158 68 10 27 49 33
z Serveur
z Client (rception des rsultats)

y Rception des rsultats y Terminaison
z Total
Avril 1999
606
94
47
8-9 avril 1999
Performances des RPCs [Schroeder & Burrows 90]

z Null ()
y Appel serveur, stub et RPC runtime y Envoi/rception du paquet d'appel (74 octets) y Envoi/rception du paquet retour (74 octets)
Microsecondes
606 954 954
y Total z MaxResult (b)

y y y y Appel serveur, stub et RPC runtime Marshall 1440 octets pour le rsultat Envoi/rception du paquet d'appel (74 octets) Envoi/rception du paquet retour (1514 octets) 4414
2514
606 550 954
y Total
6524
Avril 1999
95
Facteurs d'amlioration [Schroeder & Burrows 90]

Vitesse processeurs X 3 Attente active Contrleur amlior Protocole transport en assembleur Protocole amlior Pas de contrler d'erreur Vitesse rseau X 10 Suppression des couches IP/UDP 0 octets 52 % 17 % 11 % 10 % 8% 7% 4% 4% 1440 octets 36 % 7% 28 % 4% 3% 16 % 18 % 1%
Avril 1999
96
48
8-9 avril 1999
Quelques travaux complmentaires

z Tendances
y Paralllisation, flots y Tolrance aux dfaillances y Intgration dans les langages de haut niveau y Amlioration des performances brutes y Usage local (appel entre contexte)
z Appels parallles
y [Satyanarayanan & Siegel 90]
z Flots
y Mercury [Liskov & Shrira 88]
z RPC "lger"
y [Bershad & al. 90]
Avril 1999
97
RPC sens unique

z Envoie d un message asynchrone pour dclencher une procdure
y la procdure ne doit pas avoir retourner des rsultats y rcupration d une rponse par un mcanisme similaire
x invocation d actions du client par le serveur x le client doit avoir prvu les actions correspondant aux diffrents types de rponses
y pas d information sur la terminaison du travail demand

x mais envoie d un message sous la forme syntaxique d un appel de procdure (qui ne doit pas avoir de rsultat rendre)
y c est le modle des langages acteurs

x ABCL, ACTALK, HYBRID
Avril 1999 98
49
8-9 avril 1999
RPC asynchrone
z Le client poursuit son excution aprs l mission du message d appel
y la procdure distante s excute en parallle avec la poursuite du client et retourne les paramtres rsultats en fin de son excution y le client rcupre les rsultats quand il en a besoin (primitive spciale) y avantage : paralllisme plus important y critique le client ne retrouve pas la smantique de l appel de procdure
Avril 1999
x contrle de la rcupration des rsultats : pb de synchronisation (risque d erreur)
99
Appel asynchrone avec futur

z Futur
y objet particulier pour la rcupration des rsultats y futur explicite :
x construction avant l appel de l objet dans lequel les rsultats seront dpos
y futur implicite :
x c est le mcanisme d appel qui construit les objets rsultats
y mode d utilisation :
x la lecture rend un rsultat nul si le rsultat n est pas disponible x la lecture bloque le client si le rsultat n est pas disponible
Avril 1999
100
50
8-9 avril 1999
Appel de procdure
z Appels de procdure imbriqus
Appel 1() dbut Appel2 () dbut fin Appel3() dbut fin
Schma d excution pouvant tre dduit

z Schma continuation
Appel 1() dbut Appel2 () dbut
fin fin
Avril 1999
101
Les limites du modle clientserveur

z modle de structuration
y permet de dcrire linteraction entre deux composants logiciels
x absence de vision globale de lapplication
y schma d'excution rpartie lmentaire (appel synchrone)

x absence de proprits portant sur la synchronisation, la protection, la tolrance aux pannes, . .
Avril 1999
102
51
8-9 avril 1999
Les limites du modle clientserveur

z services pour la construction dapplications rparties
y le RPC est un mcanisme de bas niveau y des services additionnels sont ncessaires pour la construction dapplications rparties (dsignation, fichiers rpartis, scurit, etc.)
x CORBA, EJB, ...
z outils de dveloppement
y limits la gnration automatique des talons y peu (ou pas) doutils pour le dploiement et la mise au point d'applications rparties
Avril 1999 103
Construction d applications rparties l aide des RPC

z ATTENTION : client-serveur (et objets rpartis) masquent la diffrence entre appel de procdure et appel de procdure distance
y une telle application prsente toutes le caractristiques d une application rpartie
x conception (et intgration de logiciel existant) x dsignation (et protection) x synchronisation (et contrle de la concurrence) x tolrance aux pannes (et disponibilit des services) x performances (et quilibrage de charge) x disponibilit d outils conviviaux pour la conception, le dploiement et la mise au point)
Avril 1999 104
52
8-9 avril 1999
Modle client-serveur Bibliographie

z A.D. Birrell and B.J. Nelson
y "Implementing remote procedure calls" ACM Trans. on Comp. Syst., vol. 2(1), pp. 39-59, February 1984
(Papier de rfrence) (Mesures) (RPC asynchrone)
M.D Schroeder and M. Burrows

y "Performance of Firefly RPC" ACM Trans. on Comp. S y s vol. 8(1), pp. 1-17, January 1990 ., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems" Proc. of SIGPLAN, pp. 260-267, 1988
B. Liskov and L. Shrira

y
B.N. Bershad, T.E. Anderson, E.D. Lazowska and H.M. Levy

y "Leightweight remote procedure call" ACM Trans. on Comp. S y s vol. 8(1), pp. 37-55, January 1990 .,
(RPC lger ) (Appels parallles)
Satyanarayanan & Siegel

y "Parallel Communication in a Large Distributed Environment" ACM Trans. on Comp., vol. 39(3), pp. 328-348, March 1990
Avril 1999
105
53

03 99 Slides Client Serveur

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03 99 Slides Client Serveur

Hochgeladen von

Copyright:

Verfügbare Formate

Modle Client-Serveur

8-9 avril 1999

Modle client-serveur Plan

y Travaux actuels y Conclusion y Bibliographie

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Modle client-serveur dfinition

communication par messages

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Modle client-serveur principe

Modle client-serveur exemple

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Modle client-serveur gestion des processus

Mise en uvre serveur unique

Slection requtes rponse

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Mise en uvre 1 processus par service

Mise en uvre 1 processus par service

z Cration dynamique des excutants

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Diffrents types de service

z solution trs favorable

Diffrents types de service

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Diffrents types de service

Diffrents types de service

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Appel de procdure distance (RPC)

z Objectifs trs difficiles atteindre

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

RPC : les piges

z Appel de procdure distance

y dans certains langages

RPC [Birrel & Nelson 84] Principe de ralisation

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

RPC (A) Principe de fonctionnement

RPC (B et C) Principe de fonctionnement

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

RPC (D) Principe de fonctionnement

RPC (E) Principe de fonctionnement

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

RPC Rle des talons

Talon serveur - skeleton z Cest la procdure sur le site serveur

z Dsignation et liaison, z Aspects pratiques

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Diffrents types de pannes

x risque dexcuter plusieurs fois la mme procdure

Diffrents types de pannes

y Pbs : ltat du client et du serveur peuvent devenir inconsistants

Copyright Michel Riveill, INP Grenoble, 1999

8-9 avril 1999

Smantique en cas d erreur

y Au plus une fois