Cours en Entier

La communication à distance
Les protocoles
Les intergiciels (middleware)
Intergiciels et applications communicantes

Première partie
Philippe Quéinnec
Informatique et Réseaux 2e année

Introduction
ENSEEIHT
14 février 2018
Inspiré de cours de G. Padiou, Ph. Mauran et S. Krakowiak. Certains dessins en sont issus.
Intergiciels 1 / 15 Intergiciels 2 / 15
La communication à distance La communication à distance

Les protocoles Les protocoles
Les intergiciels (middleware) Les intergiciels (middleware)
Plan La communication à distance
Communication au niveau réseau

Les ingénieurs réseaux font communiquer des machines
1 La communication à distance
Machine M Machine M’
X
2 Les protocoles
B
Réseau Y
3 Les intergiciels (middleware) A
Communication
bi-point entre
Z
2 machines
I – Introduction 3 / 15 I – Introduction 4 / 15
La communication à distance La communication à distance : objectifs
Faire communiquer des processus par échange d’information

Communication au niveau intergiciel
Les ingénieurs informaticiens font communiquer des applications
Pas de mémoire partagée, communication « à distance »
Machine M Communication Machine M’
entre 2 processus Exploiter les réseaux de communication pour faire
X ique
Lien log B communiquer des ordinateurs
Avantage : le partage de ressources et l’échange d’informations
Réseau Y
Comment ? définition de protocoles de communication entre
A processus distants
Communication Difficulté : hétérogénéité du matériel, des systèmes
bi-point entre
Z
2 machines
d’exploitation, des programmes applicatifs écrits dans
différents langages : C, C++, Java. . .

Plan du cours Distinction service / serveur
Service
Un service est une description / interface / spécification.
1 La communication à distance entre applications
2 Communication par socket Serveur
3 Appel de procédure et appel de méthode à distance Un serveur est une réalisation / implantation / concrétisation d’un
4 Intergiciel asynchrone : communication par messages service
5 Tolérance aux fautes
Besoins
6 Mémoire virtuelle répartie, systèmes de fichiers répartis
Trouver les services existants
Pour un service donné, trouver les serveurs qui le réalisent
Dialoguer avec un serveur donné (= protocole)
Service/serveur – exemple Plan
Je veux manger
Quels sont les services offerts dans un village ⇒ boulangerie,
bistrot. . . 1 La communication à distance
Où trouver une boulangerie ? ⇒ place Dupuy
Comment acheter une baguette ⇒ protocole d’interaction
2 Les protocoles
Service de nommage internet (DNS)
Service de conversion de noms symboliques en adresses IP 3 Les intergiciels (middleware)
numériques
À l’N7, serveurs sur les machines 147.127.80.123,
147.127.176.22, 147.127.16.11

Les protocoles de communication Les protocoles de communication (suite)
Grande variété de mise en œuvre

Mais aussi selon le niveau d’abstraction
Beaucoup de paramètres Simple échange d’un message
Point à point ou diffusion Transaction de messages, par exemple :
Synchronisation émetteur-récepteur : question, réponse [, acquittement ]
Envoi asynchrone : l’émetteur ne se bloque pas Flots de messages sur une liaison pré-établie
Envoi synchrone : l’émetteur attend un acquittement
Gestion de tampons en émission et/ou en réception Appel procédural à distance, appel de méthode à distance
Délais de transmission (non) bornés Publication et abonnement
Fiabilité : pertes possibles, duplications, erreurs. . . etc
Désignation des entités distantes (processus)
Plan Les intergiciels et leur rôle
Définition
1 La communication à distance Couche logicielle entre système d’exploitation et applications
Service implantant un modèle d’interaction entre processus
API normalisée associée au service de communication implanté
2 Les protocoles
Quelques points communs
Besoin d’une interface avec la couche « transport »
3 Les intergiciels (middleware)
Besoin de certains services de base : service de nommage
Nécessité de traiter l’hétérogénéïté entre les processus
La communication à distance
Les protocoles
Les intergiciels (middleware)
Les sources d’hétérogénéïté
Deux processus communicants peuvent

exécuter un programme écrit dans des langages différents
être exécutés par des systèmes d’exploitation différents
s’exécuter sur des architectures de machine différentes
Deux approches de solution

Définition d’un langage commun (IDL/Interface Description
Language) et instanciation dans différents contextes
d’exécution → normes RPC, CORBA
Définition d’un environnement de développement et
d’exécution portable et exécution dans n’importe quel contexte
→ environnement Java
I – Introduction 15 / 15
Présentation générale Présentation générale
Structure client/serveur Structure client/serveur Objectifs
Programmation (API C) Programmation (API C) Éléments de base
Programmation (API Java) Programmation (API Java)
Plan
1 Présentation générale
Deuxième partie Objectifs
Éléments de base
2 Structure client/serveur
Communication par flots 3 Programmation (API C)
Interface socket Exemples
API principale
Divers
4 Programmation (API Java)
Mode connecté
Mode non connecté
Intergiciels 1 / 48 II – Interface socket 2 / 48

Structure client/serveur Objectifs Structure client/serveur Objectifs
Programmation (API C) Éléments de base Programmation (API C) Éléments de base
L’API socket dans la pile IP Objectifs de l’API socket
HTTP NFS Application

API Fournir une interface homogène aux applications
Socket service TCP
TCP UCP Transport service UDP
Noyau Conforme au système de gestion de fichiers
flot d’octets
IP Réseau
lecture/écriture
Modèle client/serveur
Matériel Liaison/physique
II – Interface socket 3 / 48 II – Interface socket 4 / 48

La notion de flot centralisé → réparti Désignation globale via la notion de port

Comment désigner un processus à distance ?
Un processus a un nom local : numéro d’ordre par exemple ;
Idée
P1 P2 Un site a un nom global : adresse IP par exemple ;
Un port est un « point d’accès » à un site ;
Pipe « réparti » Site unique Nom global d’un processus : (adresse site, numéro de port)
Désignation ? (communication par mémoire commune)
Protocole ?
1 1
Interface ?
2 2
P2
Fiabilité ?
P1 P2 P1
Hétérogénéité ? 3 3
Réseau
Site S1 Site S2 4 4
Réseau
Site S1 Site S2
Ports

Éléments de base Schéma général
Processus 1
adr 1 adr 3 Processus 3
Socket → descripteur de fichier sock 1 (@IP, port)
sock 1
Protocole / domaine d’adresses → famille d’adresses sock 2
sock 3
Adresse → (adresse IP, numéro de port) sock 2
Liaison → attribution d’une adresse à un socket adr 4
Association → domaine + couple d’adresses (client/serveur ou

Processus 2 adr 2 Processus 4
émetteur/récepteur)
sock 1 adr 5 sock 1
sock 2 adr 6

Numéro de ports standards (notorious) Services offerts

/etc/services
ftp 21/tcp Orienté connexion (TCP)

telnet 23/tcp établissement/acceptation de connexion
smtp 25/tcp mail
flot d’octets fiable et ordonné
http 80/tcp www
# terminaison de connexion
# UNIX specific services
# Orienté datagramme (UDP)
exec 512/tcp pas de connexion
login 513/tcp un message applicatif = une opération
printer 515/tcp spooler
à la fois flot et messages
who 513/udp whod
talk 517/udp

Structure client/serveur Structure client/serveur
Programmation (API C) Programmation (API C)
Plan Structure générale
Objectifs
Client
Éléments de base
initie la communication
2 Structure client/serveur
doit connaître le serveur
3 Programmation (API C)
Exemples Serveur
API principale informe le système de sa disponibilité
Divers répond aux différents clients
4 Programmation (API Java) clients pas connus a priori
Mode connecté
Mode non connecté

Client/serveur non connecté Client/serveur connecté
Client Serveur
créer un socket créer un socket
Client Serveur se connecter au serveur attribuer une adresse
créer un socket créer un socket dialoguer avec le serveur informer le système
répéter attribuer une adresse par le socket connecté répéter
émettre une requête répéter terminer la connexion attendre une demande
vers une adresse attendre une requête de connexion
attendre la réponse traiter la requête dialoguer avec le client
jusqu’à réponse positive émettre la réponse par le socket ainsi créé
ou abandon jusqu’à fin du service jusqu’à fin du service
un socket d’écoute pour accepter les connexions,

un socket connecté pour chaque connexion

Exemples Exemples
API principale API principale
Divers Divers
Plan Primitives principales
socket création
Objectifs
bind nommage : liaison d’un socket à une adresse
Éléments de base
connect connexion : établissement d’une association
2 Structure client/serveur listen prêt à attendre des connexions
accept attente de connexion : acceptation d’association
close fermeture
Exemples
shutdown fermeture (obsolète)
API principale
Divers
read/write
4 Programmation (API Java) recv/send
Mode connecté recvfrom/sendto
Mode non connecté

