SPAI C1 ArchiC S 6p

1
Partie 1 : Architecture et
communications Client/Serveur
Olivier GLCK
Universit LYON 1/Dpartement Informatique
Olivier.Gluck@univ-lyon1.fr
http://perso.univ-lyon1.fr/olivier.gluck
Olivier Glck - 2013 M2 SIR/RTS - Services et Protocoles Applicatifs sur Internet 2
Copyright
! Copyright 2013 Olivier Glck; all rights reserved
! Ce support de cours est soumis aux droits dauteur et nest
donc pas dans le domaine public. Sa reproduction est
cependant autorise condition de respecter les conditions
suivantes :
! Si ce document est reproduit pour les besoins personnels du
reproducteur, toute forme de reproduction (totale ou partielle) est
autorise la condition de citer lauteur.
! Si ce document est reproduit dans le but dtre distribu des tierces
personnes, il devra tre reproduit dans son intgralit sans aucune
modification. Cette notice de copyright devra donc tre prsente. De
plus, il ne devra pas tre vendu.
! Cependant, dans le seul cas dun enseignement gratuit, une
participation aux frais de reproduction pourra tre demande, mais elle
ne pourra tre suprieure au prix du papier et de lencre composant le
document.
! Toute reproduction sortant du cadre prcis ci-dessus est interdite
sans accord pralable crit de lauteur.
Remerciements
! Certains transparents sont bass sur des
supports de cours de :
! Olivier Aubert (LYON 1)
! Bndicte Le Grand (UPMC)
! Des figures sont issues des livres cits en
bibliographie
Plan de la premire partie
! Organisation pratique et contenu du module
! Bibliographie
! Quelques rappels : Internet et le modle TCP/IP
! Architecture Client/Serveur
! Communications inter-processus
! Les sockets
! Les appels de procdures distantes
Organisation pratique et contenu
du module
Les modules SPAI/AdminSR
! En SIR/RTS : 21h + 4h de cours + 6h de travaux pratiques
! La suite en SIR Admin Systmes : 12h de cours + 34h TP
(16h Admin. Unix + 18h Admin. Windows)
! Travaux pratiques :
! Salles Rseaux : TPR1, TPR2, TPR3 (Linux/Windows 2000)
! pas daccs extrieur
! possibilit de cblage
! root sur les machines
! SPAI en SIR/RTS : un contrle de fin de module (2 sessions)
! Admin. Systmes en SIR : plusieurs TPs nots + un petit
contrle (contrle continu donc pas de deuxime session)
2
Les modules SPAI et AdminSR : objectifs
! Former des administrateurs systmes et rseaux
! " connatre le modle Client/Serveur (90% des
applications de lInternet)
! " avoir des notions de conception dapplications
Client/Serveur
! " connatre les protocoles applicatifs de lInternet et
savoir mettre en place les services associs sous Linux
et sous Windows
! Dans Admin. Systmes (SIR) : une partie
spcifiquement Windows
! Jacques Delmas : 12h de cours et 18h de TPs
Le module SPAI : contenu (1)
! Modle Client/Serveur et applications
! Architecture et communication de type Client/Serveur
! Modle Client/Serveur, middleware
! Conception dune application Client/Serveur
! Les modes de communication entre processus
! Les sockets TCP/IP
! Les serveurs multi-protocoles et multi-services
! Les appels de procdures distantes, lexemple des
RPC
Le module SPAI : contenu (2)
! Applications Client/Serveur sur TCP/IP
! Connexions distance (telnet, rlogin, ssh, X11, )
! Transfert de fichiers et autres (FTP, TFTP, NFS, SMB)
! Gestion dutilisateurs distants (NIS)
! Le courrier lectronique (POP, IMAP, SMTP, WebMail)
! Les serveurs de noms (DNS)
! Un annuaire fdrateur (LDAP)
! Le web, protocole HTTP, serveur apache, caches Web
! Ladministration de rseaux et le protocole SNMP
! Les architectures pour le calcul et les communications
distribues (sil reste du temps)
Le module AdminSR : contenu
! Administration systme et rseaux des technologies
Windows NT (NT4, 2000, 2003 et XP) :
! Architecture en Domaines
! Gestion des utilisateurs (Active Directory)
! Profils errants, stratgie de groupe
! Systme de fichiers et scurit
! Services rseaux
! Scripts, base de registre
! Gestion des disques (partitions et raid)
! Sauvegardes et surveillance d'un parc, cluster
Bibliographie
! Rseaux , 4ime dition, Andrew Tanenbaum, Pearson
Education, ISBN 2-7440-7001-7
! La communication sous Unix , 2ime dition, Jean-Marie
Rifflet, Ediscience international, ISBN 2-84074-106-7
! Analyse structure des rseaux , 2ime dition, J. Kurose et
K. Ross, Pearson Education, ISBN 2-7440-7000-9
! TCP/IP Illustrated Volume 1, The Protocols , W. R. Stevens,
Addison Wesley, ISBN 0-201-63346-9
! TCP/IP, Architecture, protocoles, applications , 4ime
dition, D. Comer, Dunod, ISBN 2-10-008181-0
! Internet
! http://www.w3.org/
! http://www.rfc-editor.org/ (documents normatifs dans TCP/IP)
Quelques rappels : Internet et le
modle TCP/IP
3
Le visage de l'Internet (1)
! Un rseau de rseaux
! Un ensemble de logiciels et de protocoles
! Bas sur larchitecture TCP/IP
! Fonctionne en mode Client/Serveur
! Offre un ensemble de services (e-mail, transfert
de fichiers, connexion distance, WWW, )
! Une somme dinventions qui saccumulent
! mcanismes rseau de base (TCP/IP)
! gestion des noms et des adresses
! des outils et des protocoles spcialiss
! le langage HTML
! Une construction partir du bas
! rseau local (laboratoire, dpartement)
! rseau local (campus, entreprise)
! rseau rgional
! rseau national
! rseau mondial
! 3 niveaux dinterconnexion
! postes de travail (ordinateur, terminal...)
! liaisons physiques (cble, fibre, RTC...)
! routeurs (quipement spcialis, ordinateur...)
! Un ensemble de sous-rseaux indpendants
(Autonomous System) et htrognes qui sont
interconnects (organisation hirarchique)
S'articule autour de
plusieurs backbone
Modle Client/Serveur
Htrognit
Facteur d'chelle
ISP aux US
Point
d'interconnexion
Larchitecture de TCP/IP (1)
! Une version simplifie du modle OSI
! Application FTP, WWW, telnet, SMTP,
! Transport TCP, UDP (entre 2 processus aux extrmits)
! TCP : transfert fiable de donnes en mode connect
! UDP : transfert non garanti de donnes en mode non
connect
! Rseau IP (routage)
! Physique transmission entre 2 sites
TCP Transport Control Protocol
UDP User Datagram Protocol
IP Internet Protocol
IP
protocoles de contrle de l'Internet
TCP UDP
ICMP ARP RARP BOOTP DHCP
protocoles de
transfert
Logiciel (systme d'exploitation)
SLIP PPP
Rseaux locaux
Ethernet, Token Ring, ...
ATM FRelay
Matriel
HTTP FTP TELNET SMTP DNS SNMP
sockets
NFS
Applications (processus utilisateur)
...
rseau
transpo
rt
OSI
7
6
5
2
1
4
3
4
! Deux machines sur un mme sous rseau IP
IP
TCP
Rseau logique IP
Pilote
Ethernet
Client FTP
IP
TCP
Pilote
Ethernet
Serveur FTP
Sous-rseau de type
Ethernet
Ordinateur A Ordinateur B
Protocole FTP
Protocole TCP
Protocole IP
Protocole Ethernet
Linux
kernel
NIC
! Prise en compte de l'htrognit
IP
TCP
Pilote
Ethernet
Client FTP
IP
TCP
Pilote
Token Ring
Serveur FTP
sous-rseau de type
Token Ring
Ordinateur A Ordinateur B
Protocole FTP
TCP - contrle de bout en bout
Datagrammes
IP
trames
Ethernet
Linux
kernel
NIC
IP
Ether Token
sous-rseau de type
Ethernet
trames
Token Ring
De proche en
proche
routeur
! IP - protocole d'interconnexion, best-effort
! acheminement de datagrammes (mode non connect)
! peu de fonctionnalits, pas de garanties
! simple mais robuste (dfaillance d'un nud intermdiaire)
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
Nud intermdiaire : routeur
(matriel ou logiciel)
datagramme
Couche rseau : communications entre machines
! TCP - protocole de transport de bout en bout
! uniquement prsent aux extrmits
! transport fiable de segments (mode connect)
! protocole complexe (retransmission, gestion des
erreurs, squencement, )
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
datagramme
Nud d'extrmit
(end systems)
TCP
TCP TCP
TCP
Flux TCP
Couche transport : communications entre applis
IP
TCP
Pilote
Ethernet
Serveur FTP
donnes
utilisateur
en-tte
applicatif
donnes applicatives
en-tte
TCP
donnes applicatives
en-tte
TCP
en-tte
IP
donnes applicatives
en-tte
TCP
en-tte
IP
en-tte
Ethernet
en-queue
Ethernet
message
segment
datagramme
trame
Identification des protocoles (1)
IP
TCP
Ethernet ou
SNAP
Numro de
port (dans
l'en-tte TCP
ou UDP)
Identifiant de protocole
(dans l'en-tte IP)
EtherType (dans
l'en-tte de la trame)
ICMP ARP RARP
UDP
HTTP FTP TELNET SMTP DNS SNMP ...
port=161
BOOTP
port=67 ou 68 port=53
port=25
port=23
port=21
port=80
proto=6 proto=17
proto=1
type=0x800
type=0x806
type=0x835
5
! Une adresse de transport = une adresse IP + un
numro de port (16 bits) -> adresse de socket
! Une connexion s'tablit entre une socket source et
une socket destinataire -> une connexion = un
quintupl (proto, @src, port src, @dest, port dest)
! Deux connexions peuvent aboutir la mme
socket
! Les ports permettent un multiplexage ou
dmultiplexage de connexions au niveau transport
! Les ports infrieurs 1024 sont appels ports
rservs
Le protocole UDP
! UDP (RFC 768) - User Datagram Protocol
! protocole de transport le plus simple
! service de type best-effort (comme IP)
! les segments UDP peuvent tre perdus
! les segments UDP peuvent arriver dans le dsordre
! mode non connect : chaque segment UDP est trait
indpendamment des autres
! Pourquoi un service non fiable sans connexion ?
! simple donc rapide (pas de dlai de connexion, pas
d'tat entre metteur/rcepteur)
! petit en-tte donc conomie de bande passante
! sans contrle de congestion donc UDP peut mettre
aussi rapidement qu'il le souhaite
Les utilisations d'UDP
! Performance sans garantie de dlivrance
! Souvent utilis pour les applications multimdias
! tolrantes aux pertes
! sensibles au dbit
! Autres utilisations d'UDP
! applications qui envoient peu de donnes et qui ne
ncessitent pas un service fiable
! exemples : DNS, SNMP, BOOTP/DHCP
! Transfert fiable sur UDP
! ajouter des mcanismes de compensation de pertes
(reprise sur erreur) au niveau applicatif
! mcanismes adapts l'application
Le datagramme UDP
Checksum UDP Longueur segment
Donnes applicatives (message)
32 bits
Port destination Port source
8 octets
Taille totale du segment
(en-tte+donnes)
Total de contrle du segment
(en-tte+donnes)
optionnel : peut tre 0
UDP = IP + multiplexage (adresse de transport) !!
Le protocole TCP
! Transport Control Protocol (RFC 793, 1122, 1323, 2018,
2581)
! Transport fiable en mode connect
! point point, bidirectionnel : entre deux adresses de
transport (@IP src, port src) --> (@IP dest, port dest)
! transporte un flot d'octets (ou flux)
! l'application lit/crit des octets dans un tampon
! assure la dlivrance des donnes en squence
! contrle la validit des donnes reues
! organise les reprises sur erreur ou sur temporisation
! ralise le contrle de flux et le contrle de congestion
( l'aide d'une fentre d'mission)
Attention: les RFCs ne spcifient pas tout - beaucoup de
choses dpendent de l'implmentation
6
Exemples de protocole applicatif (1)
! HTTP - HyperText Transport Protocol
! protocole du web
! change de requte/rponse entre un client et un
serveur web
! FTP - File Transfer Protocol
! protocole de manipulation de fichiers distants
! transfert, suppression, cration,
! TELNET - TELetypewriter Network Protocol
! systme de terminal virtuel
! permet l'ouverture d'une session distante
Exemples de protocole applicatif (2)
! SMTP - Simple Mail Transfer Protocol
! service d'envoi de courrier lectronique
! rception (POP, IMAP, IMAPS, )
! DNS - Domain Name System
! assure la correspondance entre un nom symbolique
et une adresse Internet (adresse IP)
! bases de donnes rparties sur le globe
! SNMP - Simple Network Management Protocol
! protocole d'administration de rseau (interrogation,
configuration des quipements, )
! Les sockets - interface de programmation permettant
l'change de donnes (via TCP ou UDP)
Architecture Client/Serveur
Les applications rseau (1)
! Applications = la raison d'tre des rseaux infos
! Profusion d'applications depuis 30 ans grce
l'expansion d'Internet
! annes 1980/1990 : les applications "textuelles"
! messagerie lectronique, accs des terminaux
distants, transfert de fichiers, groupe de discussion
(forum, newsgroup), dialogue interactif en ligne
(chat), la navigation Web
! plus rcemment :
! les applications multimdias : vido la demande
(streaming), visioconfrences, radio et tlphonie sur
Internet
! la messagerie instantane (ICQ, MSN Messenger)
! les applications Peer-to-Peer (MP3, )
Les applications rseau (2)
! L'application est gnralement rpartie (ou
distribue) sur plusieurs systmes
! Exemples :
! L'application Web est constitue de deux logiciels
communiquants : le navigateur client qui effectue une
requte pour disposer d'un document prsent sur le
serveur Web
! L'application telnet : un terminal virtuel sur le client, un
serveur telnet distant qui excute les commandes
! La visioconfrence : autant de clients que de
participants
! --> Ncessit de disposer d'un protocole de
communication applicatif !
Terminologie des applications rseau
! Processus :
! une entit communicante
! un programme qui s'excute sur un hte d'extrmit
! Communications inter-processus locales :
! communications entre des processus qui s'excutent
sur un mme hte
! communications rgies par le systme d'exploitation
(tubes UNIX, mmoire partage, )
! Communications inter-processus distantes :
! les processus s'changent des messages travers le
rseau selon un protocole de la couche applications
! ncessite une infrastructure de transport sous-jacente
7
Protocoles de la couche Applications
! Le protocole applicatif dfinit :
! le format des messages changs entre les processus
metteur et rcepteur
! les types de messages : requte, rponse,
! l'ordre d'envoi des messages
! Exemples de protocoles applicatifs :
! HTTP pour le Web, POP/IMAP/SMTP pour le courrier
lectronique, SNMP pour l'administration de rseau,
! Ne pas confondre le protocole et l'application !
! Application Web : un format de documents (HTML),
un navigateur Web, un serveur Web qui on
demande un document, un protocole (HTTP)
Le modle Client / Serveur
! Ide : l'application est rpartie sur diffrents
sites pour optimiser le traitement, le stockage...
! Le client
! effectue une demande de service auprs du serveur
(requte)
! initie le contact (parle en premier), ouvre la session
! Le serveur
! est la partie de l'application qui offre un service
! est l'coute des requtes clientes
! rpond au service demand par le client (rponse)
! Le client et le serveur ne sont pas identiques, ils
forment un systme coopratif
! les parties client et serveur de l'application peuvent
s'excuter sur des systmes diffrents
! une mme machine peut implanter les cts client ET
serveur de l'application
! un serveur peut rpondre plusieurs clients
simultanment
Des clients et des serveurs...
Un client, un serveur :
Plusieurs clients, un serveur :
Client Serveur
Client Matre
Esclave Esclave
Client
Un client, plusieurs serveurs :
Client Serveur Serveur
Requte/Rponse
Le serveur contact peut faire appel un
service sur un autre serveur (ex. SGBD)
Le serveur traite plusieurs requtes
simultanes
Processus
client
Processus
serveur
Systme
(OS)
Matriel
Systme
(OS)
Matriel
Application C/S
Protocole applicatif
Rseau
Navigateur
Serveur
Apache
Windows
Modem
ADSL
Linux
Ethernet
Le Web
HTTP
Internet
L'application est rpartie sur
le client et le serveur qui
dialoguent selon un protocole
applicatif spcifique
L'exemple du Web
Applications
Transport
Rseau
Liaison
Physique
Applications
Transport
Rseau
Liaison
Physique
Applications
Transport
Rseau
Liaison
Physique
Serveur
Client A
Client B
modem
Systme autonome
rponse
Partie cliente de
l'application
Partie serveur de
l'application
requte
8
Exemple d'application client/serveur
! Le client lit une ligne partir de l'entre standard
(clavier) et l'envoie au serveur
! Le serveur lit la ligne reue et la convertit en
majuscules
! Le serveur renvoie la ligne au client
! Le client lit la ligne reue et l'affiche sur la sortie
standard (cran)
Exemple d'application client/serveur
! DAYTIME (RFC 867) permet au client d'obtenir la
date et l'heure du serveur
! Le protocole spcifie
! l'change des messages :
! ds qu'un serveur reoit un message d'un client, il
renvoie une chane de caractres contenant la date et
l'heure
! le contenu du message client n'est mme pas regard
! le format de la chane renvoye : 1 ligne ASCII
! Par exemple "Weekday, Month Day, Year Time-Zone "
"Tuesday, February 22, 1982 17:37:43-PST "
Interface de programmation rseau
! Il faut une interface entre l'application rseau et
la couche transport
! le transport n'est qu'un tuyau (TCP ou UDP dans
Internet)
! l'API (Application Programming Interface) n'est que le
moyen d'y accder (interface de programmation)
! Les principales APIs de l'Internet
! les sockets
! apparus dans UNIX BSD 4.2
! devenus le standard de fait
! les RPC : Remote Procedure Call - appel de
procdures distantes
Interface de programmation rseau
Processus
client
Processus
serveur
TCP/IP
Matriel
TCP/IP
Matriel
Application C/S
Protocole applicatif
Internet
socket socket
Du ressort du
dveloppeur de
l'application
Du ressort du
systme
d'exploitation
Interface d'accs
au transport
Une socket : interface locale l'hte, cre par l'application, contrle par l'OS
Porte de communication entre le processus client et le processus serveur
Application C/S - rcapitulatif
! Une application Client/Serveur, c'est
! une partie cliente qui excute des requtes vers un
serveur
! une partie serveur qui traite les requtes clientes et
y rpond
! un protocole applicatif qui dfinit les changes
entre un client et un serveur
! un accs via une API (interface de programmation)
la couche de transport des messages
! Bien souvent les parties cliente et serveur ne
sont pas crites par les mmes programmeurs
(Navigateur Netscape/Serveur apache) --> rle
important des RFCs qui spcifient le protocole !
Client Serveur
Middleware
Rseau
Le Middleware
! Grossirement : la gestion du protocole applicatif
+l'API d'accs la couche transport+des services
complmentaires
! C'est un ensemble de services logiciels construits
au dessus d'un protocole de transport afin de
permettre l'change de requte/rponse entre le
client et le serveur de manire transparente
9
Le Middleware
! Complment de services du rseau permettant la
ralisation du dialogue client/serveur :
! prend en compte les requtes de lapplication cliente
! les transmet de manire transparente travers le
rseau jusquau serveur
! prend en compte les donnes rsultat du serveur et
les transmet vers lapplication cliente
! Lobjectif essentiel du middleware est doffrir
aux applications une interface unifie permettant
laccs lensemble des services disponibles sur
le rseau : lAPI
Fonctions dun Middleware
! Procdures dtablissement/fermeture de connexion
! Excution des requtes, rcupration des rsultats
! Initiation des processus sur diffrents sites
! Services de rpertoire
! Accs aux donnes distance
! Gestion d'accs concurrents
! Scurit et intgrit (authentification, cryptage, )
! Monitoring (compteurs, )
! Terminaison de processus
! Mise en cache des rsultats, des requtes
Condor pools
of
workstations
tertiary storage clusters
n
a
t
io
n
a
l
s
u
p
e
r
c
o
m
p
u
t
e
r

f
a
c
ilit
ie
s
B
a
s
i
c

G
r
i
d

S
e
r
v
i
c
e
s
...
Resource
Discovery
Uniform Data
Access
Monitoring and
Events
P
o
r
t
a
l
s
Resource
brokering

Workflow
management
--------
Fault
management
Authorization
--------
Accounting
Data replication and
metadata management
--------
Grid MPI
--------
CORBA, DCOM,
Encapsulation as Web Services, as Script Based Services, as Java Based Services
Portals that are Web Services based, shell scripts,
specialized (e.g. high end vis workstations, PDAs)
. . .
A
d
v
a
n
c
e
d

S
e
r
v
i
c
e
s
Applications

Architecture of a Grid
scientific
instruments
D
i
s
t
r
i
b
u
t
e
d

R
e
s
o
u
r
c
e
s
Resource access
and functionality
Resource access
and functionality
Resource access
and functionality
Resource access
and functionality
Resource access
and functionality
Uniform
Computing
Access
Resource
Scheduling

Visualization
--------
Data analysis
--------
Data integration
--------
Collaboration tools
Authentication
Encapsulation as Web Services, as Script Based Services, as Java Based Services
O
p
e
r
a
t
i
o
n
a
l

S
u
p
p
o
r
t
space-based networks optical networks Internet
Identity
Credentials
Communications
job initiation, event generators, GridFTP servers
Grid Services Application Services
Grid Communication Functions (transport services, security services)
Conception d'une application C/S
! Comment dcouper une application informatique
en clients et serveurs ?
! Une application informatique est reprsente
selon un modle en trois couches :
! la couche prsentation (interface Homme/Machine) :
! gestion de laffichage
! la couche traitements (ou logique) qui assure la
fonctionnalit intrinsque de lapplication (algorithme)
! la couche donnes qui assure la gestion des donnes
de l'application (stockage et accs)
! Exemples de dcoupage Client/Serveur :
! le module de gestion des donnes peut tre hberg
par un serveur distant (SGBD, serveur web)
! le module de gestion de laffichage peut galement
tre gr par un serveur distant (un terminal X par
exemple)
X Window
Prsentation
Logique
Donnes
Prsentation
Le web
Prsentation
Logique
Logique
Donnes
Applets, JavaScript,
PHP, CGI, Servlets,
BD distribue Serveur de fichiers
Prsentation
Logique
Donnes
Prsentation
Logique
Donnes
Donnes
mulation de terminaux
Prsentation
Logique
Donnes
telnetd
! Autres exemples
10
Prsentation
Logique
Donnes
Donnes
Prsentation
Logique
Donnes
Prsentation
Logique
Logique
Donnes
Prsentation
Logique
Donnes
BD
rparties
Classe 1
Donnes
distantes
Classe 2
Transactions
rparties
Classe 3
Prsentations
distantes
Classe 4
Prsentation
Logique
Donnes
Prsentations
rparties
Classe 5
Prsentation
Client
Serveur
! Modle de Gartner pour les systmes 2 niveaux
(2-tiers) :
! Modle de Gartner pour les systmes 3 niveaux
(3-tiers) :
Client
Serveur de milieu
Serveur
Prsentation
Logique
Donnes
Prsentation
Logique
Donnes
Logique
Prsentation
Logique
Donnes
Logique
Prsentation
Logique
Donnes
Logique
Donnes
Donnes
Logique
Client Rseau Serveur
envoi d'une requte
message requte
prise en compte de
la requte
rveil du serveur
excution requte
message rponse
rception du rsultat
poursuite du traitement
Les modes de communication
! Communication en mode non connect
Client Rseau Serveur
demande de
connexion
message de connexion
prise en compte de
la connexion
Cration dun contexte
Excution des
requtes
Emission de requtes
Rception de rsultats
Synchronisation
demande de
dconnexion
message de dconnexion
prise en compte de
la dconnexion
Libration du contexte
Les modes de communication
! Communication en mode connect
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)
! Serveur concurrent
! 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
Service avec ou sans tat(s)
! Service avec tats
! le serveur conserve localement un tat pour chacun
des clients connects : informations sur le client, les
requtes prcdentes,
! Service sans tat
! 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)
11
Les communications inter-processus
Clusters
Cluster Architecture
Sequential Applications
Parallel Applications
Parallel Programming Environment
Cluster Middleware
(Single System Image and Availability Infrastructure)
Cluster Interconnection Network/Switch
PC/Workstation

Network Interface
Hardware
Communications
Software
PC/Workstation

Network Interface
Hardware
Communications
Software
PC/Workstation

Network Interface
Hardware
Communications
Software
PC/Workstation

Network Interface
Hardware
Communications
Software
Modle de fonctionnement
Application
Interface Socket
(Bibliothque standard)
Middleware (MPI, VIA, ...)
Bibliothque spcifique
UDP TCP
IP
Ethernet Pilote spcifique
Firmware
Carte rseau
Noyau
OS-Bypass
Initialisation
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
! On retrouve ces deux schmas de communication
! dans des communications locales : entre processus
s'excutant sur le mme hte
! dans des communications distantes : entre
processus s'excutant sur des htes distants
Communication par mmoire partage
! Les processus se partagent une zone de
mmoire commune dans laquelle ils peuvent lire
et/ou crire
P1 P2
Zone de mmoire partage
entre P1 et P2
write()
read() write()
read()
! 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, )
12
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
! Communications distantes
! 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...
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
! Exemple : sh$ ls -l | wc -l
ls -l wc -l
Cration du tube et des processus fils
write() read()
sh fork();
exec();
fork();
exec();
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
! Problmes
! zones d'mission et rception distinctes ?
! nombre d'metteurs/rcepteurs dans une zone ?
! oprations bloquantes/non bloquantes ?
Communication par passage de msg
! Il faut viter les critures concurrentes :
! 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)
P1 P2
read/write read/write
P1
write
read
write
P2
read
P3
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)
! 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)
13
Appel systme
- Attente de l'arrive des
donnes
- Recopie dans le tampon de
l'application
Middleware
Retour
read()
Oprations bloquantes
! Le processus se bloque jusqu' ce que
lopration se termine :
Application
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 inter-
processus (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
Appel systme
Appel systme
Appel systme
WOULDBLOCK
WOULDBLOCK
Retour
Attente des
donnes
Recopie
Attente active
read()
read()
read()
Middleware Application
Activer SIGIO
Appel systme
Retour
Signal SIGIO
Retour
signal()
handler()
read()
Attente passive
Attente des
donnes
Recopie
Middleware Application
Emission bloquante
Donnes
sk_buff
Application
Carte rseau
Noyau
Appel systme
Copie
Envoi Retransmission
Interruption
14
Rception bloquante
Donnes
sk_buff
Application
Carte rseau
Noyau
Appel systme
Copie
Dbut du message Fin
Interruption
Tampon
Emission non-bloquante
Donnes
Application
Carte rseau
Noyau
Envoi Retransmission
Soumission MPI Notification
Rception non-bloquante
Donnes
Application
Carte rseau
Noyau
Message
Soumission MPI Notification Attente
Tampon
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
! Dsignation implicite
! 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
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)
15
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 :
! "well-known ports"
! ils permettent d'identifier les serveurs d'applications
connues
! ils sont attribus par l'IANA
! Les clients n'ont pas besoin d'utiliser des well-
known ports
! 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)
Couche socket du noyau
Les sockets en pratique
Processus client ou serveur
TCP
Bibliothque socket (API)
Un descripteur de socket (sock_id) n'est qu'un point
d'entre vers le noyau
UDP ...
Appel systme
- la bibliothque socket est lie l'application
- la couche socket du noyau ralise l'adaptation au protocole de
transport utilis
read
socket buffers
sock_id=2
write
mission/rception d'un segment
TCP, datagramme UDP...
L'appli crit
L'appli lit
L'appli crit
L'appli lit
Port 5004
Rappel - une connexion TCP
! Une connexion = (proto, @IP_src, port_src, @IP_dest, port_dest)
TCP send buffer
TCP recv buffer
IP
Contrle de flux : l'metteur ne
sature pas le tampon de rception
du rcepteur
Client
TCP send buffer
TCP recv buffer
IP
Serveur
Segment TCP
dans un data-
gramme IP
Flux TCP
@IP client
@IP serveur
Port 80
En mode connect...
! Pour que le client puisse contacter 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
! Le client contacte le serveur
! 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()
connect()
write()
read()
socket()
bind()
accept()
read()
listen()
write()
Cration du
descripteur local
Demande
d'ouverture de
connexion
Connexion ouverte
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
Requte
Rponse
Traitement de la requte
Demande de
connexion
16
En mode connect...
connect()
socket()
bind()
accept()
read()
listen()
write()
type, domaine, protocole
Paramtres en entre Paramtres en sortie
sock_id
sock_id, port
sock_id, NMAX
sock_id, @sock_dest
sock_id @sock_src, client_sock_id
client_sock_id, @recv_buf, lg read_lg
client_sock_id, @send_buf, lg write_lg
En mode connect...
Processus
client
Internet
File des connexions
en attente
(pendantes)
socket buffers
sock_id=xxx
port=yyy
TCP
IP
TCP
IP
id=xxx2 id=xxx1 id=xxx
client1
client2
port=80
Cr par
listen()
Au retour
d'accept()
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
write(m) read(m) N critures N lectures
r1+r2+r3+r4++rN <= N*m
write(m)
Ct mission
m m m m m
Ct rception
r1 r2 r3 r4 rN ...
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
socket()
send_to()
recv_from()
socket()
bind()
recv_from()
send_to()
Cration du
descripteur local
Attachement d'un numro
de port la socket
Le serveur est en
attente d'une
requte cliente
Requte
Rponse
Traitement de la
requte
Le serveur envoie la
rponse
Envoi de la
requte
Attente de la
rponse
send_to()
socket()
bind()
read()
recv_from()
write()
type, domaine, protocole
Paramtres en entre Paramtres en sortie
sock_id
sock_id, port
sock_id, @recv_buf, lg
sock_id, @sock_dest,
@send_buf, lg
Rappel en mode connect :
client_sock_id, @recv_buf, lg read_lg
client_sock_id, @send_buf, lg write_lg
read_lg, @sock_src
write_lg
17
Processus
client
Internet
socket buffers
sock_id=xxx
port=yyy
UDP
IP
Processus
serveur
socket buffers
sock_id=zzz
port=80
UDP
IP
Serveur itratif en mode connect
socket()
bind()
accept()
read()
listen()
write()
Traitement de la requte cliente
Processus
serveur
close()
Le processus serveur :
- attend une connexion cliente
- lit la requte
- traite la requte
- envoie la rponse
- ferme la connexion cliente

