Conception d'une application C/S

Modle de Gartner pour les systmes 3 niveaux (3-tiers) :

Client
Prsentation Prsentation Prsentation Logique Prsentation Logique Donnes

Serveur de milieu

Logique

Logique

Logique

Logique Donnes

Logique

Logique Donnes Donnes

Serveur

Donnes

Donnes

Les modes de communication

Communication en mode non connect

Client Rseau message requte Serveur prise en compte de la requte rveil du serveur

envoi d'une requte

rception du rsultat message rponse poursuite du traitement

excution requte

Les modes de communication

Communication en mode connect

Client demande de connexion Rseau message de connexion Serveur prise en compte de la connexion
Cration dun contexte

Emission de requtes Rception de rsultats Synchronisation message de dconnexion demande de dconnexion

Excution des requtes

prise en compte de la dconnexion

Libration du contexte

Serveur itratif ou concurrent

Serveur itratif

traite squentiellement les requtes adapt aux requtes qui peuvent s'excuter rapidement souvent utilis en mode non connect (recherche de la performance) le serveur accepte les requtes puis les "dlgue" un processus fils (traitement de plusieurs clients) adapt aux requtes qui demandent un certain traitement (le cot du traitement est suffisamment important pour que la cration du processus fils ne soit pas pnalisante) souvent utilis en mode connect

Serveur concurrent

Service avec ou sans tat(s)

Service avec tats

Service sans tat

le serveur conserve localement un tat pour chacun des clients connects : informations sur le client, les requtes prcdentes, le serveur ne conserve aucune information sur l'enchanement des requtes...

Incidence sur les performances et la tolrance aux pannes dans le cas o un client fait plusieurs requtes successives

performance --> service sans tat tolrance aux pannes --> service avec tats

Exemple : accs un fichier distant

RFS avec tats, NFS sans tat (pointeur de fichier)

Les communications inter-processus

Les schmas de communication

Ds lors qu'une application est rpartie, elle se dcompose en plusieurs processus qui doivent communiquer (changes de donnes) Deux grands types de schma de communication

communication par mmoire partage (ou fichier) communication par passage de messages dans des communications locales : entre processus s'excutant sur le mme hte dans des communications distantes : entre processus s'excutant sur des htes distants
62

On retrouve ces deux schmas de communication

Communication par mmoire partage

Les processus se partagent une zone de mmoire commune dans laquelle ils peuvent lire et/ou crire
P1
Zone de mmoire partage entre P1 et P2 write() read() read() write()

P2

Intrt : communications transparentes, limitation des copies mmoire Problme : gestion de l'accs une ressource partage

problme si deux critures simultanes (ordre dordonnancement, atomicit des oprations) les processus P1 et P2 doivent se synchroniser pour accder au tampon partag (verrou, smaphore, )
63

Communication par mmoire partage

Communications locales

les deux processus s'excutent sur la mme machine donc peuvent se partager une partie de leur espace d'adressage exemple : les threads s'excutent dans le contexte d'un mme processus la mmoire partage est physiquement rpartie le gestionnaire de mmoire virtuelle permet de regrouper les diffrents morceaux selon un seul espace d'adressage problme de cohrence mmoire...

Communications distantes

Les tubes de communication (pipes)

Communications locales type mmoire partage

le canal de communication est unidirectionnel (pas de problme de synchronisation) communications entre 2 processus uniquement : l'un crit dans le tube, l'autre lit
Cration du tube et des processus fils fork(); exec(); write()

Exemple : sh$ ls -l | wc -l
sh
fork(); exec(); read()

ls -l

wc -l

Communication par passage de msg

Les processus n'ont pas accs des "variables" communes Ils communiquent en s'changeant des messages

au moins deux primitives : send() et recv() des zones de mmoire locales chaque processus permettent l'envoi et la rception des messages l'metteur/rcepteur doit pouvoir dsigner le rcepteur/metteur distant zones d'mission et rception distinctes ? nombre d'metteurs/rcepteurs dans une zone ? oprations bloquantes/non bloquantes ?

Problmes

Communication par passage de msg

Il faut viter les critures concurrentes :

read/write read/write write

write

P2 P3
read

P1

P2

P1
read

Pour se ramener des communications point-point