Exemples Exemples
Divers Divers
Exemple – mode connecté Exemple – mode connecté
Site S1
socket()
Site S2
Client Serveur bind()
listen()
ccl = socket()
c ;
csv=socket();
ps accept()
bind(csv,ps);
connect(ccl,<S
t( ,ps>) listen(csv,5); bloque jusqu’à une
2
pc ps
socket()
demande de connexion
cx=accept(csv); connexion
write(ccl,...);
cl connect()
pc ps
read(cx,...); write()
pc ps requête read()
write(cx,...);
read(ccl,...);
. write()
close(cx); read()
close(ccl); réponse

Exemples Exemples
Divers Divers
Exemple – mode connecté Exemple – mode connecté

Le client Le serveur
struct sockaddr_in adrserv; struct sockaddr_in adrserv;

char reponse[6]; int sserv = socket (AF_INET, SOCK_STREAM, 0);
bzero (&adrserv, sizeof(adrserv));
int scl = socket (AF_INET, SOCK_STREAM, 0); adrserv.sin_family = AF_INET;
bzero (&adrserv, sizeof(adrserv)); adrserv.sin_addr.s_addr = htonl (INADDR_ANY);
adrserv.sin_family = AF_INET; adrserv.sin_port = htons (4522);
inet_aton("147.127.133.111", &adrserv.sin_addr); bind (sserv, (struct sockaddr *)&adrserv, sizeof(adrserv));
adrserv.sin_port = htons (4522); listen (sserv,5);
connect (scl, (struct sockaddr *)&adrserv, sizeof(adrserv)); while (1) {
write (scl, "hello", 6); char requete[6];
read (scl, reponse, 6); int scl = accept (sserv, NULL, NULL);
close (scl); read(scl, requete, 6);
if (strcmp(requete, "hello") == 0) write(scl, "world", 6);
else write(scl, "bouh", 5);
ATTENTION : il manque le contrôle d’erreur, INDISPENSABLE. close(scl);
}
Exemples Exemples
Divers Divers
Exemple – mode non connecté Exemple – mode non connecté

Le client
socket() struct sockaddr_in adrserv;

struct hostent *sp;
bind() char *requete = "hello";
char reponse[10];
recvfrom()
socket() int scli = socket (AF_INET, SOCK_DGRAM, 0);
bloque jusqu’à bzero (&adrserv, sizeof(adrserv));
réception de données
sendto() requête adrserv.sin_family = AF_INET;
sp = gethostbyname("turing.enseeiht.fr"); // assume OK
memcpy (&sins.sin_addr, sp->h_addr_list[0], sp->h_length);
traitement adrserv.sin_port = htons (4522);
réponse sendto() sendto (scli, requete, strlen(requete), 0,

recvfrom() (struct sockaddr *)&adrserv, sizeof(adrserv));
recvfrom (scli, reponse, sizeof (reponse), 0, NULL, NULL);
close (scli);

Exemples Exemples
Divers Divers
Exemple – mode non connecté Création d’un socket

Le serveur
struct sockaddr_in adrserv, adrcli; char requete[10];
int sserv = socket (AF_INET, SOCK_DGRAM, 0); socket crée un socket en spécifiant le famille de protocole utilisée.
bzero (&adrserv, sizeof(adrserv));
adrserv.sin_family = AF_INET; int socket(int domain, int type, int protocol)
adrserv.sin_addr.s_addr = htonl (INADDR_ANY);
adrserv.sin_port = htons (4522); où
bind (sserv, (struct sockaddr*)&adrserv, sizeof(adrserv)); domain = AF_INET, AF_INET6, AF_UNIX, AF_X25. . .
while (1) {
bzero (&adrcli, sizeof (adrcli));
type = SOCK_STREAM, SOCK_DGRAM
int adrclilen = sizeof (adrcli); protocol = 0
recvfrom (sserv, requete, sizeof(requete), 0, Retour : un « descripteur » de fichier ou −1
(struct sockaddr *)&adrcli, &adrclilen);
sendto (sserv, "world", 6, 0,
(struct sockaddr *)&adrcli, adrclilen);
}
Exemples Exemples
Divers Divers
Adresse Représentation des entiers
struct sockaddr_in { La pile IP est « big endian »

short sin_family;
u_short sin_port; Conversion de données (numéro de port, adresse IP)
struct in_addr sin_addr; htonl host-to-network, long int
char sin_zero[8]; htons host-to-network, short int
}; ntohl network-to-host, long int
ntohl network-to-host, short int
sin_family doit être AF_INET
sin_port numéro de port sur 16 bits, dans une représentation Conversion ascii ↔ in_addr
standard : “network byte ordered” (big endian) int inet_aton(const char *cp, struct in_addr *inp);
sin_addr.s_addr = adresse IP sur 32 bits, correctement char *inet_ntoa (struct in_addr in);
ordonnée (big endian)

Exemples Exemples
Divers Divers
Service de nommage (DNS) Liaison socket/adresse

struct hostent { bind nomme localement le socket (machine, port).
char *h_name; /* nom canonique */ Obligatoire pour accepter des connexions ou recevoir des messages.
char **h_aliases; /* liste d’alias */
int h_addrtype; /* type des adresses */ int bind(int sd, struct sockaddr *addr, int addrlen);
int h_length; /* longueur d’une adresse */
char **h_addr_list; /* liste d’adresses */ où
}; */
struct hostent *gethostbyname(char *name); sd : descripteur du socket
struct hostent *gethostbyaddr(void *addr, int len, int type); addr : adresse attribuée à ce socket
gethostbyname avec un nom de machine addrlen : taille de l’adresse (sizeof(struct sockaddr_in))
turing.enseeiht.fr permet d’obtenir ses autres noms et Retour : 0 si ok, −1 si échec avec errno :
son (ses) adresse(s). Actuellement h_addrtype == AF_INET EACCESS = permission refusée (adresse réservée)
ou AF_INET6, et utiliser h_addr_list[0]. EADDRINUSE = adresse déjà utilisée pour un nommage
Pour une adresse format sin_addr de type == AF_INET,
...
gethostbyaddr permet d’obtenir le(s) nom(s) en clair.
Exemples Exemples
Divers Divers
Connexion (côté client) Déclaration du serveur

connect identifie l’extrémité distante d’une association.
int connect(int sd, struct sockaddr *addr, int addrlen); listen établit une file d’attente pour les demandes de connexions.
où int listen(int sd, int backlog);
sd : descripteur du socket (du client)
addr : adresse du socket du serveur où
addrlen : taille de l’adresse sd : descripteur du socket (du client)
Retour : 0 si ok, −1 si échec. backlog : nombre max de clients en attente
EISCONN = socket déjà connecté Retour : 0 si ok, −1 si échec.
ECONNREFUSED = connexion refusée (pas d’écouteur)
EADDRINUSE = un autre socket déjà à l’écoute sur le même
ENETUNREACH = réseau inaccessible port.
ETIMEDOUT = délai de garde expiré avant l’établissement de
la connexion
...

Exemples Exemples
Divers Divers
Acceptation d’une connexion Communication de données

accept prend la première demande de connexion et crée un
nouveau socket ayant les mêmes caractéristiques que sd mais
connecté à l’appelant ⇒ établissement d’une association.
Appels système classiques : read/write.
int accept(int sd, struct sockaddr *peer, int *addrlen);
int write(int sd, const void *buf, int len);
où int read(int sd, void *buf, int len);
sd : socket existant de type STREAM
Flot d’octets : les frontières entre les messages ne sont pas
peer : adresse du socket du client (valeur en retour)
préservées
addrlen = taille de l’adresse fournie et taille de l’adresse
⇒ protocole applicatif nécessaire
retournée (utiliser sizeof(struct sockaddr_in))
Retour : un nouveau descripteur de socket si ok, ou −1 en cas
d’erreur
EOPNOTSUPP = sd n’est pas de type STREAM
Exemples Exemples
Divers Divers
Communication, mode non connecté Liaisons implicites/explicites

bind implicite
int sendto(int sd, void *buf, int len, int flags,
Lors d’un connect ou d’un sendto, le socket doit avoir une
struct sockaddr *dest, int addrlen);
adresse locale ⇒ attribution d’un numéro de port non utilisé si
int recvfrom(int sd, void *buf, int len, int flags,
nécessaire.
struct sockaddr *src, int *addrlen);
Il est possible de nommer le socket (bind) avant connect ou
où sendto, mais guère d’utilité.
sd : socket
connect explicite
buf, len : message à envoyer
Il est possible de « connecter » un socket en mode datagramme
dest : adresse du socket destinataire (sendto, entrée)
(utilisation de connect sur un socket SOCK_DGRAM) :
src : adresse du socket émetteur (recvfrom, sortie)
plus nécessaire de spécifier le destinataire de chaque message
addrlen : longueur de l’adresse (entrée et sortie pour recvfrom)
sans connect, le même socket peut être utilisé vers différents
Retour : ≥ 0 si nombre d’octets émis/reçus, −1 si erreur destinataires

Exemples Exemples
Divers Divers
Fermeture Configuration (en tant que fichier)
close termine l’association et libère le socket après avoir

délivré les données en attente d’envoi.
int close(int sock);
Note : comportement inattendu s’il reste des octets à lire int fcntl(int fd, int cmd, ...)
(écritures en attente perdues).
Par exemple : fcntl(sd, F_SETFL, O_NONBLOCK)
shutdown permet une fermeture unilatérale :
pour mettre en non bloquant.
int shutdown(int sock, int how);
où how = SHUT_RD (fin de réception), SHUT_WR (fin

d’émission), SHUT_RDWR (fin de réception et d’émission)
Rq : il faudra quand même appeler close pour libérer les ressources
du système.
Exemples Exemples
Divers Divers
Configuration (en tant que socket) Adresse d’un socket
int setsockopt(int sockfd, int level, int optname,

const void *optval, socklen_t optlen);
obtenir l’adresse de l’extrémité locale d’une association
Par exemple :
int getsockname(int sd,
int ra = 1; struct sockaddr *addr, int *addrlen);
setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &ra, sizeof(ra));
obtenir l’adresse de l’extrémité distante d’une association
level option description (mode connecté)
SOL_SOCKET SO_REUSEADDR réutilisation immédiate d’adresse locale
SO_KEEPALIVE maintient en vie une connexion int getpeername(int sd,
SO_BROADCAST autorise les diffusions struct sockaddr *peer, int *addrlen);
IPPROTO_TCP TCP_MAXSEG taille max d’un segment TCP
TCP_NODELAY disable Nagle’s algorithm
IPPROTO_IP IP_OPTIONS options des entêtes IP

Structure client/serveur Mode connecté Structure client/serveur Mode connecté
Programmation (API C) Mode non connecté Programmation (API C) Mode non connecté
Plan Les classes
Objectifs
Éléments de base java.net.InetAddress pour manipuler des adresses IP
2 Structure client/serveur Mode connecté : java.net.Socket et
java.net.SocketServer
Mode datagramme : java.net.DatagramSocket et
Exemples
java.net.DatagramPacket
API principale
Divers Note : les interfaces présentées sont incomplètes (exceptions
supprimées).
4 Programmation (API Java)
Mode connecté
Mode non connecté

La classe java.net.InetAddress Classe java.net.ServerSocket

Deux sous-classes Inet4Address, Inet6Address
Obtention : Représente un socket d’écoute.
static InetAddress getLocalHost();
renvoie l’adresse IP du site local d’appel. Constructeurs :
static InetAddress getByName(String host); ServerSocket(int port);
Résolution de nom (sous forme symbolique ServerSocket(int port, int backlog, InetAddress bindAddr);
turing.enseeiht.fr ou numérique 147.127.18.03) Réalise socket – bind – listen.
static InetAddress[] getAllByName(String host); Méthodes :
Résolution de nom → toutes les adresses IP d’un site
Accesseurs Socket accept();
String getHostName() Renvoie un socket connecté. Bloquant. (= accept en C).
le nom complet correspondant à l’adresse IP InetAddress getInetAddress();
String getHostAddress() Renvoie l’adresse IP locale.
l’adresse IP sous forme d.d.d.d ou x:x:x:x:x:x:x:x int getLocalPort();
byte[] getAddress()
l’adresse IP sous forme d’un tableau d’octets.

La classe java.net.Socket La classe java.net.Socket (suite)

Représente un socket connecté, côté client comme côté serveur.
Constructeurs (côté client) :
Socket(String host, int port); Accesseurs :
Socket(InetAddress address, int port); InetAddress getLocalAddress();
Socket(String host, int port, Renvoie l’adresse IP locale. (≈ getsockname en C)
InetAddress localAddr, int localPort); int getLocalPort();
Socket(InetAddress addr, int port, Renvoie le port local.
InetAddress getInetAddress();
InetAddress localAddr, int localPort);
Renvoie l’adresse IP distante. (≈ getpeername en C)
= socket – bind (éventuellement) – connect. int getPort();
Constructeur bloquant ! Renvoie le port distant.
Accès aux flots de données :
InputStream getInputStream();
OutputStream getOutputStream();
Socket en Java : exemple client Socket en Java : exemple serveur
public class Client {
public class Serveur {
public static void main(String[] args) throws Exception {
public static void main(String[] args) throws Exception {
Socket socket = new Socket("bach.enseeiht.fr", 8080);
ServerSocket s = new ServerSocket(8080);
// Un BufferedReader permet de lire par ligne.
while (true) {
BufferedReader plec = new BufferedReader(
Socket soc = s.accept();
new InputStreamReader(socket.getInputStream()));
BufferedReader plec = new BufferedReader(
// Un PrintWriter possède toutes les opérations print classiques.
new InputStreamReader(soc.getInputStream()));
// En mode auto-flush, le tampon est vidé (flush) lors de println.
PrintWriter pred = new PrintWriter(
PrintWriter pred = new PrintWriter(
new BufferedWriter(
new BufferedWriter(
new OutputStreamWriter(soc.getOutputStream())),
new OutputStreamWriter(socket.getOutputStream())),
true);
true);
while (true) {
String str = "bonjour";
String str = plec.readLine(); // lecture du message
for (int i = 0; i < 10; i++) {
if (str.equals("END")) break;
pred.println(str + i); // envoi d’un message
pred.println(str); // renvoi d’un écho
str = plec.readLine(); // lecture de l’écho
}
}
plec.close();
pred.println("END") ;
pred.close();
plec.close(); Attention aux soc.close(); Attention aux
pred.close(); exceptions ! exceptions !
}
socket.close();
}
}
}
}
Socket en mode datagramme java.net.DatagramSocket Conclusion
Constructeurs : Principes de base

DatagramSocket(); // port quelconque disponible Extension d’une notion issue du monde « centralisé »
DatagramSocket(int port);
Connexion point à point entre processus
Méthodes :
Bases du modèle (protocole) client-serveur
void send(DatagramPacket p);
Communication en mode datagramme ou connecté
void receive(DatagramPacket p);
Pas de transparence de la communication
Classe java.net.DatagramPacket :
DatagramPacket(byte[] buf, int length); Pour aller plus loin
DatagramPacket(byte[] buf, int length,
Trouver une abstraction du contrôle plus simple
InetAddress addr, int port); // destination
⇒ réutiliser la notion de procédure
Principe de conception : idée de transparence
+ getters et setters

Introduction
L’appel procédural à distance L’appel procédural à distance
Transparence
L’appel de méthode à distance L’appel de méthode à distance
Mise en œuvre
Plan
1 L’appel procédural à distance

Troisième partie Introduction
Transparence
Sémantiques
Paramètres
Appel de procédure et de méthode à Désignation et liaison
Mise en œuvre
distance
2 L’appel de méthode à distance
Sémantique et propriétés
Sérialisation
RMI de Java
Exemple basique
Exemple : callback
Intergiciels 1 / 66 III – Appel à distance 2 / 66
Introduction Introduction
Transparence Transparence
Mise en œuvre Mise en œuvre
Communication par appel procédural à distance Communication par appel procédural à distance
alias Remote Procedure Call (RPC)
Machine hôte Extension répartie du mécanisme d’appel procédural

Processus
Procédure appelée exécutée dans un espace différent de celui
de l’appelant
proc Synchronisation appelant-appelé
Transaction de messages
Pile
(question - réponse - [acquittement])
Fiabilité bien moindre qu’en centralisé
Machine cliente Machine serveur
Comment transmettre les paramètres ?
Processus client Processus serveur
Requête
Problème de l’hétérogénéité
d’appel
du matériel
proc
du système d’exploitation
Réponse
Proxy
d’appel
résultat de la représentation des données (paramètres)
Pile Pile des langages de programmation
III – Appel à distance 3 / 66 III – Appel à distance 4 / 66