Serveur concurrent en mode connect
socket()
bind()
accept()
listen()
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()
write()
Traitement de la
requte cliente
close()
thread 1
read()
write()
Traitement de la
requte cliente
close()
thread 2
cration
thread ddi
! 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())
! 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)
! Comportement d'une lecture non bloquante
! s'il n'y a rien lire dans la socket, retourne -1 ...
(l'application doit ressayer plus tard)
! 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...
18
Paramtrage des sockets
! Les sockets sont paramtrables
! fonctions setsockopt() et getsockopt()
! options boolennes et non boolennes
! Exemples d'options 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
! Exemples d'options non boolennes
! taille du tampon d'mission, taille du tampon de
rception, type de la socket
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
! 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)
! Fonctionnement
! 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
! 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
! 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
! Avantages
! 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
19
! 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
serveur
processus
fils
processus
fils
code
ddi
code
ddi
sockets : une
par service
sockets : une par connexion
exec()
exec()
fork()
fork()
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
! Premire solution
! rendre les primitives non bloquantes l'ouverture de la
socket
! inconvnient : attente active (dans une boucle)
20
! Deuxime solution
! crer un fils par socket pour la scrutation d'un service
! inconvnient : lourd, gaspillage de ressources
! mais avantage conserv d'activation la demande
! Troisime solution : la primitive select()
! 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 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())
Les appels de procdures distantes
Deux approches de conception
! Un concepteur dapplication distribue peut
procder selon deux approches :
! conception oriente communication :
! dfinition du protocole dapplication (format et syntaxe
des messages) inter-oprant entre le client et le serveur
! conception des composants serveur et client, en
spcifiant comment ils ragissent aux messages
entrants et gnrent les messages sortants
! conception oriente application :
! construction dune application conventionnelle, dans un
environnement mono-machine
! subdivision de lapplication en plusieurs modules qui
pourront sexcuter sur diffrentes machines
Principe gnral
! Souvent, quand un client envoie une requte (des
paramtres), il est bloqu jusqu' la rception
d'une rponse
! Analogie avec un appel de fonction
! la fonction ou procdure ne rend la main au programme
appelant qu'une fois le traitement (calcul) termin
! RPC - Remote Procedure Call
! permettre un processus de faire excuter une fonction
par un autre processus se trouvant sur une machine
distante
! se traduit par l'envoi d'un message contenant
l'identification de la fonction et les paramtres
! une fois le traitement termin, un message retourne le
rsultat de la fonction l'appelant
Principe gnral
! L'objectif des RPC est de faire en sorte qu'un
appel distant ressemble le plus possible un
appel local
! Le processus client (l'appelant) est li une
petite procdure de bibliothque, appele stub
client, qui reprsente la procdure du serveur
dans l'espace d'adressage du client
! Le processus serveur (l'excutant) est li un
stub serveur qui reprsente l'excution du client
! Dissimule le fait que l'appel de la procdure n'est
pas local : le programmeur de l'application utilise
un appel de procdure "normal" !
21
procA()
return
procB()
return return
Machine 1 Machine 2 Machine 3
rseau rseau
Programme
principal
Procdure A
(serveur)
Procdure B
(serveur)
Le modle RPC
Assemblage Dsassemblage
SendRequest() ReceiveResponse()
Application
Appel
Procdure
Retour
Procdure
Assemblage Dsassemblage
SendResponse() ReceiveRequest()
Procdure
Retour
Procdure
Excuter
Procdure stub client stub serveur
Client Serveur
RPC
Le modle RPC
1
2
3
4
Noyau
Rseau
5
7 8
9 6
10
11
12
13
14
L'interface RPC
! Intrts :
! l'application n'a pas manipuler directement les sockets
(le transport des donnes est transparent)
! l'implmentation des RPC est indpendante de l'OS
! Inconvnient :
! l'utilisation des RPC est moins performante que l'utilisation
directe des sockets (couches supplmentaires)
socket
API socket
Application
TCP
RPC/XDR
UDP
Interface RPC
Client
Client stub
Librairie RPC
Message RPC
au format XDR (call)
(reply)
Serveur
Server stub
Librairie RPC
Sockets TCP ou UDP
Restrictions lies aux RPC
! Pas de passage de paramtres par adresse :
impossible de passer des pointeurs (ou
rfrences)
! en effet, les espaces d'adressage du client et du
serveur sont diffrents donc aucun sens de passer
une adresse
! La procdure distante n'a pas accs aux
variables globales du client, aux priphriques
d'E/S (affichage d'un message d'erreur !)
! Un appel de procdure obit fonctionnement
synchrone : une instruction suivant un appel de
procdure ne peut pas sexcuter tant que la
procdure appele nest pas termine
Le protocole RPC
! Il doit dfinir le format du call (message du
client vers le serveur), le format des arguments
de la procdure, le format du reply (rsultats)
! Il doit permettre d'identifier la procdure
excuter par le serveur quand un call arrive
! Il doit permettre d'authentifier la demande
(problmes de scurit)
! Quelles machines distantes sont autorises excuter
la procdure ?
! Quels utilisateurs sont autoriss excuter la
procdure ?
L'implmentation de SUN
! Sun Microsystems a dvelopp une technologie RPC
dite Sun RPC devenue aujourdhui un standard
de fait
! NFS (Network File Sytem) repose sur les Sun RPC
! Les Sun RPC dfinissent :
! le format des messages que lappelant (stub client) met
pour dclencher la procdure distante sur un serveur
! le format des arguments de la procdure
! le format des rsultats de la procdure
! Possibilit d'utiliser UDP ou TCP pour les
communications
! XDR assiste les RPC pour assurer le fonctionnement
dans un environnement htrogne (reprsentation
standard des arguments et rsultats)
22
Identification des procdures distantes
! Un programme distant correspond un serveur avec
ses procdures et ses donnes propres
! Chaque programme distant est identifi par un entier
unique cod sur 32 bits utilis par lappelant
! Les procdures dun programme distant sont
identifies squentiellement par les entiers 0, 1, ..., N
! Une procdure distante est identifie par le triplet
(program, version, procedure)
! program identifie le programme distant
! version identifie la version du programme
! procedure identifie la procdure
Nom Identifiant Description
portmap 100000 port mapper
rstat 100001 rstat, rup, perfmeter
ruserd 100002 remote users
nfs 100003 Network File System
ypserv 100004 Yellow pages (NIS)
mountd 100005 mount, showmount
dbxd 100006 debugger
ypbind 100007 NIS binder
etherstatd 100010 Ethernet sniffer
pcnfs 150001 NFS for PC

Identification des procdures distantes
! La procdure de numro 0 permet de tester la
disponibilit du service
! Un identifiant de programme peut correspondre
plusieurs processus de service (mount/showmount)
La smantique "au moins une fois"
! Les RPC sur un protocole de transport non fiable
(UDP)
! si un appel de procdure distante sexcutant sur UDP ne
retourne pas, lappelant ne peut pas savoir si la procdure
a t excute ou si la rponse a t perdue
! du ct de l'appelant : la rception d'un reply signifie
uniquement que la procdure distante a t excute au
moins une fois
! du ct de serveur : un serveur recevant plusieurs fois la
mme requte ne peut pas savoir si le client s'attend une
unique excution de la procdure ou bien s'il s'agit
effectivement de N excutions distinctes de la mme proc.
La smantique "au moins une fois"
! Le concepteur d'une application RPC utilisant UDP doit
prendre en compte le fait que la non rception d'un
reply ne signifie pas que la procdure distante n'a
pas t excute...
! Exemple :
! lecture dans un fichier distant : pas gnant si une demande
de lecture a gnr deux excutions de la procdure
! criture dans un fichier distant : gnant s'il s'agit d'un ajout
en fin de fichier ; la chane peut tre ajoute deux fois au
lieu d'une seule
! Les procdures doivent tre idempotentes :
! --> pas de procdure d'ajout en fin de fichier mais une
procdure d'criture telle position (ajout d'un paramtre
prcisant o crire dans le fichier)
Communications client/serveur
! Les sockets utilisent un well-known port pour
contacter un serveur distant (ex: telnet=port 23)
! Les clients RPC ne connaissent que l'identifiant
du programme RPC distant et le numro de
procdure (ex: 100003 pour NFS)
! Pourtant, les communications sous-jacentes se
font en mode client/serveur : lappelant doit
connatre ladresse (IP, port) utilise par le
programme RPC distant (ex: nfsd)
Communications client/serveur
! Le numro de port du processus serveur est
attribu dynamiquement quand il dmarre
! --> car le nombre de programmes RPC (identifiant sur
32 bits) est potentiellement suprieur au nombre de
well-known ports (numro de port sur 16 bits, ports
rservs entre 0 et 1023)
! Un processus spcial, le dmon portmap
maintient une base de donnes renseignant les
associations locales entre numro de port et
programme RPC
23
Le processus portmap
! lorsquun programme RPC (serveur) dmarre, il
alloue dynamiquement un numro de port local,
contacte le port mapper de la machine sur laquelle il
sexcute, puis informe ce dernier de lassociation
! lorsquun client dsire contacter un programme RPC
sur une machine distante, il interroge d'abord le port
mapper de cette machine pour connatre le port de
communication associ au service RPC
! le port mapper est lui mme un programme RPC
(100000) mais il est le seul utiliser un port allou
statiquement : le port 111/UDP et le port 111/TCP
le quadrupl (numro de
protocole, numro RPC,
numro de version, numro
de port)
Programme
RPC serveur
Port Mapper
TCP
le programme communique
sockets alloues dynamiquement
au programme RPC
sockets du port
mapper = 111
UDP TCP UDP
! Les procdures du port mapper
! 0 : fonction vide (teste la prsence de portmap)
! 1 : enregistrement d'un service (local)
! 2 : annulation d'un service (local)
! 3 : demande du numro de port d'un service
enregistr localement
! 4 : liste tous les services enregistrs localement
! 5 : appel d'une procdure distante via le port mapper
--> permet de "pinger" une procdure distante
Utilisation du port mapper
Procedure arguments
(call) or results (reply)
Message ID
Message type
RPC version number
REMOTE program
REMOTE program version
REMOTE procedure
Authentification fields
Le format est de longueur variable car le nombre
darguments de la procdure appele est variable
Le format des messages RPC
Numrotation des CALL/REPLY
CALL ou REPLY
Version de la librairie RPC
Identifie la procdure distante
Plusieurs types possibles (par ex.
UNIX : uid, gid, )
Nombre variable
Les rponses possibles
! Plusieurs types de rponses possibles :
! SUCCESS : les rsultats de la procdure sont renvoys
au client
! RPC_MISMATCH : les versions RPC du client et du
serveur ne sont pas compatibles
! AUTH_ERROR : problme d'authentification
! PROG_MISMATCH : la procdure demande n'est pas
disponible (problme de version du programme, )
! Plus de dtails : RFC 1057
24
La reprsentation XDR
! Les champs des messages RPC sont spcifis
dans le format XDR (eXternal Data
Representation)
! XDR : reprsentation des donnes dfinie par
SUN Microsystems
! dfinit le type et le format des donnes changes sur
le rseau (paramtres de la procdure distante)
! permet dchanger des donnes entre machines
ayant des reprsentations internes diffrentes
! Pourquoi XDR ?
! rpond au problme d'change d'informations types ou
structures entre deux machines htrognes dans la
reprsentation locale des donnes
! exemple : un entier de 32 bits ayant la valeur 260 sera
reprsent par :
! 00000104h sur une machine de type "big endian" cest
dire avec les Most Significant Bytes ayant les adresses
basses et les LSB ayant les adresses hautes
! 40100000h sur une machine de type "little endian"
! il faut adopter une reprsentation rseau et convertir sur
les extrmits les reprsentations locales en reprsentation
rseau et vice-versa
! L'htrognit concerne :
! la taille des objets typs : un entier peut tre cod sur
2 octets ou 4 octets
! l'ordre des octets : big endian ou little indian
! la reprsentation proprement dite d'un objet typ :
combien de bits pour la mantisse et l'exposant
reprsentant un nombre flottant, reprsentation d'un
entier ngatif
! Inconvnient du protocole XDR :
! l'encodage est effectu mme si les machines source
et destination utilisent dj la mme reprsentation
! --> perte de performance
! XDR va par exemple spcifier qu'un entier occupe
32 bits qui seront transfrs dans l'ordre "big
endian" sur le rseau
! si l'metteur ou le rcepteur n'est pas "big endian",
XDR fera la conversion de l'entier
! Le problme se posait dj pour les transmissions
par socket des adresses IP et numros de port
! fonctions de conversion :
! htons() et htonl() : reprsentation locale -->
reprsentation rseau
! ntohs() et ntohl() : reprsentation rseau -->
reprsentation locale
! ce problme ne se pose pas pour transfrer un fichier :
transfert brut d'une squence d'octets sans interprter
son contenu
Type Taille Description
int 32 bits entier sign de 32 bits
unigned int 32 bits entier non sign de 32 bits
bool 32 bits valeur boolenne (0 ou 1)
enum arb. type numr
hyper 64 bits entier sign de 64 bits
unsigned hyper 64 bits entier non sign de 64 bits
float 32 bits virgule flot. simple prcision
double 64 bits virgule flot. double prcision
opaque arb. donne non convertie (sans type)
fixed array arb. tableau de longueur fixe de nimporte quel
autre type
structure arb. agrgat de donnes
discriminated union arb. structure implmentant des formes alternatives
symbolic constant arb. constante symbolique
void 0 utilis si pas de donnes
string arb. chane de car. ASCII

! Une donne avant d'tre envoye est code au
format XDR mais aucune information dans
l'encodage ne donne le type de la donne
! si une application utilise un entier de 32 bits, le rsultat
de lencodage occupera exactement 32 bits et rien
nindiquera quil sagit dun type entier
! Cette forme dencodage implique que clients et
serveurs doivent sentendre sur le format exact
des donnes quils changent
! La bibliothque de fonctions de conversion XDR
permet simplement aux concepteurs dapplications
RPC de ne pas se soucier de la reprsentation
locale des donnes
25
XDR *xdrs; /* pointeur vers un buffer XDR */
char buf[BUFSIZE]; /* buffer pour recevoir les donnes encodes */
xdr_mem_create (xdrs, buf, BUFSIZE, XDR_ENCODE);
/* maintenant un buffer XDR est cr pour encoder les donnes
* chaque appel une fonction dencodage va placer le rsultat
* la fin de ce buffer ; le pointeur xdrs sera mis jour */

int i;
...
i=260;
xdr_int(xdrs, &i); /* encode lentier i et le place la fin de buffer */
/* Le programme receveur devra dcoder les donnes :
xdr_mem_create ( ... , XDR_DECODE) */
Fonction arguments type de donnes converti
xdr_bool xdrs, ptrbool boolen
xdr_bytes xdrs, ptrstr, strsize, maxsize chane de caractres
xdr_char xdrs, ptrchar caractre
xdr_double xdrs, ptrdouble virgule flot. double prcision
xdr_enum xdrs, ptrint type numr
xdr_float xdrs, ptrfloat virgule flot. simple prcision
xdr_int xdrs, ptrint entier 32 bits
xdr_long xdrs, ptrlong entier 64 bits
xdr_opaque xdrs, ptrchar, count donnes non converties
xdr_pointer xdrs, ptrobj pointeur
xdr_short xdrs, ptrshort entier 16 bits
xdr_string xdrs, ptrstr, maxsize chane de caractres
xdr_u_char xdrs, ptruchar entier 8 bits non sign
xdr_u_int xdrs, ptrint entier 32 bits non sign

Conception d'un programme RPC
! ct client, entre lappel de
procdure et la procdure
distante, il faut :
! encoder les arguments
! crer un message RPC CALL
! mettre ce message vers le
programme distant
! attendre les rsultats et
dcoder ces rsultats selon la
reprsentation interne de la
machine locale
! ct serveur, il faut :
! accepter une demande
d'excution RPC
! dcoder les arguments selon
la reprsentation de la
machine locale
! dispatcher le message vers la
procdure adquate
! construire la rponse puis
encoder celle-ci
! mettre le message
correspondant vers le client
La mthodologie consiste dvelopper lapplication
distribue comme une application conventionnelle puis
dfinir les procdures qui seront excutes distance
Proc A1 Proc A2
client stub
pour B2
client stub
pour B1
Dispatcher
server stub
pour B1
server stub
pour B2
Proc B1 Proc B2
Conception d'un programme RPC
! Les procdures stubs remplacent les procdures
conventionnelles (appel de procdure ct client,
procdure appele ct serveur)
(prog_num, ver,
proc_num)
Gnration de programme RPC
! rpcgen est un outil de gnration de programme
RPC produisant automatiquement le code pour :
! les procdures stub client et serveur
! un squelette de serveur
! les procdures XDR d'encodage/dcodage des
paramtres et des rsultats
! l'envoi et la rception des messages RPC
! Le concepteur du programme RPC doit fournir un
fichier spcifiant
! la description des structures de donnes des
paramtres et des rsultats
! les fonctions ralisant le service dsir
! rpcgen produit quatre fichiers source dont les
noms sont drivs du nom du fichier de
spcification en entre
! Si le fichier en entre est serv.x, les fichiers
gnrs sont :
! serv.h : dclarations des constantes et types
utiliss dans le code gnr pour le client et le serveur
! serv_xdr.c : procdures XDR utilises par le client
et le serveur pour encoder/dcoder les arguments
! serv_clnt.c : procdure stub ct client
! serv_svc.c : procdure stub ct serveur
26
! Un exemple de spcification
-- dfinitions des types --
struct couple_int {int min; int max;};
struct couple_int_float {int s; float m;};
-- --
program VECTEUR_PROG {
version VECTEUR_VERSION_1 {
couple_int MIN_MAX(vecteur) = 1;
couple_int_float SOM_MOY(vecteur) = 2;
int PRODUIT_SCALAIRE(couple_vecteur) = 3;
vecteur SOMME_VECTEUR(couple_vecteur) = 4;
} = 1; -- num_version --
} = 0x22222222; -- num_prog --
! Ensuite, ct client, il suffit d'appeler callrpc()
callrpc(host,prog,progver,procnum,inproc,in,outproc,out);
! inproc est une procdure qui encode les arguments dans
le message RPC
! in spcifie ladresse des arguments de la procdure
distante
! outproc est une procdure qui dcode les rsultats dans le
message RPC
! out spcifie ladresse en mmoire o les rsultats seront
dcods
! Inconvnients
! uniquement au dessus d'UDP
! pas de paramtrage possible des temporisations (temps
maximal d'attente d'un rsultat = 25 s, r-mission de la
requte toutes les 5 s)
Les RPC sous UNIX
! Le fichier /etc/rpc
! l'quivalent de /etc/services pour les sockets
(annuaire des services)
! contient les informations relatives aux programmes RPC :
nom du service, numro de programme, listes d'alias
root@192.168.69.2# cat /etc/rpc
portmapper 100000 portmap sunrpc
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog nis
mountd 100005 mount showmount
...
Les RPC sous UNIX
! La commande rpcinfo
! permet d'interroger le port mapper pour connatre les
services RPC disponibles la machine o il s'excute
(procdure n4 du port mapper)
rpcinfo -p [host]
(par dfault, host = localhost)
! permet de s'assurer de la disponibilit d'un service RPC
particulier (excution de la procdure 0 du service)
rpcinfo -u host prog_num [ver_num] (UDP)
rpcinfo -t host prog_num [ver_num] (TCP)
(par dfault, ver_num = 1)
Les RPC sous UNIX
root@192.168.69.1# rpcinfo -p 192.168.90.2
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100004 2 udp 954 ypserv
100004 1 udp 954 ypserv
100004 2 tcp 957 ypserv
100004 1 tcp 957 ypserv
100007 2 udp 959 ypbind
100007 1 udp 959 ypbind
100007 2 tcp 962 ypbind
100007 1 tcp 962 ypbind
root@192.168.69.1# rpcinfo -u 192.168.90.2 ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
Les RPC sous UNIX
! Sur le client (192.168.69.1)
root@192.168.69.1# rpcinfo -u 192.168.69.2 nfs
rpcinfo: RPC: le programme n'est pas enregistr
Le programme 100003 n'est pas disponible.
root@192.168.69.1# rpcinfo -p 192.168.69.2
Aucun programme enregistr sur l'hte cible
! Sur le serveur (192.168.69.2)
root@192.168.69.2# rpcinfo -p 192.168.69.2
No remote programs registered.
root@192.168.69.2# rpcinfo -p | grep nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
! Il faut autoriser les connexions RPC extrieures
27
Les RPC sous UNIX
! Les fichiers /etc/hosts.allow et /etc/
hosts.deny permettent d'autoriser ou non
l'accs aux services rseaux (en particulier les
connexions RPC distantes sur la machine locale)
! Syntaxe gnrale (hors RPC) :
service: utilisateurs (autoriss dans hosts.allow,
rejets dans hosts.deny)
! Exemple (voir aussi man hosts_access) :
root@192.168.69.2# cat /etc/hosts.deny
ALL: ALL #on ne peut plus rien faire distance
root@192.168.69.2# cat /etc/hosts.allow
portmap nfsd sshd: 192.168.69. 192.168.90.3
Les RPC sous UNIX
! Comme pour les dmons utilisant les sockets, il est
possible de lancer dynamiquement le processus d'un
serveur RPC uniquement quand un client sollicite le
service (via le dmon inetd)
! Il suffit d'ajouter une entre par service RPC dans le
fichier /etc/inetd.conf
# services RPC
rpc 100002 1-2 dgram udp wait root /sbin/ypserv ypserv -d
! Quand le processus inetd se lance, il ralise
l'enregistrement des services RPC qu'il prend en
compte auprs de portmap
Exercices
Lecture bloquante/non bloquante
! Une application (client ou serveur) veut lire
exactement 100 caractres sur une socket
(mode connect)
! Dcrire l'algorithme correspondant et donnez les
avantages/inconvnients
! dans le cas d'une lecture bloquante
! dans le cas d'une lecture non bloquante
Exemple de programmation C/S
! 1. Quel est le service propos par cette application client/serveur ?
Combien darguments sont ncessaires au lancement du client ?
Quels sont-ils ?
! 2. Quel port utilise le serveur ? Aurait-on pu choisir une autre
valeur ? Quel port utilise le client ? Comment est-il attribu et par
quelle primitive ? Sagit-il dune connexion en mode connect ou
non et est-ce justifi ?
! 3. A quoi correspondent les constants BUF_SIZE et QUEUE_SIZE ?
! 4. Quand est-ce que le serveur sarrte ? Que fait le serveur une
fois les initialisations termines (dcrire le cas o il y a des
connexions pendantes et le cas inverse) ?
! 5. Que se passe t-il si le client est lanc avant que le serveur nait
dmarr ?
! 6. Quand est-ce que le client sarrte si la connexion a russi ? Que
fait le client une fois la connexion tablie ?
! 7. Que pensez-vous de la structure actuelle du serveur ? Peut-il
satisfaire un grand nombre de connexions ? Expliquez. Proposez une
solution plus adapte.
D o cum e n t
Micro s o ft Word
Un mini-inetd
! Voici la page man du programme mini-inetd ainsi que son code.
! 1. Compltez la partie DESCRIPTION de la page man. Reprsentez
laide dun schma/diagramme la structure algorithmique du
programme.
! 2. Dans le code ci-aprs, le code de la fonction tcp_listen() a
volontairement t omis. Quelles sont les paramtres et la valeur de
retour de cette fonction ? Quelles sont les oprations qui doivent y
tre ralises et o les paramtres interviennent-ils ?
! 3. Commentez le nom du programme. Quelles sont les diffrences et
similitudes entre mini-inetd et inetd ?
! 4. Comment modifieriez vous la structure donne la question 1
pour que mini-inetd puisse traiter plusieurs couples (port,
program) passs en arguments ?
D o cum e nt
Microsoft Wor d

SPAI C1 ArchiC S 6p

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SPAI C1 ArchiC S 6p

Transféré par

Droits d'auteur :

Formats disponibles

1

Vous aimerez peut-être aussi