--> dissocier le tampon d'mission et de rception --> avoir autant de tampons de rception que d'metteurs potentiels --> il ne reste plus alors au protocole qu' s'assurer que deux missions successives (d'un mme metteur) n'crasent pas des donnes non encore lues (contrle de flux)

Oprations bloquantes/non bloquantes

Quand un appel une primitive send() ou recv() doit-il se terminer ? Plusieurs smantiques en rception :

recv() peut rendre la main

aussitt (recv() non bloquant) quand les donnes ont t reues et recopies depuis le tampon de rception local (le tampon de rception est de nouveau libre)

Oprations bloquantes/non bloquantes

Plusieurs smantiques en mission :

send() peut rendre la main aussitt (send() non bloquant) quand les donnes ont t recopies dans le tampon d'mission local (les donnes peuvent tre modifies au niveau de l'application) quand les donnes ont t recopies dans le tampon de rception distant (le tampon d'mission local est de nouveau libre) quand le destinataire a consomm les donnes (le tampon de rception est de nouveau libre)

Oprations bloquantes

Le processus se bloque jusqu' ce que lopration se termine :

Application Middleware read() Appel systme

- Attente de l'arrive des donnes - Recopie dans le tampon de l'application

Retour

Oprations non bloquantes

Intrt :

le processus peut faire autre chose en attendant que les donnes soient mises ou reues

Le processus a tout de mme besoin d'tre inform de la compltion de l'opration (lecture ou criture) Deux possibilits :

attente active : appels rguliers la primitive jusqu' compltion attente passive : le systme informe le processus par un moyen quelconque de la compltion de l'opration (signaux par exemple)

Communication par signaux

Mcanisme de communications locales interprocessus (ou depuis le noyau vers un processus) permettant de notifier un vnement Principe : interruption logicielle quand l'vnement se produit Le processus

indique les signaux qu'il souhaite capter (provoquant son interruption) met en place un handler (fonction particulire) qui sera excut quand l'vnement se produira

Exemple : arrive de donnes urgentes sur une socket

Oprations non bloquantes

Application read()

Middleware Appel systme WOULDBLOCK

read()

Appel systme WOULDBLOCK Appel systme

Attente des donnes

read()

Recopie
Retour

Attente active

Oprations non bloquantes

Application signal() Middleware Activer SIGIO Retour

Attente des donnes

handler() read()

Signal SIGIO Appel systme

Recopie
Retour

Attente passive

Dsignation du destinataire/metteur

Pour faire du passage de messages, il est ncessaire de dsigner l'autre extrmit de la communication Dsignation explicite

du ou des processus destinataire(s)/metteurs recevoir un message de n'importe qui mettre un message n'importe qui (diffusion) une phase d'tablissement de connexion dsigne les deux entits communicantes

Dsignation implicite

Les sockets

Les sockets - adressage

Deux processus communiquent en mettant et recevant des donnes via les sockets Les sockets sont des portes d'entres/sorties vers le rseau (la couche transport) Une socket est identifie par une adresse de transport qui permet d'identifier les processus de l'application concerne Une adresse de transport = un numro de port (identifie l'application) + une adresse IP (identifie le serveur ou l'hte dans le rseau)

Les sockets - adressage

Le serveur doit utiliser un numro de port fixe vers lequel les requtes clientes sont diriges Les ports infrieurs 1024 sont rservs :

Les clients n'ont pas besoin d'utiliser des wellknown ports

"well-known ports" ils permettent d'identifier les serveurs d'applications connues ils sont attribus par l'IANA

ils utilisent un port quelconque entre 1024 et 65535 condition que le triplet <transport/@IP/port> soit unique ils communiquent leur numro de port au serveur lors de la requte ( l'tablissement de la connexion TCP ou dans les datagrammes UDP)

Les sockets en pratique

Une socket est un fichier virtuel avec les oprations d'ouverture, fermeture, criture, lecture, Ces oprations sont des appels systme Il existe diffrents types de socket associs aux diffrents services de transport :

stream sockets (connection-oriented) - SOCK_STREAM utilise TCP qui fournit un service de transport d'octets fiable, dans l'ordre, entre le client et le serveur datagram sockets (connectionless) - SOCK_DGRAM utilise UDP (transport non fiable de datagrammes) raw sockets - SOCK_RAW utilise directement IP ou ICMP (ex. ping)

Les sockets en pratique

Un descripteur de socket (sock_id) n'est qu'un point d'entre vers le noyau Processus client ou serveur Appel systme Bibliothque socket (API) write Couche socket du noyau TCP UDP ...
sock_id=2 read socket buffers

- la bibliothque socket est lie l'application

mission/rception d'un segment TCP, datagramme UDP...

- la couche socket du noyau ralise l'adaptation au protocole de transport utilis

Rappel - une connexion TCP

Une connexion = (proto, @IP_src, port_src, @IP_dest, port_dest)

Port 5004 Client @IP client Segment TCP dans un datagramme IP

L'appli crit L'appli lit

TCP send buffer IP TCP recv buffer

Contrle de flux : l'metteur ne sature pas le tampon de rception du rcepteur

L'appli crit L'appli lit Port 80

TCP send buffer IP TCP recv buffer

Serveur

Flux TCP

@IP serveur

En mode connect...

Pour que le client puisse contacter le serveur

Le client contacte le serveur

le processus serveur doit dj tourner le serveur doit avoir cr au pralable une socket pour recevoir les demandes de connexion des clients en crant une socket locale au client en spcifiant une adresse IP et un numro de port pour joindre le processus serveur

Le client demande alors l'tablissement d'une connexion avec le serveur Si le serveur accepte la demande de connexion

il cre une nouvelle socket permettant le dialogue avec ce client permet au serveur de dialoguer avec plusieurs clients

En mode connect...
socket()
Cration du descripteur local Demande d'ouverture de connexion Attachement d'un numro de port la socket Le serveur autorise NMAX connexions (le service est ouvert !) Le serveur accepte (ou attend) une connexion pendante et cre une nouvelle socket ddie au client

socket() connect()
Demande de connexion

bind() listen() accept() read()

Connexion ouverte

write()
Requte

Traitement de la requte

read()

Rponse

write()

En mode connect...
Paramtres en entre socket() bind() listen() connect() accept() read() write()
type, domaine, protocole sock_id, port sock_id, NMAX sock_id, @sock_dest sock_id client_sock_id, @recv_buf, lg client_sock_id, @send_buf, lg @sock_src, client_sock_id read_lg write_lg

Paramtres en sortie
sock_id

En mode connect...
Au retour d'accept() File des connexions en attente (pendantes) id=xxx

sock_id=xxx socket buffers

Processus client

id=xxx1

id=xxx2

TCP

port=yyy IP

Cr par listen() client1 client2

TCP

port=80 IP

Internet

En mode connect...

Attention : les missions/rceptions ne sont pas synchrones

read(m) : lecture d'au plus m caractres write(m) : criture de m caractres

N critures

write(m)

read(m)

N lectures

write(m) Ct mission Ct rception r1 r2

r3

r4

...

rN

r1+r2+r3+r4++rN <= N*m

En mode non connect...

Pour que le client puisse contacter le serveur

il doit connatre l'adresse de la socket du serveur le serveur doit avoir cr la socket de rception

Le client envoie sa requte en prcisant, lors de chaque envoi, l'adresse de la socket destinataire Le datagramme envoy par le client contient l'adresse de la socket mettrice (port, @IP) Le serveur traite la requte et rpond au client en utilisant l'adresse de la socket mettrice de la requte

En mode non connect...

socket()
Cration du descripteur local Attachement d'un numro de port la socket Le serveur est en attente d'une requte cliente Traitement de la requte Le serveur envoie la rponse

socket()

bind() recv_from()

Envoi de la requte Attente de la rponse

send_to()
Requte

recv_from()

Rponse

send_to()

En mode non connect...

Paramtres en entre socket() bind() recv_from() send_to()
type, domaine, protocole sock_id, port sock_id, @recv_buf, lg sock_id, @sock_dest, @send_buf, lg read_lg, @sock_src write_lg

Paramtres en sortie
sock_id

Rappel en mode connect : read() write()

client_sock_id, @recv_buf, lg client_sock_id, @send_buf, lg read_lg write_lg

En mode non connect...

sock_id=xxx socket buffers

Processus client
TCP TCP

Processus serveur

sock_id=zzz socket buffers port=80

port=yyy IP

IP

Internet

Serveur itratif en mode connect

socket() bind() listen() accept() read() write() close()
Processus serveur Le processus serveur : - attend une connexion cliente - lit la requte - traite la requte - envoie la rponse - ferme la connexion cliente

Traitement de la requte cliente

Serveur concurrent en mode connect

socket() bind() listen() accept()
cration thread ddi thread 1 thread 2 Processus serveur Le processus serveur : - attend une connexion cliente - cre un processus fils ou thread pour traiter le dialogue avec ce client et excuter sa requte

read()
Traitement de la requte cliente

read()
Traitement de la requte cliente

write() close()

write() close()

Oprations bloquantes/non bloquantes

Par dfaut, les primitives connect(), accept(), send_to(), recv_from(), read(), write() sont bloquantes

recv() sur un tampon vide attendra l'arrive des donnes pour rendre la main send() sur un tampon plein attendra que les donnes quitte le tampon pour rendre la main accept() ne rend la main qu'une fois une connexion tablie (bloque si pas de connexions pendantes) connect() ne rend la main qu'une fois la connexion cliente tablie (sauf si pas entre listen() et accept())

Oprations bloquantes/non bloquantes

Il est possible de paramtrer la socket lors de sa cration pour rendre les oprations non bloquantes Comportement d'une mission non bloquante

tout ce qui peut tre crit dans le tampon l'est, les caractres restants sont abandonns (la primitive retourne le nombre de caractres crits) si aucun caractre ne peut tre crit (tampon plein), retourne -1 avec errno=EWOULDBLOCK (l'application doit ressayer plus tard) s'il n'y a rien lire dans la socket, retourne -1 ... (l'application doit ressayer plus tard)

Comportement d'une lecture non bloquante

Oprations bloquantes/non bloquantes

Comportement vis vis de l'acceptation des connexions en mode non bloquant

s'il n'y a pas de connexion pendante, retourne -1 ... (l'application doit ressayer plus tard)

Comportement vis vis des demandes de connexions en mode non bloquant

la primitive connect() retourne immdiatement mais la demande de connexion n'est pas abandonne au niveau TCP...

Paramtrage des sockets

Les sockets sont paramtrables

fonctions setsockopt() et getsockopt() options boolennes et non boolennes diffusion (dgram uniquement ; remplace l'@IP destinataire par l'@ de diffusion de l'interface) keepalive : teste rgulirement la connexion (stream) tcpnodelay : force l'envoi des segments au fur et mesure des critures dans le tampon taille du tampon d'mission, taille du tampon de rception, type de la socket

Exemples d'options boolennes

Exemples d'options non boolennes

Les serveurs multi-protocoles

Un serveur qui offre le mme service en mode connect et non connect

exemple : DAYTIME (RFC 867) port 13 sur UDP et sur TCP qui permet de lire la date et l'heure sur le serveur 13/TCP : la demande de connexion du client dclenche la rponse ( une requte donc implicite) : le client nmet aucune requte 13/UDP : la version UDP de DAYTIME requiert une requte du client : cette requte consiste en un datagramme arbitraire qui nest pas lu par le serveur mais qui dclenche lmission de la donne ct serveur

Le serveur coute sur 2 sockets distinctes pour rendre le mme service

Les serveurs multi-protocoles

Pourquoi un serveur multi-protocoles ?

certains systmes ferment tout accs UDP pour des raisons de scurit (pare-feu) non duplication des ressources associes au service (corps du serveur) un seul processus utilisant des oprations non bloquantes de manire grer les communications la fois en mode connect et en mode non-connect deux implmentations possibles : en mode itratif et en mode concurrent

Fonctionnement

Les serveurs multi-protocoles

En mode itratif

le serveur ouvre la socket UDP et la socket TCP puis boucle sur des appels non bloquants accept() et recv_from() sur chacune des sockets si une requte TCP arrive le serveur utilise accept() provoquant la cration dune nouvelle socket servant la communication avec le client lorsque la communication avec le client est termine, le serveur ferme la socket "cliente" et ritre son attente sur les deux sockets initiales si une requte UDP arrive le serveur reoit et met des messages avec le client lorsque les changes sont termins, le serveur ritre son attente sur les deux sockets initiales

Les serveurs multi-protocoles

En mode concurrent

un automate gre l'arrive des requtes (primitives non bloquantes) cration dun nouveau processus fils pour toute nouvelle connexion TCP traitement de manire itrative des requtes UDP elles sont traites en priorit pendant ce temps, les demandes de connexion sont mises en attente

Les serveurs multi-services

Un serveur qui rpond plusieurs services (une socket par service) Pourquoi un serveur multi-services ?

problme li la multiplication des serveurs : le nombre de processus ncessaires et les ressources consommes qui y sont associes le code ralisant les services nest prsent que lorsquil est ncessaire la maintenance se fait sur la base du service et non du serveur : ladministrateur peut facilement activer ou dsactiver un service

Avantages

Les serveurs multi-services

Fonctionnement : lancement d'un programme diffrent selon la requte entrante

le serveur ouvre une socket par service offert, attend une connexion entrante sur lensemble des sockets ouvertes lorsquune demande de connexion arrive, le serveur cre un processus fils qui prend en compte la connexion le processus fils excute (via exec() sur systme UNIX) un programme ddi ralisant le service demand

Les serveurs multi-services

fork() serveu r fork() processus fils exec()
code ddi

processus fils exec()

code ddi

sockets : une par service

sockets : une par connexion

Les processus dmons

L'invocation d'un service Internet standard (FTP, TELNET, RLOGIN, SSH, ) ncessite la prsence ct serveur d'un processus serveur

qui tourne en permanence qui est en attente des requtes clientes

On parle de dmon A priori, il faudrait un dmon par service Problme : multiplication des services --> multiplication du nombre de dmons Sous UNIX, un super-dmon : inetd

Le dmon inetd

Un "super serveur"

un processus multi-services multi-protocoles un serveur unique qui reoit les requtes activation des services la demande permet d'viter d'avoir un processus par service, en attente de requtes une interface de configuration (fichier inetd.conf) permettant ladministrateur systme dajouter ou retirer de nouveaux services sans lancer ou arrter un nouveau processus

Le processus inetd attend les requtes l'aide de la primitive select() et cre un nouveau processus pour chaque service demand (except certains services UDP qu'il traite lui-mme)

Le fichier /etc/inetd.conf
# Internet services syntax : # <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args> # wait : pour un service donn, un seul serveur peut exister un instant donn # donc le serveur traite l'ensemble des requtes ce service # stream --> nowait : un serveur par connexion ftp stream tcp nowait root /etc/ftpd ftpd -l tftp dgram udp wait root /etc/tftpd tftpd shell stream tcp nowait root /etc/rshd rshd pop3 stream tcp nowait root /usr/local/lib/popper popper -s -d -t /var/log/poplog # internal services : # => service ralis par inetd directement time stream tcp nowait root internal time dgram udp nowait root internal

La scrutation de plusieurs sockets

Scrutation : mcanisme permettant l'attente d'un vnement (lecture, connexion, ) sur plusieurs points de communication

ncessaire dans le cas des serveurs multi-services ou multi-protocoles

Problme li aux caractres bloquants des primitives

exemple : une attente de connexion ( accept) sur une des sockets empche l'acceptation sur les autres rendre les primitives non bloquantes l'ouverture de la socket inconvnient : attente active (dans une boucle)

Premire solution

La scrutation de plusieurs sockets

Deuxime solution

Troisime solution : la primitive select()

crer un fils par socket pour la scrutation d'un service inconvnient : lourd, gaspillage de ressources mais avantage conserv d'activation la demande permet de raliser un multiplexage d'oprations bloquantes (scrutation) sur des ensembles de descripteurs passs en argument : descripteurs sur lesquels raliser une lecture descripteurs sur lesquels raliser une criture descripteurs sur lesquels raliser un test de condition exceptionnelle (arrive d'un caractre urgent) un argument permet de fixer un temps maximal d'attente avant que l'une des oprations souhaites ne soit possible

La scrutation de plusieurs sockets

La primitive select() rend la main quand une de ces conditions se ralise :

l'un des vnements attendus sur un descripteur de l'un des ensembles se ralise : les descripteurs sur lesquels l'opration est possible sont dans un paramtre de sortie le temps d'attente maximum s'est coul le processus a capt un signal (provoque la sortie de select())