Transparence Principe général
But : rendre l’utilisation de l’appel à distance aussi conforme

(transparent) que l’appel local de procédure
passage des paramètres
liaison (nommage)
protocole de transport
exceptions
sémantique de l’appel
représentation des données
performance
sécurité
Sémantique de l’appel procédural à distance Sémantique de l’appel procédural à distance

Quelques problèmes. . . Sémantique minimaliste : « Sans garantie »
Délai de garde ⇒ Echec

Proc(a,7,...) Proc(a,7,...)
Perte du Appel sans réponse
Re
qu
message
ête
résultat
Proc(x,y,...) Proc(x,y,...)
Plusieurs sémantiques possibles ! Avantages et inconvénients

« Sans garantie » (Maybe / Best effort) Simple à implanter : envoyer un message
« Au moins une fois » (At-least-once) Pas de réponse donc pas de garantie d’exécution
« Au plus une fois » (At-most-once) Utile dans certains cas (logging)
« Exactement une fois » (Exactly-once).
Sémantique de l’appel procédural à distance Sémantique de l’appel procédural à distance

Sémantique « Au moins une fois » Sémantique « Au plus une fois »
Délai de garde ⇒ Rappel Délai de garde ⇒ Rappel
Proc(a,7,...) Proc(a,7,...)
Début de l’appel Fin de l’appel Début de l’appel Fin de l’appel
Perte du Requête Perte du Requête

Requête dupliquée Message Requête message dupliquée Message
message
initiale Résultat initiale résultat Résultat
résultat
Proc(x,y,...) Proc(x,y,...) Détecter que l’appel

Proc(x,y,...) a déjà été satisfait
Avantages et inconvénients Avantages et inconvénients

Robuste face aux pertes et lenteurs Plus proche de l’appel procédural centralisé
Si terminaison correcte → garantie d’une exécution au moins Terminaison correcte ⇒ garantie d’une seule exécution à
Si terminaison incorrecte (après plusieurs rappels), pas de distance
garantie sur ce qui s’est passé à distance Terminaison incorrecte : pas de garantie sur ce qui s’est passé à
distance ⇒ entre autre, risque d’exécution partielle à distance
Risque de plusieurs exécutions pour un seul appel logique
Sémantique de l’appel procédural à distance Espace d’adressage séparés

Sémantique « Exactement une fois »
+ Isolation des données du serveur

Proc(a,7,...) Fin de l’appel sur
Début de l’appel délai de garde final
Sécurité
Perte d’une requête
Conception modulaire
Requête Arrêt sur dupliquée
initiale défaillance
− Passage des paramètres au moyen de messages
Risque d’exécution pas de variables globales implicites
partielle de
Proc(x,y,...)
passage par valeur (copie)
Avantages et inconvénients Références ?
Si terminaison correcte ⇒ équivalent à « au + une fois » Interdire le passage de références ⇒ expressivité faible
Sérialisation : transfert et reconstruction du graphe (structure
Si terminaison incorrecte ⇒ garantie d’atomicité à distance de données)
Références globales opaques (objets répartis)

Représentation des données Désignation et liaison

Problèmes Correspondance : nom symbolique (externe) → nom interne
hétérogénéité du matériel (adresse réseau, identifiant local)
taille des types élémentaires (booléen, entier. . . ) Cas des RPC :
ordre des octets pour les entiers nom de service → port et adresse serveur
nom d’opération → procédure sur le serveur correspondant
nombres réels
codage des caractères Instant(s) d’évaluation de la liaison
données composites : structures, tableaux Liaison statique (précoce) : localisation du serveur fixée au
moment de la compilation du programme client
Approches Liaison dynamique (tardive) : localisation à l’exécution
1 définir une représentation standard désignation symbolique des services
typage implicite : seules les valeurs sont transmises choix retardé de l’implémentation
typage explicite : information de type + valeur localisation du service au premier appel seulement, ou à
chaque appel
2 préfixer par le type local, et laisser le destinataire convertir si adaptation à une reconfiguration du système : régulation,
nécessaire pannes, évolutions
Liaison dynamique : serveur de noms Serveurs de noms local à un site : portmapper

Cas où le site hébergeant le service est connu, mais où le port
1,2 : Enregistrement du service
dans l’annuaire sous :
correspondant au service n’est pas connu ⇒ utiliser un service de
hnomi → hadr. serv., no porti nommage local au serveur, le portmapper.
3,4,5 : Consultation de
l’annuaire pour trouver hadr.
serv., no porti à partir de
hnomi
L’appel peut alors avoir lieu
Tolérance aux pannes (service critique) : mémoire stable,
duplication des tables, des serveurs
Localisation du serveur de noms : Le portmapper a un numéro de port fixé par convention (111)
diffusion de la requête par le client Un service enregistre le numéro de port de son veilleur auprès
ou variable de configuration du système du portmapper
ou utilisation d’une adresse conventionnelle Le veilleur se met en attente sur ce port

Niveaux de protocole
Protocole
Talon d'appel Squelette d'acceptation
Définition d’un protocole de transaction
X = talon_proc(A,1,B) {
de transaction de messages de messages
ma = new Message();
Sérialisation/Désérialisation ma.entete(S,C,np);
des paramètres ma.sérialiser(A,1,B) ;
Trans.appel_envoyer(ma); Trans.accepter(ma,mr) {
Génération de talon d’appel Message.identifier(ma,S,C,np);
Message.désérialiser(ma,X,Y,Z);
(stub) et d’acceptation
R = S.proc[np](X,Y,Z);
(skeleton) mr=new Message();
Assistance par génération mr.entete(C);
mr.serialiser(R);
automatique de code return mr ;
Trans.réponse_recevoir(mres);
return mres.désérialiser(); }
}
Langage de description d’interface (IDL)
Description d’interface en IDL eXternal Data Representation

Exemple minimaliste (SUN)
Les langages IDL (Interface Definition Language) Description et codage des données indépendantes du matériel
Langage commun de description d’interface Structures de données arbitraires (structures, tableaux,
séquences)
Purement déclaratif : types de données, interfaces
RPC convertit les données machine en XDR avant de les
Base pour la génération des talons et squelettes
envoyer sur le réseau (sérialisation)
RPC convertit les données XDR en données machine après
struct arg { int a1; int a2; };
program MONSERVICE { lecture sur le réseau (désérialisation)
version MAVERSION { Génération automatique des routines de sérialisation et de
int PROC1 (arg) = 1; désérialisation à partir d’une description proche du langage C
int PROC2 (int, int) = 2;
ou codage manuel de ces routines à partir d’une librairie pour
} = 1;
} = 0x30000050; les types élémentaires

Programmation par appel explicite Appel explicite : client

int callrpc (const char *host,
u_long prognum, u_long versnum, u_long procnum,
xdrproc_t inproc, char *in, #include <stdio.h>
xdrproc_t outproc, char *out); #include <rpc/rpc.h>
int main()
{
Appel d’une procédure hprognum, versnum, procnumi sur la
int stat ;
machine host. La procédure reçoit en paramètre in codé avec int result ;
inproc et retourne out décodé avec outproc. char *argin = "546" ;
stat = callrpc (/*host*/ "cotiella",
int registerrpc (u_long prognum, u_long versnum, /*prognum*/ 87654321, /*versnum*/ 1, /*procnum*/ 12,
u_long procnum, /*inproc*/ xdr string, /*in*/ (char*) &argin,
char * (*procname) (char *arg), /*outproc*/ xdr int, /*out*/ (char*) &result) ;
xdrproc_t inproc, xdrproc_t outproc); if (stat != 0) { fprintf (stderr, "Call failed: ") ; /*. . .*/ }
printf ("Call succeeded: \"%s\" = %d\n", argin, result) ;
Enregistrement de la procédure procname sous le nom }
hprognum, versnum, procnumi. Le paramètre est décodé avec
inproc et le résultat est encodé avec outproc.
Appel explicite : serveur Diffusion & protocole

#include <rpc/rpc.h>
#include <stdlib.h> typedef bool_t (*resultproc_t) (char *out,
int resultat ; struct sockaddr_in *addr);
char *maproc (char *argin) int clnt_broadcast(u_long prognum, u_long versnum,
{ u_long procnum,
char *argument = *(char**)argin ; xdrproc_t inproc, char *in,
resultat = atoi(argument) ; xdrproc_t outproc, char *out,
return (char*) &resultat ; resultproc_t eachresult);
}
int main()
Envoi diffusé sur le réseau, la fonction eachresult est appelée
{
int stat ; pour chaque réponse obtenue.
stat = registerrpc (/*prognum*/ 87654321, /*versnum*/ 1, /*procnum*/ 12,
/*procname*/ maproc, Protocole de transport
/*inproc*/ xdr string, /*outproc*/ xdr int) ; Par défaut pour callrpc et clnt_broadcast, le protocole de
if (stat != 0) { fprintf (stderr, "Registering failed\n") ; /* . . . */ } communication est UDP. Pour callrpc, possibilité d’utiliser TCP
svc run() ; /* veilleur/aiguilleur */
} via client_create (à suivre).

Génération automatique : rpcgen RPCGEN : exemple

Un programme (fichier prog.c) appelle deux procédures distantes
À partir d’une description des types et d’une déclaration des (implantées dans rproc.c, décrites dans rpspec.x) d’un serveur
procédures, RPCGEN engendre : prog.c rpspec.x rproc.c
les routines XDR pour convertir les types de données

le talon client masquant l’appel à distance
RPCGEN
le talon serveur gérant l’appel
la procédure principale (main) et la procédure de sélection rpspec_clnt.c rpspec_svc.c
(dispatch) pour le serveur rpspec.h rpspec_xdr.c
Le programmeur doit : cc rpc lib cc
décrire les types de données échangées

prog rproc_svc
écrire la programme principal client space
écrire le code des procédures coté serveur $ rpcgen rpspec.x

$ cc -o server rproc.c rpspec_svc.c rpspec_xdr.c -lnsl
$ cc -o client prog.c rpspec_clnt.c rpspec_xdr.c -lnsl
RPCGEN : Fichier d’interface RPCGEN : un exemple de client

#include <rpc/rpc.h>
rpspec.x contient : #include "rpspec.h"
les noms, et les numéros de programme, de version et de main() {
procédures, des procédures distantes CLIENT *cl ;
les types de données manipulés long *res1 ;
struct arga *res2 ;
/* rpspec.x */
/* Mise en place du lien. cotiella est le nom de la machine distante. */
struct arga {
cl = clnt create ("cotiella", MONPROG, MAVERS, "tcp") ;
int arga1 ;
if (cl == NULL) { clnt pcreateerror ("cotiella") ; exit(1) ; }
int arga2 ;
};
res1 = rproca 1 ("45", 42, cl) ; /* appel de rproca version 1 */
if (res1 == NULL) { clnt perror (cl, "failed") ; exit (1) ; }
program MONPROG {
printf("Result: %ld\n", *res1) ;
version MAVERS {
long RPROCA (string, int) = 1 ; /* proc #1 */
res2 = rprocb 1 (cl) ; /* appel de rprocb version 1 */
arga RPROCB (void) = 2 ; /* proc #2 */
} = 1; /* version #1 */
clnt destroy (cl) ; /* fin du lien */
} = 0x1234567 ; /* prog num */
}
RPCGEN : procédures du serveur RPC : bilan

Apports
#include "rpspec.h"
Transparence partielle (désignation, localisation)
/* Implantation de RPROCA version 1 */ Modèle de programmation classique (appel procédural ↔
/* Passage par pointeur du retour */
/* req contient des informations de contexte */
interaction C/S )
long *rproca 1 svc (char *arg1, int arg2, struct svc req *req) { Conception modulaire
static long res ;
res = atoi(arg1) + arg2 ;
Outils de génération automatique des talons
return &res ;
} Limitations
Développement traditionnel monolithique
/* Implantation de RPROCB version 1 */
struct arga *rprocb 1 svc (struct svc req *req) { Construction et déploiement statique
/* . . . */ Structure d’exécution asymétrique, centralisée sur le serveur
}
Peu de services extra-fonctionnels : supervision, équilibrage de
charge, tolérance aux pannes, données rémanentes...
Introduction Sémantique et propriétés

Transparence Sérialisation
Mise en œuvre RMI de Java
Et variantes Plan
XML-RPC 1 L’appel procédural à distance

Un protocole RPC qui utilise XML pour encoder les données et Introduction
HTTP comme mécanisme de transport. Transparence
Sémantiques
SOAP (Simple Object Access Protocol) Paramètres
Désignation et liaison
Architecture client-serveur via des échanges de messages décrits en Mise en œuvre
XML. Neutralité du transport (HTTP, SMTP, TCP, JMS).
2 L’appel de méthode à distance
REST (Representational state transfer) Sémantique et propriétés
Sérialisation
Règles architecturales de construction d’applications client-serveur,
RMI de Java
s’appuyant sur HTTP et axé sur les ressources (RPC est axé sur les Exemple basique
actions). Une règle essentielle est que la relation client-serveur est Exemple : callback
sans état (pas de session).

Sémantique et propriétés Sémantique et propriétés
Sérialisation Sérialisation
RMI de Java RMI de Java
L’appel de méthode centralisé L’appel de méthode à distance
Principe et propriétés
Processus Deux espaces d’exécution
Principe et propriétés
Un seul espace Deux points de contrôle
d’exécution A oa Couplage plus faible
B ob
Point de contrôle unique Protocole de communication entre processus.
ob.m(); m(){...}
Fort couplage Processus client Processus serveur
Fiabilité
A oa B ob
Sécurité ob.m(); Réseau m(){...}

L’appel de méthode à distance Le passage de paramètres
Différences avec l’appel de procédure

Contexte d’exécution différent : l’un « module », l’autre
« objet »
Appel d’une méthode sur un objet autre
(ni sérialisable,
Aspect dynamique : création de « services » ni accessible à dist.)
+ transmission de services à distance
Processus Processus Processus Processus
client serveur client serveur erreur
Service S A oa B ob
procx(...); procx(...) {
ob.m(); m(){...}
...
};
C oc
Modèle
m'(){ };
Modèle d'exécution modulaire d'exécution à objets

Un objet est sérialisable, s’il appartient à une classe :

Définition qui implante l’interface java.io.Serializable
La sérialisation d’un graphe d’objets consiste à obtenir une ⇒ pas de code à fournir, mécanisme par défaut :
représentation linéaire inversible de ces objets et de leurs relations. Sont récursivement sérialisés les attributs non statiques ni
La désérialisation reconstruit une forme interne et structurée du transients contenant :
graphe d’objet. des types primitifs (int, bool. . . )
ou des objets qui doivent être sérialisables.
A C C ou qui implante l’interface java.io.Serializable et fournit
28 76
null
but : exportation vers un les méthodes (code utilisateur arbitraire) :
null fichier ou un autre processus
private void writeObject(java.io.ObjectOutputStream out)
B Difficulté : la présence de throws IOException;
String
123
coucou cycles private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;

Exemple sérialisation Compatibilité de versions
class A implements java.io.Serializable { Comment s’assurer, à l’endroit et au moment de la désérialisation,

public B b; que l’implantation de la classe est la même qu’à la sérialisation
public A a;
(mêmes attributs en particulier) ?
}
class B implements java.io.Serializable { ⇒ gestionnaire de version des classes
public A a;
} Solution élémentaire : un attribut statique serialVersionUID
a1 a2
A a1 = new A(); A a2 = new A(); a a (type long) dans chaque classe :
B b1 = new B(); B b2 = new B(); b b private static final long serialVersionUID = 76428734L;
a1.a = a2; a1.b = b1; b1 b2
a2.a = a1; a2.b = b2; a Par défaut si absent, le compilateur calcule un tel champ (à partir
a
b1.a = a1; b2.a = a1;
des attributs notamment), mais le calcul est sensible à son humeur
ObjectOutputStream oos = new ObjectOutputStream(
new FileOutputStream("/tmp/toto")); ⇒ à gérer soi-même.
oos.writeObject(a1);

Le mécanisme RMI (Remote Method Invocation) Talons : proxy/servant
Proxy
P1 P2
Objet local « remplaçant » l’objet distant = objet ayant la même pA sA A
interface que l’objet distant, et sachant appeler l’objet distant.
Servant Proxy = talon client = stub = a la même interface que l’objet

Objet interne sachant discuter à distance avec des proxys et applicatif distant.
localement avec l’objet applicatif.
Servant = talon serveur = squelette = reçoit les requêtes, appelle
Service de nommage la méthode correspondant de l’objet applicatif, et gère les erreurs.
Le servant peut être un objet distinct (association), ou être
Désignation globale par serveurs de noms (Registry)
commun à l’objet applicatif (héritage).

Obtenir un proxy ? Le mécanisme RMI

La gestion des proxys et squelettes
Comment obtenir un proxy sur un objet distant :

S2
Utiliser un service de nommage, qui conserve des associations S1
sA A R sA A
entre objet accessible à distance et nom externe (une chaîne sA A
pA pA
de caractères ou un URL) : le client demande au service de pA
pB pC
nommage de lui fournir un proxy correspondant à un nom B sB B sB B sB
externe donné. pC sC C pC sC C pC sC C
Avoir appelé une méthode (à distance) qui transmet/renvoie S3
S2 : création du proxy pB
un (autre) objet accessible à distance : création implicite des S1: Appel de pA.foo(B,4,pC) S1 −> S2 : Envoi de la requête (A, foo, B, 4, C)
création du proxy pC
appel de A.foo(pB,4,pC)
proxys.

Réalisation Mise en œuvre du protocole

Composants d’une classe d’objet accessible à distance
L’environnement Java fournit :
la génération dynamique des talons, en s’appuyant sur l’API
d’introspection
le proxy est généré à l’exécution, lors de la création d’une
référence à un objet accessible à distance, à partir de
l’environnement d’exécution du serveur ;
les fonctions du servant sont fournies et intégrées à l’objet
accessible à distance, par héritage ;
historiquement, il existait un générateur statique de talons
(rmic), analogue à rpcgen.
un service de nommage (package java.rmi.registry), pour
nommer symboliquement des objets accessibles à distance.
un mécanisme de chargement de code dynamique, qui permet
aux clients de charger le code des objets fournis en paramètre
lorsqu’il n’est pas disponible localement (en particulier le code
des proxys).

La description d’une classe d’objet accessible à distance La description d’une classe d’objet accessible à distance
Définition de l’interface d’appel

Hérite de l’interface Remote Définition de la classe d’implantation
Chaque méthode lève l’exception RemoteException Hérite de la classe UnicastRemoteObject
Un objet local non primitif doit être sérialisable : Implante l’interface du proxy correspondant
class ObjParam implements Serializable
Un objet accessible à distance peut être passé en paramètre Exemple
class ObjetAADImpl extends UnicastRemoteObject
Exemple implements ObjetAAD {
void m(int i,ObjParam p) {...}
interface ObjetAAD extends Remote {
String mm(OAADParam pr) {... }
void m(int i,ObjParam p) throws RemoteException;
...
String mm(OAADParam pr) throws RemoteException;
}
...
}
Exemple : un agenda Interface de l’agenda accessible à distance

Fait référence à l’interface Serializable. import java.rmi.*;
import java.util.Date;
public class RendezVous implements java.io.Serializable { import java.time.Duration;
private String qui; interface Agenda extends Remote {
private java.util.Date date; // est sérialisable public void ajouter(RendezVous rdv)
private java.time.Duration duree; // est sérialisable throws RemoteException;
private String salle; public boolean deplacer(RendezVous rdv, Date date)
throws RemoteException;
public String toString(){... } public boolean estLibre(Date date, Duration duree)
public RendezVous (String qui, Date date, Duration duree, public void effacer(String nom, Date date)
String salle) { throws RemoteException;
this.qui = qui; public RendezVous[] lister(String nom)
this.date = date; throws RemoteException;
this.duree = duree; public void importer(String nom, Agenda orig)
this.salle = salle; throws RemoteException;
} }
}

Agenda : une implantation Structure des classes

import java.rmi.*;
import java.rmi.server.*;
Génération statique ou dynamique des stubs et des skeletons.
public class AgendaImpl
extends UnicastRemoteObject implements Agenda { Remote UnicastRemoteObject
private Set<RendezVous> table = new HashSet<>();
extends RendezVous
extends
AgendaImpl() throws RemoteException { } Agenda
imple
men
Client ts
s
ment
AgendaImpl
public void ajouter(RendezVous rdv) { table.add(rdv); }
imple
.
.
. AgendaImpl_Stub AgendaImpl_Skel
public void importer(String nom, Agenda orig)
throws RemoteException { Serveur
RendezVous[] rr = orig.lister(nom);
⇒ Cas statique : utilisation du générateur rmic (obsolète)
for (RendezVous r : rr) this.table.add(r);
}
}
Agenda : un programme serveur Agenda : un programme client
import java.rmi.registry.*;
Cas où le serveur de noms est créé en tant que thread interne
// args[0] contient le site support du service de nommage
import java.rmi.registry.*; public static void main(String args[]) throws Exception {
Registry dns = LocateRegistry.getRegistry(args[0],1099);
public class Serveur { Agenda proxy = (Agenda)dns.lookup("Travail");
public static void main(String args[]) throws Exception { RendezVous rdv = new RendezVous("chef", new Date(...),
Agenda aa = new Agenda(); Duration.ofMinutes(30), "F303");
Registry dns = LocateRegistry.createRegistry(1099); proxy.ajouter(rdv);
dns.bind("Travail",aa); RendezVous[] tous = proxy.lister("chef");
} for (RendezVous r : tous) System.out.println(r.date);
} }
}
Exemple d’appel : java Client emeraude.enseeiht.fr


Concurrence Interface du service de nommage

java.rmi.registry.Registry : interface d’accès au nommage.
Les noms d’objets doivent obéir à la syntaxe générale des URL :
Chaque invocation d’une méthode par un appel à distance se fait
rmi://host:port/name, ou name si le contexte est non ambigu.
dans une activité (thread) distincte.
public class Registry {
Site 1 Objet O Site 2 public Remote lookup(String name)
throws NotBoundException, MalformedURLException,
Appel UnknownHostException, RemoteException;
Appel de public void bind(String name, Remote obj)
de O.m2()
O.m1() throws AlreadyBoundException, MalformedURLException,
UnknownHostException, RemoteException;
public void unbind(String name)
throws RemoteException, NotBoundException,
MalformedURLException, UnknownHostException;
⇒ nécessité de gérer la protection des attributs et autres données public String[] list(String name)
partagées (p.e. synchronized pour toutes les méthodes). throws RemoteException, MalformedURLException,
UnknownHostException;
}
Localisation et accès au service de nommage Remarques sur le service de nommage
La classe java.rmi.registry.LocateRegistry offre un

ensemble de méthodes pour créer ou obtenir l’accès à un serveur de
noms local ou distant : Le service de nommage peut aussi être une application
autonome (programme rmiregistry), et peut résider sur un
public final class LocateRegistry { site différent.
public static Registry getRegistry(String host, int port)
throws RemoteException, UnknownHostException; Un objet accessible à distance n’a pas nécessairement à être
... enregistré dans le service de nommage : seuls les objets racines
public static Registry createRegistry() le doivent.
}

Implantation du service de nommage Schéma de callback (rappel)

Le service de nommage n’est lui-même qu’un objet accessible à
But : permettre au serveur d’appeler un client l’ayant contacté
distance. C’est un objet « notoire », avec une identité fixée :
auparavant
hadr machine, no porti suffit à le trouver.
Augmenter l’asynchronisme : schéma publier/s’abonner :
class RegistryImpl extends java.rmi.server.RemoteServer { 1 appel client → serveur avec retour immédiat (s’abonner)
private Map<String, Remote> bindings 2 rappel serveur → client quand le service est exécuté (publier)
= new HashMap<String, Remote>();
Augmenter les interactions : le serveur peut demander au
public Remote lookup(String name) client des données complémentaires
throws RemoteException, NotBoundException Programmation événementielle
{
synchronized (bindings) { Principe
Remote obj = bindings.get(name);
Le client passe en paramètre au serveur l’objet à rappeler
if (obj == null) throw new NotBoundException(name);
return obj; Le serveur exécute un appel sur cet objet
}
} La relation client/serveur est conceptuelle, pas une relation
... d’usage !
Callback Exemple 2 : callback

Interfaces
// les deux interfaces des objets appelés à distance
public interface ICallback extends Remote {

Trigger
public void wakeUp(String msg) throws RemoteException;
}
public interface IServer extends Remote {

public void callMeBack(int time, String param,
ICallback callback) throws RemoteException;
}

Exemple 2 : callback Exemple 2 : callback

Trigger Serveur
import java.rmi.*;
public class Trigger extends Thread { import java.rmi.server.*;
private int time;
private String param; public class Server extends UnicastRemoteObject
private ICallback callback; implements IServer {
public Server() throws RemoteException { }
// le callback cb sera appelé avec param dans time seconds public void callMeBack(int time, String param,ICallback cb)
public Trigger(int time, String param, ICallback cb) { throws RemoteException {
this.time = time; this.param = param; this.callback = cb; Trigger action = new Trigger(time, param,cb);
} action.start();
}
public void run() { // exécution comme thread
try { public static void main(String[] args) throws Exception {
Thread.sleep(1000*time); // attend time secondes Server server = new Server();
callback.wakeUp(param); Naming.rebind("ReveilMatin", server);
} catch(Exception e) { e.printStackTrace(); } }
} }
}
Exemple 2 : callback RMI : Conclusion

Callback & client
public class Callback extends UnicastRemoteObject

implements ICallback {
public Callback() throws RemoteException { } Génération automatique des stubs et skeletons
public void wakeUp(String message) throws RemoteException {
System.out.println(message);
Sérialisation automatique (en général) par simple référence à
} l’interface Serializable
} Serveur multi-thread
Sémantique au plus une fois (at-most-once)
public static void main(String[] args) throws Exception { Problème : ramassage des objets accessibles à distance
Callback callback = new Callback(); Attention à la fiabilité : RemoteException
IServer serv = (IServer) Naming.lookup("ReveilMatin");
serv.callMeBack(5, "coucou", callback);
...
}
}
Introduction Introduction La communication par message
Les intergiciels à messages Les intergiciels à messages Exemple
Le standard JMS (Java Message Service) Le standard JMS (Java Message Service) Les principes
Plan
1 Introduction
Quatrième partie La communication par message
Exemple
Les principes
Intergiciels à message 2 Les intergiciels à messages

Fonctionnalités
Message Oriented Middleware Standardisation et produits
Kafka : un MOM évolué
3 Le standard JMS (Java Message Service)
Les concepts et principes
Les principales classes
Un exemple de publication/abonnement
Intergiciels 1 / 39 IV – Intergiciels à message 2 / 39
Introduction La communication par message Introduction La communication par message

Les intergiciels à messages Exemple Les intergiciels à messages Exemple
Le standard JMS (Java Message Service) Les principes Le standard JMS (Java Message Service) Les principes
La communication asynchrone par message Interaction par messages

Objectif : exploiter les possibilités d’une communication asynchrone
Avantages Modèle élémentaire
Évite le blocage de l’appelant inhérent à l’appel procédural Send(message, destination)
Découple l’envoi de la réception Receive(message, source)
Récepteur(s) anonyme(s)
Synchrone/asynchrone
Étend le simple protocole point-à-point
Communication synchrone : rendez-vous entre émission et
Autorise une communication de type publication/abonnement
réception bloquantes
(publish/subscribe) : protocole m → n
Communication asynchrone :
Émission non bloquante
Difficulté Réception bloquante, non déterministe
Programmation délicate car asynchrone :
Approche événementielle : Événement → Réaction
IV – Intergiciels à message 3 / 39 IV – Intergiciels à message 4 / 39

Paramètres Communication asynchrone par messages

Désignation
Communication point à point entre activités (canaux)
Envoi asynchrone : l’émetteur ne se bloque pas
Communication indirecte : passage par une boite à lettres
Réception sélective à la demande du récepteur
attachée à un processus (n → 1 : port, porte)
partagée par plusieurs processus (n → m : file de messages) Diffusion possible d’un message à plusieurs récepteurs
Statique (ex : IPv4) ou dynamique Couplage minimal entre émetteur et récepteur :
L’émetteur ne connaît pas le(s) récepteur(s) : il publie
Propriétés du service de communication Un récepteur doit explicitement souscrire pour recevoir
Un récepteur contrôle à quel moment il accepte
Fiabilité (perte)
Le récepteur peut ne pas être actif (présent) lorsque le
Intégrité message est envoyé
Qualité de service (débit, latence, gigue)
Usage : Architectures logicielles à composants
Ordonnancement relatif des réceptions par rapport aux
émissions (p.e. fifo)

Exemple : supervision d’un réseau Approche client-serveur

Contexte
Surveillance de l’état de machines, systèmes et applications
dans un environnement distribué
Flot permanent de données en provenance de sources diverses
sur le réseau
Possibilité permanente d’évolution (ajout, suppression,
déplacement des équipements)
Possibilité d’accès des administrateurs depuis n’importe quel
poste de travail
Objectifs
suivi des changements de configuration dynamiques Interactions synchrones
émission de messages signalant les changements d’état et les Communication essentiellement 1 vers 1 (ou n vers 1)
mises à jour Entités (clients, serveurs) désignées explicitement
statistiques, journal de fonctionnement Organisation de l’application plutôt statique
Approche client-serveur par inversion de contrôle Approche MOM
Client-serveur avec inversion du contrôle

Le service d’administration s’abonne auprès des clients sur les
événements qui l’intéressent
Les clients contactent le service d’administration en cas de tel
événement
⇒ mécanisme de « callback »
Entités (clients, serveurs) désignées explicitement Les composants administrés émettent des messages :
Organisation de l’application plutôt statique changements d’état et de configuration, d’alertes
horloge (relevé périodique, statistiques)
Découverte de nouveaux équipements ? Des processus cycliques (démons) mettent à jour l’état du
système à partir des notifications reçues
Inversion des rôles des producteurs et des consommateurs de
données

Communication indirecte Queue vs Sujet (Topic)

File de messages / Message Queue
Communication directe
Interface : ajouter dans la file, retirer dans la file
Plusieurs producteurs, plusieurs consommateurs
P1 P2
Retrait destructif
Site S1 Réseau Site S2 Persistance
Découplage temporel production / consommation
Communication indirecte Publication – abonnement / Publish – subscribe
Interface : envoyer un message, obtenir un message
Editeur Serveur Abonné
courtier Plusieurs producteurs, plusieurs consommateurs
Site S1 Site S3 Site S2 Retrait non destructif, mais chaque consommateur n’obtient
qu’au plus une fois chaque message
Abonnement pour délivrance asynchrone
L’échange par publication/abonnement (publish/subscribe) Modèle requête/réponse
Modèle client-serveur avec des messages :

Cl1 Cl2 Cl3
Une file de requêtes par serveur
s'abonner(QuelSujet)
délivrer(M)
Une file de réponse par client
publier(QuelSujet)
envoyer(M) s'abonner(QuelSujet) Une requête identifie la file de réponse à utiliser
Serveur
QuelSujet délivrer(M)
Client :
1 envoyer message de requête sur la file de requête
2 attendre message de reponse sur sa file de réponse
Serveur :
1 attendre message de requête sur la file de requête
Précédence temporelle : on ne peut recevoir que ce qui a été 2 traiter la requête
publié après s’être abonné (contrairement à une queue) 3 envoyer message de reponse sur la file de réponse identifiée
dans la requête
Introduction La communication par message Introduction Fonctionnalités

Les intergiciels à messages Exemple Les intergiciels à messages Standardisation et produits
Le standard JMS (Java Message Service) Les principes Le standard JMS (Java Message Service) Kafka : un MOM évolué
Domaine d’application : systèmes faiblement couplés Plan
Découplage temporel : interactions asynchrones / systèmes 1 Introduction

autonomes communicants La communication par message
Communication en mode « push » : découverte des évolutions Exemple
de l’environnement Les principes
Fonctionnement en mode déconnecté : site absent ou
utilisateur mobile 2 Les intergiciels à messages
Fonctionnalités
Découplage spatial : systèmes à grande échelle
Standardisation et produits
Fonctionnement en mode partitionné / déconnecté
Communication « anonyme » Kafka : un MOM évolué
Communication n–m 3 Le standard JMS (Java Message Service)
Découplage sémantique : systèmes hétérogènes Les concepts et principes
Modèle d’interaction minimal → possibilité d’intégrer des Les principales classes
environnements (systèmes, réseaux) / applications hétérogènes Un exemple de publication/abonnement

Introduction Fonctionnalités Introduction Fonctionnalités
Les intergiciels à messages Standardisation et produits Les intergiciels à messages Standardisation et produits
Le standard JMS (Java Message Service) Kafka : un MOM évolué Le standard JMS (Java Message Service) Kafka : un MOM évolué
Les intergiciels à messages Architectures du service courtier

MOM : Message-Oriented Middleware
Centralisée Snowflake
C C C S C
Architecture et fonctionnalités de base
S S
Les clients (applicatifs) s’adressent à un serveur S
C S C
Ils envoient/recoivent leurs messages au(x) serveur(s)
C C S
Un service courtier (broker ou provider) sert d’intermédiaire
pour stocker et router les messages vers leurs destinataires
Le protocole d’échange peut être de type publier/s’abonner
(publish/subscribe) C S C
Critère de réception par le contenu, par le sujet (topic) S S
C S C C C
Gestion de la persistance des messages
C
Communication point-à-point possible
Distribuée Bus logiciel

Intergiciel à messages (suite) Intergiciel à messages (suite)

Les éléments d’un intergiciel à message
Fonctionnalités complémentaires
Service de gestion des messages implanté par un ou plusieurs
serveurs (providers) Définition de priorités entre messages
Une API client Compression des données utiles du messsage
Les objets messages pour communiquer Échéance maximale pour recevoir un message
Publication à date minimale fixée
La notion de message Routage des messages d’un serveur à l’autre (forward)
l’en-tête ou header qui contient les informations de gestion : Lancement d’applications lorsque des messages sont
file destinataire, identifiant du message disponibles pour elles
dates de disponibilité, d’échéance, . . .
Possibilité d’alertes sur critères :
les propriétés : suite de couples (clé,valeur) précisant le Présence de messages dans une file donnée
contenu du message Nombre de messages présents
les données applicatives (charge utile ou payload)
La standardisation et les produits MOM Apache Kafka
API standard pour Java : JMS (Java Message Service) A distributed streaming platform
Quelques MOM :
Distribution, stockage et traitement de flux de données
Open Message Queue (intégré dans GlassFish, implantation de
référence) Points forts : haut débit, latence faible, tolérant aux fautes
ActiveMQ de Apache → traitement de gros flux de données temps réel
Joram de l’INRIA (intégré dans Jonas)
OpenJMS Les données
Autres standards : Un flux est identifié par un sujet (topic)
HLA (High-Level Architecture) pour interconnecter des
simulateurs Un flux est constitué d’enregistrements (record )
XMPP (eXtensible Messaging and Presence Protocol) Un enregistrement contient une clef, une valeur et une date
AMQP (Advanced Message Queuing Protocol) (timestamp)
Microsoft Message Queuing (MSMQ)

Les APIs Topic et partitions
Producer : publication
d’enregistrements
Consumer : abonnement à
des topics et obtention
d’enregistrements
Streams : transformation de
flux, un ou des flux en Un topic est multi-producteurs, multi-consommateurs
entrée, un ou des flux en Un topic est décomposé en partitions → parallélisation
sortie
Chaque partition contient une séquence ordonnée et immuable
Connector : vision flux de d’enregistrements, strictement croissante
BD source : https://kafka.apache.org
Immuable : pas d’effacement à la consommation (mais
possibilité de délai de rétention avec oubli)
Consommation Distribution & tolérance aux fautes
Un Kafka cluster est un ensemble de serveurs sur un ensemble

de machines
Chaque partition est répliquée sur plusieurs serveurs
Chaque partition possède un serveur leader et des serveurs de
secours
Le leader gère toutes les lectures et écritures, les secours
suivent passivement
Un algorithme d’élection choisit un nouveau leader en cas de
Les producteurs d’une partition ajoutent en queue défaillance (cf cours Systèmes répartis)
Chaque consommateur a un offset, qu’il peut changer En pratique, un serveur leader d’une partition est secours pour
arbitrairement (pour retourner en arrière ou pour sauter aux d’autres partitions du même ou d’autres topics
plus récents enregistrements)

Architecture globale Traitement de flux

Séparation (branch) : scission d’un flux en plusieurs flux
Filtrage : flux limité aux enregistrements vérifiant un prédicat
map : applique une transformation à chaque enregistrement
flatmap : applique une transformation à chaque
enregistrement, pour produire 0, 1 ou plusieurs enregistrements
Agrégation des enregistrements ayant la même clef en un
unique enregistrement
Comptage des enregistrements d’une même clef
Jointure de plusieurs flux
Un producteur publie dans une partition d’un topic builder.stream("visiteurs-topic")
Les consommateurs forment des groupes. .filter((nom, date) -> date >= today - 7)
Un groupe reçoit depuis toutes les partitions, mais un .map((nom, date) -> KeyValue.pair(nom.toLowerCase(),date))
enregistrement n’est délivré qu’une fois par groupe (à un seul .groupByKey()
consommateur) .count()
.filter((nom, count) -> count > 100)
→ partage de charge
.to("clients-fidèles-topic");
Introduction Fonctionnalités Introduction Les concepts et principes
Les intergiciels à messages Standardisation et produits Les intergiciels à messages Les principales classes
Le standard JMS (Java Message Service) Kafka : un MOM évolué Le standard JMS (Java Message Service) Un exemple de publication/abonnement
Plusieurs points de vue Plan
1 Introduction
La communication par message
Kafka est . . . Exemple
Les principes
un intergiciel à messages, unifiant queue et abonnement, avec
objectif de performance (de Kafka et des applications 2 Les intergiciels à messages
l’utilisant) → parallélisation Fonctionnalités
un système de stockage d’informations incrémentales, fiable Standardisation et produits
(réplication) et performant Kafka : un MOM évolué
un système de traitement de flux 3 Le standard JMS (Java Message Service)
Les concepts et principes
Les principales classes
Un exemple de publication/abonnement
Introduction Les concepts et principes Introduction Les concepts et principes

Les intergiciels à messages Les principales classes Les intergiciels à messages Les principales classes
Le standard JMS (Java Message Service) Un exemple de publication/abonnement Le standard JMS (Java Message Service) Un exemple de publication/abonnement
Le standard JMS (Java Message Service) Les objets de communication

Les objets globaux (administrés) accessibles à distance
Désignation par JNDI (Java Naming and Directory Interface)
Les fabriques de connexions (connection factories)
Les destinations réparties en 2 domaines de désignation :
files (queues) et sujets (topics)
Ces objets sont créés dans le(s) serveur(s) courtier(s)
createConsumer
implantant JMS createProducer
Les objets clients

Les connexions permettent de se connecter à un serveur JMS
Les sessions gèrent les échanges via une file ou un sujet
Les producteurs/consommateurs de messages pour l’envoi/la
réception de messages dans le cadre d’une session
Les objets – Queue Les objets – Topic
ConnectionFactory ConnectionFactory
Topic
Connection Connection Connection Connection
/
topic
Queue a b
x y
Session Session Session Session
Producer Consumer Producer Consumer

listener

Un exemple de publication/abonnement Un exemple de publication/abonnement

Le client éditeur : nom de la destination fourni dans args[0] Un client abonné : nom de la source fourni dans args[0]
import javax.jms.* ; import javax.naming.* ;

public class Editeur { import javax.jms.* ; import javax.naming.* ;
public static void main(String[] args) { public class Abonne {
try { public static void main(String[] args) {
InitialContext jndiCtx = new InitialContext(); try {
ConnectionFactory scf = (C...) jndiCtx.lookup("MaConnFactory"); InitialContext jndiCtx = new InitialContext();
Destination dest = (Destination) jndiCtx.lookup(args[0]); ConnectionFactory scf = (C...) jndiCtx.lookup("MaConnFactory");
Connection conn = scf.createConnection(); Destination src = (Destination) jndiCtx.lookup(args[0]);
conn.start(); Connection conn = scf.createConnection();
Session session = Session session =
conn.createSession(false,Session.AUTO_ACKNOWLEDGE); conn.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageProducer editeur = session.createProducer(dest); MessageConsumer abonné = session.createConsumer(src);
TextMessage m = session.createTextMessage(); abonné.setMessageListener(new MonMsgListener());
m.setText("publication exemple"); conn.start();
editeur.send(m); ... ...
}
Un exemple de publication/abonnement Un exemple de publication/abonnement

Le traitant activé sur occurrence d’un message La création des objets globaux
import org.objectweb.joram.client.jms.tcp.TcpConnectionFactory;
public class CreateDestination {
import javax.jms.* ; public static void main(String args[]) throws Exception {
public class MonMsgListener implements MessageListener { // Creating the JMS administered objects:
public void onMessage(Message m) { javax.jms.ConnectionFactory connFactory
try { = TcpConnectionFactory.create("localhost", 16010);
if (m instanceof TextMessage) {
TextMessage msg = (TextMessage) m ; Destination destination = Topic.create(0);
System.out.println(msg.getText()) ; // Destination destination = Queue.create(0);
}
} catch (JMSException je) {...} // Binding objects in JNDI
} javax.naming.Context jndiCtx = new InitialContext();
} jndiCtx.bind("MaConnFactory", connFactory);
jndiCtx.bind("MonTopic", destination);
}
}
Introduction Les concepts et principes

Les intergiciels à messages Les principales classes
Le standard JMS (Java Message Service) Un exemple de publication/abonnement
Conclusion
Mode de communication adaptée à la circulation des

informations dans le système informatique des entreprises
Intégration dans des intergiciels à base de composants
Mécanisme de base dans les bus de services
IV – Intergiciels à message 39 / 39
Vocabulaire
Sûreté de fonctionnement Sûreté de fonctionnement
Les moyens
Serveurs à haute disponibilité Serveurs à haute disponibilité
Principes
Tolérance aux fautes pour les données Tolérance aux fautes pour les données
Traitement des erreurs
Plan
1 Sûreté de fonctionnement
Vocabulaire
Cinquième partie Les moyens
Principes
2 Serveurs à haute disponibilité
Tolérance aux fautes Redondance froide
Redondance passive
Redondance active
Groupes et synchronisme virtuel
3 Tolérance aux fautes pour les données
Techniques logicielles
Techniques matérielles
Intergiciels 1 / 44 V – Tolérance aux fautes 2 / 44
Vocabulaire Vocabulaire
Les moyens Les moyens
Principes Principes
Traitement des erreurs Traitement des erreurs
Sûreté de fonctionnement Mesures de fiabilité et disponibilité
Fiabilité
Availability, disponibilité : capacité à être prêt à délivrer un MTTF (mean time to failure) : temps moyen jusqu’à la
service prochaine panne
Reliability, fiabilité : continuité de service MTTR (mean time to repair) : temps moyen de réparation
Safety, sécurité/sûreté : absence d’effets catastrophiques sur MTBF (mean time between failure) = MTTF + MTTR
l’environnement
Security, sécurité : préservation de la confidentialité et de Disponibilité
l’intégrité des informations Disponibilité moyenne = fraction du temps où le système est
Repairability, maintenabilité : capacité à restaurer un service disponible
correct après une défaillance Pannes franches : dispo moyenne = MTTF/(MTTF+MTTR)
99.99% (4 nines) indisponible 50 min / an
99.999% (5 nines) indisponible 5 min / an
V – Tolérance aux fautes 3 / 44 V – Tolérance aux fautes 4 / 44
Principes Principes
Différence entre fiabilité et disponibilité Le vocabulaire

Indisponibilité = 1 - disponibilité = MTTR/(MTTF + MTTR) Défaillance (failure)
≈ MTTR/MTTF (si MTTR MTTF ) Déviation par rapport à la spécification.
⇒ diviser MTTR par 2 = doubler MTTF Manifestation d’une erreur vis-à-vis du service.
Différence entre fiabilité (MTTF) et disponibilité (a)
Erreur (error)
Partie de l’état du système entraı̂nant la défaillance.
Manifestation d’une faute vis-à-vis du système.
Note : une erreur est susceptible de causer une défaillance mais pas
nécessairement (erreur latente, erreur compensée. . . )
Faute (fault)
Cause de l’erreur.
Ex : faute de programmation ⇒ division par 0 ⇒ arrêt du service
(dessin : S. Krakowiak) virus de la grippe ⇒ malade ⇒ absent en cours
Principes Principes
Cascade/Propagation Classification informelle des fautes

Point de vue
nature : accidentelle ou intentionnelle
origine : matérielle ou humaine
défaillance erreur faute défaillance erreur
client
faute création : conception ou opération
de A persistance : permanente ou temporaire
A B
Le bon fonctionnement de A dépend du bon fonctionnement faute physique : accidentelle, matérielle, opération, permanente
de B faute transitoire : accidentelle, matérielle, opération, temporaire
Une défaillance de B constitue une faute pour A faute intermittente : accidentelle, matérielle ou humaine,
Cette faute peut à son tour provoquer une erreur interne de conception, temporaire
A, causant une défaillance de A faute de conception : accidentelle, humaine, conception, permanente
faute d’interaction : accidentelle, humaine, opération, temporaire
attaques, intrusions : intentionnelle, humaine, conception ou
opération
Principes Principes
Classification des défaillances Défaillance d’arrêt

Si, suite à une première omission, le serveur ignore toutes les
Un serveur doit rendre un service correctement, i.e. conformément
requêtes jusqu’à ce qu’il soit redémarré, on parle de panne franche,
à une spécification (valeur, transition, vitesse. . . ).
défaillance d’arrêt, crash failure ou fail stop.
défaillance d’omission : le service ignore une requête
Redémarrage
défaillance temporelle : la réponse est fonctionnellement
correcte mais pas au bon moment amnesia-crash : état initial indépendant de l’état avant crash
défaillance temporelle d’avance : réponse trop tôt pause-crash : état identique à l’état avant crash
défaillance temporelle de retard : réponse trop tard (défaillance halting-crash : pas de redémarrage (crash définitif)
de performance)
défaillance de réponse : réaction inadaptée à la requête
Défaillance d’arrêt = cas le plus simple, auquel on essaie de se
défaillance de valeur : valeur renvoyée erronée
défaillance de transition : transition interne erronée ramener (arrêt forcé sur tout type de défaillance)
défaillance arbitraire ou byzantine Note : un client ne peut pas distinguer entre un serveur
planté , un serveur lent ou une défaillance du réseau.
Principes Principes
Les moyens de la sûreté de fonctionnement Exemples
Construction
Prévention des fautes : comment empêcher par construction,
l’occurrence ou l’introduction de fautes Écrire un programme sans (trop de) bugs = prévention
(méthodologie de développement) + élimination (vérification
Tolérance aux fautes : comment fournir un service conforme à
de types, preuves, tests. . . )
la spécification, en dépit de fautes
S’adapter à un environnement hostile = prévision (à quoi
Validation faut-il s’attendre ?) + tolérance (que faut-il faire ?)
Empêcher le piratage = prévision (quelles attaques ?) +
Élimination des fautes : comment réduire, par vérification et
prévention (cryptographie. . . )
tests, la présence de fautes
Prévision des fautes : comment estimer, par évaluation, la
présence et l’apparition de fautes

Principes Principes
Principes de la tolérance aux fautes Méfiance

Traiter les erreurs
Nombreux pièges :
Détecter l’existence d’un état incorrect (erreur)
Mauvaise analyse des fautes possibles
Remplacer l’état incorrect par un état correct
Réaction inappropriée due à des hypothèses mal formulées : le
Traiter les fautes remède aggrave la situation
Composants multiples, pour réduire la probabilité qu’une faute Redondance mal conçue :
dans l’un d’entre eux conduise à une défaillance de l’ensemble Éléments redondants ayant des modes de défaillance identiques
Faux sentiment de sécurité
Traitements multiples
Il n’existe pas de méthodes de tolérance aux fautes valables dans
Principe : la redondance l’absolu, seulement des méthodes adaptées à des hypothèses
Redondance d’information (détection d’erreur) particulières d’occurrence de fautes. Ces hypothèses doivent donc
Redondance temporelle (traitements multiples) être explicitement formulées, après analyse soigneuse. S.Krakowiak
Redondance architecturale (composants multiples)

Principes Principes
Traitement des erreurs Recouvrement

Recouvrement (error recovery)
Reprise (backward recovery)
Remplacer l’état incorrect par un état correct
Détecter l’erreur Retour en arrière vers un état antérieur dont on sait qu’il est
explicitement (vérifier des propriétés spécifiques à l’état) correct
implicitement (observation d’anomalies : délai de garde, Nécessite la capture et la sauvegarde de l’état
protection mémoire. . . ) Technique générale
Deux techniques de recouvrement :
Coûteuse en temps et place
Reprise (backward recovery)
Poursuite (forward recovery)
Poursuite (forward recovery)
Compensation (error masking) Reconstruction d’un état correct, sans retour en arrière
L’état possède une redondance interne suffisante pour Reconstruction souvent partielle, service dégradé
détecter et corriger l’erreur
Technique spécifique à l’application et aux types d’erreurs
Totalement transparent pour l’utilisateur
possibles
Par exemple : vote majoritaire interne
Principes Principes
Reprise Points de reprise en réparti
Soit prise de clichés (⇒ état cohérent possible)

Reprise
Soit des points de reprise individuels + construction d’un état
Le système est remis dans un état précédant l’occurrence de global cohérent
l’erreur ⇒ risque d’effet domino
⇒ points de reprise pour sauvegarder l’état (périodiquement, 4 1
ou sur transition importante) P1 envoi
x
Point de Erreur
reprise 5 2
détectée
La sauvegarde et la restauration doivent être atomique (pas
d’interférences) P2 réception
L’état des points de reprise doit lui-même être protégé contre 6 3

les fautes P3
État global cohérent
Vocabulaire Redondance froide

Les moyens Redondance passive
Principes Redondance active
Traitement des erreurs Groupes et synchronisme virtuel
Compensation Plan
Exemple : vote majoritaire
Vocabulaire
Les moyens
Principes
2 Serveurs à haute disponibilité
Redondance froide
Redondance passive
Redondance active
Résiste à la défaillance d’un composant de traitement et d’un Techniques logicielles
voteur par étape Techniques matérielles
(dessin : S. Krakowiak)
Redondance froide Redondance froide
Redondance passive Redondance passive
Redondance active Redondance active
Groupes et synchronisme virtuel Groupes et synchronisme virtuel
Serveur tolérant aux fautes Serveur primaire – secours froids

Redondance : N serveurs pour résister N − 1 pannes franches
(en attente)
client
Redondance froide (reprise)
requête réponse
Points de reprise serveur traitement
Serveurs de secours prêts à démarrer primaire
point de restauration
reprise de l'état
Redondance passive (poursuite) serveur
de secours
Serveur de primaire – serveurs de secours
Un seul serveur (le primaire) exécute les requêtes des clients Panne visible par le client
La panne du primaire est visible des clients Points de reprise : périodiquement, ou à chaque transition
importante
Redondance active (compensation)
Simple mais latence de reprise
N serveurs symétriques exécutant toutes les requêtes
La panne d’un serveur est invisible aux clients (tant qu’il reste Retour en arrière ⇒ requêtes traitées mais oubliées
un serveur !)

Serveur primaire – serveurs de secours Défaillance du serveur primaire

délai de garde
(en attente) (en attente)
client client
requêt
requête
réponse 1 2 requête
répétée
serveur
serveur traitement primaire
primaire
ack ack
nouvel état secours 1
+ réponse
secours 1
secours 2
secours 2 Détection de la défaillance par le client et par les secours

Le client renvoie sa requête au secours devenu primaire
Diffusion fiable (pas de diffusion partielle)
(élection ou ordre défini à l’avance)
Cohérence : quand le primaire répond, tous les serveurs non Diffusion fiable ⇒ tous les serveurs sont à jour, ou aucun :
en panne sont dans le même état Si la panne est arrivée en 1 (aucun serveur à jour) ⇒ comme
Poursuite : tout serveur de secours peut remplacer le primaire une nouvelle requête
Si la panne est arrivée en 2 (tous les serveurs à jour) ⇒
en cas de panne
renvoie de la réponse déjà calculée
Les requêtes ont un identifiant unique, pour distinguer 1 et 2.
Cas particulier : 1 seul secours (Alsberg & Day) Redondance active

(en attente)
client
requête
réponses
traitement
(en attente) serveur
client
requête
réponse traitement
serveur
serveur traitement
primaire
nouvel état ack traitement
serveur
+ réponse
secours Tous les serveurs sont équivalents et exécutent le même
Protocole plus simple (pas besoin de diffusion fiable) traitement
Le client choisit la première réponse (panne d’arrêt), ou la
Réponse envoyée par le secours
réponse majoritaire (panne arbitraire)
Diffusion fiable et totalement ordonnée (atomique) :
Message délivré par tous les destinataires ou aucun
Deux messages différents sont délivrés dans le même ordre sur
tous les destinataires communs

Nécessité de la diffusion atomique Modèle : réplication de machine à états (Lamport 1984)

Machine à états
requête 1
client
M = (S, I, O, T , ω, s0 ) où
client S, I, O, s0 = ensemble d’états / d’entrée / de sortie / état initial
requête 2
T = fonction de transition S → I → S
T1
serveur
T2
ω = fonction de sortie S → I → O
T et ω sont déterministes.
T1 T2
serveur
Principe
T1 T2 Répliquer la machine à états décrivant le service
serveur
Le serveur 1 traite la requête 2 avant la 1, alors que les serveurs 2 I = requêtes des clients, O = réponses aux clients
et 3 traitent 1 puis 2 ⇒ état incohérent si les traitements Évolution asynchrone des réplicas (chacun à son rythme)
modifient l’état des serveurs (traitements non commutatifs) Même ordre de traitement des requêtes + déterminisme ⇒
même séquence de sorties pour tous les réplicas
Défaillance détectée par divergence des états ou des sorties
Comparaison redondance froide/passive/active Groupes de processus

Travaux de Kenneth P. Birman (Cornell University)
Mécanismes nécessaires : Protocoles de groupes
Diffusion fiable pour passive, fiable-atomique pour active
Coordination des départs/arrivées (notion de vue, à suivre) Gestion d’un ensemble de processus avec des opérations pour
Ressources : l’appartenance : évolution de la composition du groupe,
Serveur froid : éteint ; reprise longue connaissance de la composition du groupe
Serveur primaire : serveurs de secours non utilisés ⇒ gratuits /
la diffusion : communication vers un ensemble de processus
utilisés pour autre chose ; reprise non immédiate
Redondance active : exécutions superflues ; reprise immédiate Motivations :
Transparence pour le client : uniquement en redondance active ensemble de processus se comportant comme un processus
Sensibilité aux bugs logiciels : même état + même entrée ⇒ unique, avec tolérance aux fautes (réplication)
même bug ⇒ tous se plantent. . . (redondance froide moins travail coopératif, partage d’information
sensible : retour en arrière)
Système critique : combinaison des trois techniques
compensation/poursuite/reprise : 2 serveurs actifs + 1 secours
passif + 1 secours froid avec points de reprise
Groupe de pairs Groupe client-serveur groupe de diffusion groupe hiérarchique

Service de groupes : interface Protocoles de groupe : l’appartenance
Groupe
diffuser(p,m) : le processus p Le service d’appartenance (membership) vise à fournir à tout
Processus
diffuse le message m au groupe instant à chaque membre du groupe une vue de la composition
délivrer(p,m) : le message m est courante du groupe.
délivré à p Partition primaire : la suite des vues fournies aux membres est
diffuser changement
changement-de-vue(p,id,V) : une délivrer de vue totalement ordonnée. Il n’y a pas de partition, ou de manière
nouvelle vue V (= ensemble de équivalente, un unique primaire.
processus) identifiée par id est service de groupe
Partition multiple : la suite des vues fournies aux membres est
délivrée au processus p envoyer recevoir partiellement ordonnées. Il peut y avoir simultanément
La diffusion se fait toujours dans la vue système de communication plusieurs vues disjointes.
courante

Diffusion Propriétés indépendantes de l’ordre d’émission

Envoi d’un message à un ensemble de destinataires Diffusion fiable
Diffusion générale (broadcast) Un message est délivré à tous les destinataires corrects ou à aucun.
Les destinataires sont tous les processus d’un ensemble défini
implicitement (p.e. tous les processus du système). L’émetteur est Diffusion totalement ordonnée (dite atomique)
généralement aussi destinataire. La diffusion est fiable et les messages sont délivrés dans le même
broadcast(émetteur, message) ordre sur tous leurs destinataires.
t2 t2
P1
Diffusion de groupe (multicast) t1 t1
P2
Les destinataires sont un ou plusieurs groupes spécifiés. L’émetteur
peut ne pas appartenir aux groupes destinataires. Les groupes G1
peuvent ne pas être disjoints. G2

multicast(émetteur, message, {groupe1, groupe2...})
L’ordre total peut (ou non) être compatible avec la causalité

Uniformité Propriétés liées à l’ordre d’émission

Diffusion fiable uniforme
Diffusion FIFO
Si un message est délivré à un processus (correct ou défaillant), il
Deux messages d’un même émetteur sont délivrés dans l’ordre de
sera délivré à tous les processus corrects
leur émission.
6= avec diffusion fiable : délivrance à tous les processus corrects ou m1 m2 m1 m2
P1
aucun, on ne se préoccupe pas des processus défaillants.
P2
P1
Diffusion causale
P2 L’ordre de délivrance respecte la causalité de l’ordre (causal)
P3 d’émission.
c2 c2
P1
P4
m m
Non uniforme (mais fiable) Uniforme c1 c1
P2
Nécessaire si un processus défaillant peut (avant sa défaillance)
G1
exécuter des actions irréversibles, notamment vis-à-vis de
G2
l’extérieur.
Classes de propriétés Diffusion anarchique

C1 C2 S1 S2 S3
m1
fiable atomique
m2
Ordre causal ? m3
fiable FIFO atomique FIFO Ordre total ?

m4
Atomicité ?
crash
Arrêt/Reprise ?
fiable causale atomique causale m5
état

groupe avec synchronisme fort groupe avec synchronisme virtuel

C1 C2 S1 S2 S3 C1 C2 S1 S2 S3
m1 m1
m2 m2
m3 m3
m4
crash
m4 crash
S4
m5 m5

Redondance froide
Redondance passive Techniques logicielles
Redondance active Techniques matérielles
Le synchronisme virtuel Plan

Vocabulaire
Une vue = état d’un groupe (ensemble des membres) Les moyens
Garantir qu’une diffusion est délivrée dans la vue où elle a été Principes
émise Traitement des erreurs
Garantir que, entre deux changements de vue, tous les 2 Serveurs à haute disponibilité
membres reçoivent les mêmes messages Redondance froide
Garantir que tous les membres voient la même séquence de Redondance passive
changements de vue Redondance active
Progression limitée à la partition majoritaire
Techniques logicielles
Techniques matérielles

Techniques logicielles Techniques logicielles
Techniques matérielles Techniques matérielles
Techniques logicielles RAID – Redundant Array of Inexpensive/Independent Disks
Réplication des données : plusieurs exemplaires d’une même Plusieurs disques sur lesquels on partitionne et duplique les
donnée sur différents sites données
⇒ meilleure performance (accès parallèle)
Abordé à peine cours suivant ⇒ meilleure disponibilité (redondance)
e
Développé dans cours Systèmes et algorithmes répartis en 3 Multiples configurations selon besoins
année
(non développé)

Exemples
Système de fichiers réparti Système de fichiers réparti
Principe
Mémoire virtuelle répartie Mémoire virtuelle répartie
Plan
1 Introduction
Sixième partie Exemples
Principe
Mémoire virtuelle 2 Système de fichiers réparti

Les principes et objectifs
Systèmes de fichiers NFS – Network File System
Sémantique de la concurrence
3 Mémoire virtuelle répartie

Principe et objectifs
Mise en œuvre
Intergiciels 1 / 35 VI – Mémoire virtuelle 2 / 35
Exemples Exemples
Principe Principe
Origine Mémoire partagée en multi-processeurs multi-cœurs

CPU Cache L1
Cache L2
CPU Cache L1
Réplication Mémoire
CPU Cache L1
Placement de plusieurs exemplaires d’une même donnée sur Cache L2
différents sites. CPU Cache L1
Exemples de partage : Cohérence des écritures en présence de caches ?

partage de la mémoire commune dans un SMP (symmetric Write-Through diffusion sur le bus à chaque valeur écrite
multi-processor) + visible par les autres processeurs
partage d’un système de fichiers (NFS) + la mémoire et le cache sont cohérents
partage de mémoire virtuelle − trafic inutile : écritures répétées, écritures privées
Write-Back diffusion uniquement à l’éviction de la ligne
+ trafic minimal
− cohérence cache - mémoire - autres caches ?
VI – Mémoire virtuelle 3 / 35 VI – Mémoire virtuelle 4 / 35
Exemples Exemples
Principe Principe
Mémoire partagée en NUMA Système de fichiers partagé/réparti

Non-Uniform Memory Access
Partage d’un système de fichier
CPU CPU CPU

RAM RAM RAM
CPU CPU CPU

RAM RAM RAM
cache NFS sur les sites clients

invalidations périodiques
Exemples Exemples
Principe Principe
Mémoire virtuelle partagée (centralisée) Mémoire virtuelle partagée (distribuée)
partage de segments (suite de pages)

partage de la mémoire centrale par couplage

Exemples Exemples
Principe Principe
Principe général Paramètres d’implantation
Niveau
Matériel (multiprocesseurs)
Principe : fournir des objets partagés par couplage dans les
Système d’exploitation (pagination)
espaces d’adressage de structures d’exécution (couplage
virtuel) réparties Langages ou librairies utilisateurs
Partage par copie locale (efficacité)
Unité de partage
Programmation simple (accès local)
Octets / Pages / Objets
Le système charge éventuellement les données à la demande
Le système assure la cohérence des données partagées Cohérence
Propagation des mises à jour
Différents degrés de cohérence acceptables
Introduction Les principes et objectifs Introduction Les principes et objectifs

Système de fichiers réparti NFS – Network File System Système de fichiers réparti NFS – Network File System
Mémoire virtuelle répartie Sémantique de la concurrence Mémoire virtuelle répartie Sémantique de la concurrence
Plan Architecture d’un système de fichiers

Service de fichiers à plat (flat file system)
1 Introduction Service de nommage (répertoires)
Exemples Module client : API simple et unique, indépendante de
Principe l’implantation
Client Kernel or Server
2 Système de fichiers réparti
Application Application Directory service
Les principes et objectifs program program
NFS – Network File System
Flat file service
Client module
3 Mémoire virtuelle répartie
Mise en œuvre
(source : Coulouris – Dollimore)

Architecture de NFS Idée de base de NFS : le montage à distance de volumes

Client computer Server computer Montagedevolumesàdistance
mount /dev/disk0s3 /sys/mach / mount rubis:/dev/disk0s1 /projets
Application Application
program program dev projets
UNIX Siterubis
system calls sys
UNIX kernel
dev
UNIX kernel Virtual file system Virtual file system
Local Remote mach mach.sym
disk0s1
file system
UNIX UNIX
NFS NFS
file file Volume
client server
Other
system system local

NFS bin distant
protocol
disk0s3
Volume
(source : Coulouris – Dollimore) local sh cat

Exemple NFS SGF centralisé

Transparence de localisation et hétérogénéité
La notion de virtual file system (VFS) API Unix

Étend la notion de système de fichiers (file system) aux canal open(nom,mode) connexion du fichier à un canal
volumes à distance et à des systèmes de fichiers hétérogènes canal creat(nom, mode) connexion avec création
VFS → un volume support d’un système de fichiers particulier
close(canal) déconnexion
La notion de virtual node (vnode) int read(canal,tampon,n) lecture de n octets au plus
int write(canal,tampon,n) écriture de n octets au plus
Extension de la notion de inode pos = lseek(canal, depl, orig) positionnement du curseur
Pointe un descripteur local (inode) ou distant (rnode) stat(nom, attributs) Lecture des attributs du fichier
Notion de file handle ou UFID unlink(nom) suppression du nom dans le rép.

Un nom global, engendré par le serveur et donné au client link(nom orig,synonyme) Nouvelle référence
Identification du FS no inode no de génération

SGF réparti : Niveau répertoire SGF réparti : Niveau fichier
Fonction Fonction
Noms symboliques ↔ noms internes (Unique File IDentifiers Passage d’un nom interne global (UFID à un descripteur)
UFID) Accès au fichier (attributs)
Protection : contrôle d’accès
API RPC Service Fichier
Génération de noms internes (UFID) : byte[] Read(UFID uid, int pos ,int n) lire n octets au + en pos
Engendrés par le serveur pour les clients Write(UFID uid,int pos ,byte[] z,int n) écrire n octets en pos
Unicité, non réutilisation, protection UFID Create() créer un fichier
Delete(UFID uid) supprimer l’UID du fichier
API RPC Service Répertoire GetAttributes(UFID uid, Attributs a) lire les attributs du fichier
Attributs SetAttributes(UFID uid) mettre à jour les attributs
UFID Lookup(UFID rép, String nom) résolution du nom
AddName(UFID rép, String nom, UFID uid) insérer le nom
UnName(UFID rép, String nom) supprimer le nom Opérations idempotentes (sauf create) : RPC at-least-once
String[] GetNames(UFID rép, String motif) recherche par motif Serveur sans état : redémarrage sans reconstruction de l’état
précédent

Gestion de caches clients et serveur Sémantique de session
Stratégie orientée session

Objectif irréaliste Un serveur unique maintient la version courante
Garantir la sémantique centralisée : Lors de l’ouverture à distance par un client (début de session),
la version lue est la dernière version écrite une copie locale au client est créée
Approximation. . . Les lectures/écritures se font sur la copie locale
Sur ouverture, le client mémorise : Seul le client rédacteur perçoit ses écritures de façon
immédiate (sémantique centralisée)
(date de dernière modification, date présente)
Lors de la fermeture (fin de session), la nouvelle version du
Interrogation du serveur si lecture après plus de p secondes
fichier est recopiée sur le serveur :
(p = 3 sec. pour fichier ordinaire, p = 10 sec. si répertoire)
⇒ La session (d’écritures du client) est rendue visible aux
autres clients

L’approche session (suite) Évolutions

Limitations
Introduction de la mobilité : partitionnement réseau, mode
Problème
déconnecté, pannes, etc
Plusieurs sessions de rédacteurs en parallèle. . . Réplication (résolution des conflits d’écriture ?)
Unité de travail = document = ensemble de fichiers
L’ordre des versions est l’ordre de traitement des fermetures
⇒ Constant Data Availability
La version gagnante est indéfinie
Exemples d’évolutions
Autres solutions Coda (CMU) : réplication optimiste en mode déconnecté,
Invalidation les copies clientes par le serveur lors de chaque résolution de conflit manuelle
création de version Peer-to-peer (voir Locus, extension de NFS) : Ficus (UCLA)
Le contrôle du parallélisme : garantir un seul rédacteur Travail collaboratif : Bayou (Xerox PARC)
Systèmes décentralisés de gestion de versions (git)
Une autre idée : Fichiers à version unique (immuable) Sites d’hébergement / partage de fichiers (Dropbox, Google
Drive. . . )
Principe et objectifs Principe et objectifs
Plan Principe général
1 Introduction
Exemples
Principe Principe : fournir des objets partagés par couplage dans les
espaces d’adressage de structures d’exécution (couplage
2 Système de fichiers réparti virtuel) réparties
Les principes et objectifs Partage par copie locale (efficacité)
NFS – Network File System Programmation simple (accès local)
Le système charge éventuellement les données à la demande
3 Mémoire virtuelle répartie Le système assure la cohérence des données partagées
Mise en œuvre

Cohérence locale entre plusieurs objets Cohérence répartie
Init : x = 0 ∧ y = 0 Init : x = 0 ∧ y = 0
Processus P1 Processus P3 et P4
Processus P2 Processus P1 Processus P2
(1) x ← x + 1 if (x > y) print("1 0");
if (x >= y) printf("OK"); x ← x + 1 y ← y + 1
(2) y ← y + 1 if (y > x) print("0 1");
Intuitivement, P2 affiche OK. En pratique, pas nécessairement. Les processus 3 et 4 peuvent-ils afficher des résultats différents ?
Réplication et répartition des données Cohérence
Deux sujets : Définition

Une même donnée, répliquée sur plusieurs sites ⇒ mêmes Cohérence : relation que gardent entre elles les différentes copies
valeurs ? des données
Plusieurs données, sur des sites différents ⇒ l’ensemble est-il
cohérent ? Cohérence stricte, linéarisabilité, cohérence séquentielle
Mais en fait, c’est le même problème ! Cohérences faibles (weak consistency)
cohérence à la sortie (release consistency)
w(x)0 w(x)1 r(y)0 cohérence à l’entrée (entry consistency)
P1 P1
P2
w(x)1 r(x)0
P2
w(y)1 r(x)0 Cohérences non séquentielles
cohérence causale
wi (x)b = écriture, sur le site i, de la variable x avec la valeur b cohérence à terme (eventual consistency)

Réplication optimiste / pessimiste Problème 1 : placement des copies
Réplication optimiste
Autoriser l’accès à une copie sans synchronisation a priori avec
Copies permanentes
les autres copies
Ensemble de copies définies a priori. Configuration statique
Modifications propagées en arrière plan
Conflits supposés peu nombreux, et résolus quand ils sont ⇒ Architecture statique de tolérance aux fautes
détectés
Copies à la demande
Réplication pessimiste Création dynamique de copies selon les besoins
Garantit l’absence de conflits ⇒ Adaptation à la charge
Mécanisme bloquant de prévention
Where a pessimistic algorithm waits, an optimistic one speculates.
Problème 2 : propagation des mises à jour Problème 3 : protocoles de cohérence

Write-update Copie primaire fixe
Lecture : copie locale (sans communication) Serveur fixe. Toute demande de modification passe par ce serveur
Écriture : locale et nouvelle valeur envoyée en multicast (⇒ accès distant).
Cohérence : propriétés sur l’ordre des messages
Copie primaire locale
Multicast peut être cher (à chaque écriture)
Le contrôle est donné au site qui fait une mise à jour ⇒ accès local.
Write-invalidate Intéressant avec les cohérences liées à la synchronisation.
Invalidation diffusée en cas d’écriture
Duplication active
Lecture ⇒ chargement si nécessaire
Accord de l’ensemble des serveurs :
Cache ⇒ plusieurs lectures/écritures locales sans
Diffusion fiable totalement ordonnée (atomique)
communication
Votes et quorums
Nouvelles valeurs transmises que si nécessaire mais lecture pas
nécessairement instantanée Algorithmes épidémiques
Duplication active – Diffusion Duplication active – Votes et quorums

Principe
Pour effectuer une lecture, avoir l’accord de nl copies
Principe Pour effectuer une écriture, avoir l’accord de ne copies
Écriture : diffusion atomique totalement ordonnée à toutes les Condition : nl + ne > N (nb de copies)
copies Garantit la lecture de la plus récente écriture
⇒ toutes les copies mettent à jour dans le même ordre
Lecture : utilisation d’une copie quelconque : Votes pondérés
immédiatement (valeur passée possible) Donner des poids différents aux copies, selon leur importance (p.e.
causalement (cohérence causale) accessibilité)
totalement ordonnée avec les écritures (cohérence séquentielle) N nombre total de votes (≥ nb de copies)
nl = quorum de lecture
ne = quorum d’écriture
Conditions : nl + ne > N et 2 ∗ ne > N
Introduction
Système de fichiers réparti
Mise en œuvre
Mémoire virtuelle répartie
Conclusion
Intérêt de la réplication
Favorise les accès locaux : performance
Tolérance aux pannes (copies multiples)
Répartition de charge
Mode déconnecté envisageable en cohérence à terme
Limites
Diverses formes de cohérence, aucune simple ET performante
Cohérences faibles ⇒ comportements surprenants
Diverses implantations, toutes complexes
Difficiles de faire cohabiter plusieurs formes de cohérence
selon la nature des données
VI – Mémoire virtuelle 35 / 35
Communication à distance
interconnexion d’applications
Abstraire les protocoles de communication
⇒ Intergiciel : service implantant un modèle d’interaction entre
Conclusion processus / logiciel
Modèle / mécanisme
1 Intergiciel de base : communication par socket
2 Intergiciel client-serveur : appel de procédure et appel de
méthode à distance
3 Intergiciel asynchrone : communication par messages
Intergiciels 1/2 Conclusion 2/2

Cours en Entier

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi

Cours en Entier

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

Cours en Entier

Transféré par

Droits d'auteur :

Formats disponibles

La communication à distance

Intergiciels et applications communicantes

Informatique et Réseaux 2e année

La communication à distance La communication à distance

Plan La communication à distance

Communication au niveau réseau

La communication à distance La communication à distance : objectifs

Faire communiquer des processus par échange d’information

La communication à distance La communication à distance

Plan du cours Distinction service / serveur

Service/serveur – exemple Plan

La communication à distance La communication à distance

Les protocoles de communication Les protocoles de communication (suite)

Grande variété de mise en œuvre

Plan Les intergiciels et leur rôle

Les sources d’hétérogénéïté

Deux processus communicants peuvent

Deux approches de solution

Intergiciels 1 / 48 II – Interface socket 2 / 48

Présentation générale Présentation générale

L’API socket dans la pile IP Objectifs de l’API socket

HTTP NFS Application

II – Interface socket 3 / 48 II – Interface socket 4 / 48

La notion de flot centralisé → réparti Désignation globale via la notion de port

Présentation générale Présentation générale

Éléments de base Schéma général

Liaison → attribution d’une adresse à un socket adr 4

Association → domaine + couple d’adresses (client/serveur ou

II – Interface socket 7 / 48 II – Interface socket 8 / 48

Numéro de ports standards (notorious) Services offerts

ftp 21/tcp Orienté connexion (TCP)

II – Interface socket 9 / 48 II – Interface socket 10 / 48

Présentation générale Présentation générale

Plan Structure générale

II – Interface socket 11 / 48 II – Interface socket 12 / 48

Client/serveur non connecté Client/serveur connecté

un socket d’écoute pour accepter les connexions,

Présentation générale Présentation générale

Plan Primitives principales

II – Interface socket 15 / 48 II – Interface socket 16 / 48

Exemple – mode connecté Exemple – mode connecté

II – Interface socket 17 / 48 II – Interface socket 18 / 48

Présentation générale Présentation générale

Exemple – mode connecté Exemple – mode connecté

struct sockaddr_in adrserv; struct sockaddr_in adrserv;

Exemple – mode non connecté Exemple – mode non connecté

socket() struct sockaddr_in adrserv;

réponse sendto() sendto (scli, requete, strlen(requete), 0,

Présentation générale Présentation générale

Exemple – mode non connecté Création d’un socket

struct sockaddr_in adrserv, adrcli; char requete[10];

Adresse Représentation des entiers

struct sockaddr_in { La pile IP est « big endian »

II – Interface socket 25 / 48 II – Interface socket 26 / 48

Présentation générale Présentation générale

Service de nommage (DNS) Liaison socket/adresse

Connexion (côté client) Déclaration du serveur

Présentation générale Présentation générale