Client-Serveur IST

UNIVERSITE DE BANGUI REPUBLIQUE CENTRAFRICAINE
Unité - Dignité – Travail
*************
INSTITUT SUPERIEUR DE TECHNOLOGIE
********
DEPARTEMENT D’INFORMATIQUE
Cours d’Architecture Client/Serveur

& Sockets
Licence & Maitrise
Conçu par : M. Edgard NDASSIMBA
Support de cours sur l’architecture client – serveur et les sockets – Enseignant : Edgard NDASSIMBA
1
OBJECTIFS
Donner à l’étudiant(e) ou l’Ingénieur des connaissances sur :
• Un rappel sur le modèle TCP/IP

• L’architecture client/serveur
• La programmation réseau avec les sockets
STRATEGIE PEDAGOGIQUE
Les connaissances seront transmises sous forme d’un cours magistral et des travaux
Dirigés. L’étudiant(e) ou l’Ingénieur aura à compléter les travaux et les cours par l’étude
personnelle et des efforts personnels.
Le volume horaire recommandé pour ce cours est de 45 heures maximum
2
SOMMAIRE
PARTIE I : ARCHITECTURE CLIENT-
CLIENT-SERVEUR
CHAPITRE 1 : RAPPELSNSUR LE MODELE TCP/IP
I- ARCHITECTURE DES PROTOCOLES TCP/IP
1.1-Couche Application
1.2-Couche Transport
1.3-Couche Internet
1.4-Couche Accès au Réseau
CHAPITRE 2 : LE MODELE CLIENT - SERVEUR

I- PRESENTATION
1.1-Présentation de l'architecture à 2 niveaux
1.2-Présentation de l'architecture à 3 niveaux
1.3-Comparaison des deux types d'architecture
1.4-L'architecture multiniveaux
II- LES APPLICATIONS RESEAU
2.1- Terminologie des applications réseaux
2.2- Protocoles de la couche application
2.3- Interface de programmation réseau
III- LE MIDDLEWARE
III- CONCEPTION D’UNE APPLICATION CLIENT-SERVEUR
IV- LES MODE DE COMMUNICATION
4.1- Mode connecté
4.2- Mode non connecté
V- LES TYPES DE SERVEURS
PARTIE II : PROGRAMMATION DES SOCKETS

CHAPITRE 3 : LES SOCKETS
I- INTRODUTION
II - ADRESSES DE SOCKETS
1- les familles d’adresse
2- les structures d’adresse
III - LES APPELS SYSTEME
4.1- L’appel système socket
4.2 – L’appel système bind
4.3 - L’appel système connect
4.4 – L’appel système listen
4.5 – L’appel système accept
IV - ECHANGES D’INFORMATIONS SUR UN SOCKET
4.1- Emission d’information
4.2 – Réception d’information
V- ENCHAINEMENT DES APPELS SYSTEMES
5.1- Mode connect.
3
5.2- Mode non connect.
VI - DES PROCEDURES BIEN UTILE
6.1- Procédures réseau de conversion de l’ordre des sockets
6.2- Les opérations sur les octets
6.3 –Demander et définir les noms de machine
6.4- Obtenir des informations relatives aux machines
6.5- Obtenir des informations relatives aux réseaux
6.6 – Obtenir des informations relatives aux protocoles
6.7- Obtenir des informations relatives aux services réseaux
CHAPITRE 4 : LES APPELS DE PROCEDURES A DISTANCE

I- PRESENTATION DES RPC
1.1- Définition
1.2- Les RPCS en général
II- LES DIX (10) ETAPES DE L’EXECUTION D’UN RPC
III- PROBLEMES DE TRANSPARENCE DES RPC
IV- LES ETAPES CLASSIQUES DU DEVELOPPEMENT CLASSIQUES DU
DEVELOPPEMENT D’APPLICATION
V- ETABLISSEMENT DES LIENS
VI- DEUX APPROCHES DE CONCEPTION
VII- PRINCIPE GENERAL
VIII- LE MODELE RPC
CHAPITRE 5 : LA PROGRAMMATION RESEAU TCP ET UDP EN C

I- PREAMBULE
II- UDP
2.1 Client/serveur UDP en C
III- TCP
3.1 Serveur TCP multiclient en C
IV- ANNEXE
4.1- Programmation en C avec les sockets
4
PARTIE I : ARCHITECTURE CLIENT-
CLIENT-SERVEUR
5
CHAPITRE 1 : RAPPELSNSUR LE MODELE TCP/IP
I- ARCHITECTURE DES PROTOCOLES TCP/IP
TCP/IP ou Transmission Control Protocol / Internet Protocol définit une suite de protocoles
qui permettent à des ordinateurs de communiquer.
Couches TCP/IP Protocoles
Application FTP, Telnet, HTTP, POP3, SMTP, NFS
Transport TCP, UDP
Internet IP
Accès réseau Ethernet, Frame Relay, FDDI, RNIS
1.1- La couche application
Les protocoles de la couche application fournissent des services aux logiciels applicatifs
s’exécutant sur un ordinateur.
L’application TCP/IP la plus connue est le navigateur WEB.
Lorsqu’une couche spécifique sur un ordinateur souhaite communiquer avec son homologue
sur un autre ordinateur, les deux machines emploient des en – têtes pour contenir les
informations qu’elles veulent échanger. Ces en – têtes sont des éléments essentiels de la
transmission qui a lieu entre les deux ordinateurs. On qualifie ce processus d’interaction
entre couches homologues
6
1.2- La couche Transport
TCP/IP devait disposer d’un mécanisme pour garantir la livraison des données à travers le
réseau. TCP fourni un mécanisme de récupération des erreurs au moyen d’acquittement.
L’interaction entre couches adjacentes définit la façon dont les couches adjacentes d’un
modèle de réseau sur un même ordinateur collaborent.
Entre couches homologues sur des ordinateurs différents, les deux ordinateurs
communiquent l’un avec l’autre au niveau de la même couche par le biais d’un protocole. Le
protocole défini par chaque couche utilise un en – tête qui permet aux deux ordinateurs
d’échanger les informations dont ils ont besoins.
Entre couches adjacentes sur un même ordinateur, chaque couche offre un service à la
couche immédiatement supérieure. Le logiciel ou matériel qui implémente la couche
supérieure attend de la couche inférieure qu’elle assure la fonction requise.
1.3- La couche Internet
Elle définit des adresses logiques et le processus de routage autorisant des équipements
appelé routeurs à choisir ou à envoyer les paquets de données pour qu’ils parviennent a
destination, puis les détails de la façon de créer une infrastructure pour pouvoir transférer
des données entre tous les ordinateurs du réseau.
7
1.4- La couche Accès réseau
Elle définit les protocoles et le matériel requis pour acheminer des données sur un réseau
physique. Cette couche es constituée de deux couches : Liaison de données et Physique. La
couche Accès réseau du modèle TCP/IP inclut les protocoles, les normes de câblage, ainsi
que les en – têtes et les en – queues qui définissent la façon dont les données sont
transmises sur une grande variété de types de réseaux physiques.
L’encapsulation des données désigne le processus qui consiste à placer des en – têtes et
des en – queues autour de données. Par exemple le serveur WEB encapsulait la page
d’accueil home.htm au moyen des en – têtes HTML ; la couche TCP encapsulait les en –
têtes http et les données au moyen d’un en – tête TCP ; le protocole IP encapsulait les en –
têtes TCP et les données au moyen d’un en – tête IP. Enfin, la couche Accès réseau
encapsulait les paquets IP au moyen d’en – têtes et d’en – queues PPP et Ethernet.
En résumé, le processus d’encapsulation des données avec TCP/IP peut être décomposé en
5 étapes suivantes :
1- Création et encapsulation des données avec des en – têtes de niveau Application

2- Encapsulation des données fournies par la couche Application dans un en – tête de
niveau Transport
3- Encapsulation des données fournies par la couche Transport dans un en – tête de
niveau Internet (IP)
8
4- Encapsulation des données fournies par la couche Internet entre un en – tête et un
en – queue de niveau Accès réseau
5- Transmission de Bit
Données Application
TCP Données Transport
IP TCP Données Internet
ETL IP TCP Données EQL Accès réseau
Transmission de Bits
Les 5 étapes d’encapsulation
TCP Données Segment (Transport)
IP Données Paquet (Internet)
ETL Données EQL Trame (Accès réseau)
Trames, Paquets et Segments
9
CHAPITRE 2 : LE MODELE CLIENT - SERVEUR
I- PRESENTATION
Une application Client/Serveur, c'est

une partie cliente qui exécute des requêtes vers un serveur
une partie serveur qui traite les requêtes clientes et y répond
un protocole applicatif qui définit les échanges entre un client et un serveur
un accès via une API (interface de programmation) à la couche de transport des
messages
Bien souvent les parties cliente et serveur ne sont pas écrites par les mêmes programmeurs
(Navigateur Netscape/Serveur apache) --> rôle important des RFCs qui spécifient le
protocole
Idée : l'application est répartie sur différents sites pour optimiser le traitement, le
stockage...
Le client
o effectue une demande de service auprès du serveur (requête)
o initie le contact (parle en premier), ouvre la session
Le serveur
o est la partie de l'application qui offre un service
o est à l'écoute des requêtes clientes
o répond au service demandé par le client (réponse)
Le client et le serveur ne sont pas identiques, ils forment un système coopératif
o les parties client et serveur de l'application peuvent
o s'exécuter sur des systèmes différents
o une même machine peut implanter les côtés client ET serveur de l'application
o un serveur peut répondre à plusieurs clients
o simultanément
1.1- Présentation de l'architecture à 2 niveaux
L'architecture à deux niveaux (aussi appelée architecture 2-tier, tier signifiant rangée en
anglais) caractérise les systèmes clients/serveurs pour lesquels le client demande une
ressource et le serveur la lui fournit directement, en utilisant ses propres ressources. Cela
signifie que le serveur ne fait pas appel à une autre application afin de fournir une partie du
service.
10
1.2- Présentation de l'architecture à 3 niveaux
Dans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau intermédiaire,

c'est-à-dire que l'on a généralement une architecture partagée entre :
1. Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface

utilisateur (généralement un navigateur web) chargée de la présentation ;
2. Le serveur d'application (appelé également middleware), chargé de fournir la
ressource mais faisant appel à un autre serveur
3. Le serveur de données, fournissant au serveur d'application les données dont il a
besoin.
Etant donné l'emploi massif du terme d'architecture à 3 niveaux, celui-ci peut parfois
désigner aussi les architectures suivantes :
• Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise ;

• Partage d'application entre client, serveur d'application, et serveur de base de
données d'entreprise.
11
1.3- Comparaison des deux types d'architecture
L'architecture à deux niveaux est donc une architecture client/serveur dans laquelle le
serveur est polyvalent, c'est-à-dire qu'il est capable de fournir directement l'ensemble des
ressources demandées par le client.
Dans l'architecture à trois niveaux par contre, les applications au niveau serveur sont
délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche (serveur
web/serveur de base de données par exemple). L'architecture à trois niveaux permet :
• Une plus grande flexibilité/souplesse ;

• Une sécurité accrue car la sécurité peut être définie indépendamment pour chaque
service, et à chaque niveau ;
• De meilleures performances, étant donné le partage des tâches entre les différents
serveurs.
1.4- L'architecture multiniveaux
Dans l'architecture à 3 niveaux, chaque serveur (niveaux 2 et 3) effectue une tâche (un
service) spécialisée. Un serveur peut donc utiliser les services d'un ou plusieurs autres
serveurs afin de fournir son propre service. Par conséquent, l'architecture à trois niveaux est
potentiellement une architecture à N niveaux...
12
II- LES APPLICATIONS RESEAU
Applications = la raison d'être des réseaux infos

Profusion d'applications depuis 30 ans grâce à l'expansion d'Internet
o années 1980/1990 : les applications "textuelles"
messagerie électronique, accès à des terminaux distants, transfert de fichiers,
groupe de discussion (forum, newsgroup), dialogue interactif en ligne (chat),
la navigation Web
o plus récemment :
les applications multimédias : vidéo à la demande (streaming),
visioconférences, radio et téléphonie sur Internet
la messagerie instantanée (ICQ, MSN Messenger)
les applications Peer-to-Peer (MP3,..)
L'application est généralement répartie (ou distribuée) sur plusieurs systèmes

Exemples :
o L'application Web est constituée de deux logiciels communiquant : le
navigateur client qui effectue une requête pour disposer d'un document
présent sur le serveur Web
o L'application telnet : un terminal virtuel sur le client, un serveur telnet distant
qui exécute les commandes
o La visioconférence : autant de clients que de participants
Nécessité de disposer d'un protocole de communication applicatif
2.1- Terminologie des applications réseaux
Processus :
o une entité communicante
o un programme qui s'exécute sur un hôte d'extrémité
Communications inter-processus locales :
o communications entre des processus qui s'exécutent sur un même hôte
o communications régies par le système d'exploitation (tubes UNIX, mémoire
partagée, …)
Communications inter-processus distantes :
o les processus s'échangent des messages à travers le réseau selon un
protocole de la couche applications
o nécessite une infrastructure de transport sous-jacente
2.2- Protocoles de la couche application
Le protocole applicatif définit :

o le format des messages échangés entre les processus émetteur et récepteur
o les types de messages : requête, réponse, …
o l'ordre d'envoi des messages
Exemples de protocoles applicatifs :
o HTTP pour le Web, POP/IMAP/SMTP pour le courrier électronique, SNMP
pour l'administration de réseau, …
Ne pas confondre le protocole et l'application !
o Application Web : un format de documents (HTML), un navigateur Web, un
serveur Web à qui on demande un document, un protocole (HTTP)
2.3- Interface de programmation réseau
13
Il faut une interface entre l'application réseau et la couche transport
o le transport n'est qu'un tuyau (TCP ou UDP dans Internet)
o l'API (Application Programming Interface) n'est que le moyen d'y accéder
(interface de programmation)
Les principales APIs de l'Internet

o les sockets
apparus dans UNIX BSD 4.2
devenus le standard de fait
o les RPC : Remote Procedure Call - appel de procédures distantes
III- LE MIDDLEWARE
On appelle middleware (ou logiciel médiateur), l’élément du milieu, l’ensemble des couches
réseau et services logiciels qui permettent le dialogue entre les différents composants d’une
application répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l’API
du middleware.
Le Gartner Group définit le middleware comme une interface de communication universelle

entre processus. Il représente véritablement la clef de voute de toute application client-
serveur.
L’objectif principal du middleware est d’unifier, pour les applications, l’accès et la

manipulation de l’ensemble des services disponibles sur le réseau, afin de rendre l’utilisation
de ces derniers presque transparente.
Les exemples des middleware sont :
SQL*Net : interface proprietaires permettant de faire dialoguer une application cliente

avec une base de données Oracle. Ce dialogue peut aussi bien être le passage de
requête SQL que l’appel de procedure stockées.
ODBC : Objet Data Base Connexion : interface standardisée isolant le client du

serveur de données. C’est l’implémentation par Microsoft d’un standard défini par le
SQL Access Group. Elle se compose d’un gestionnaire de driver standardisé, d’une
API s’interfaçant avec l’application cliente (sous MS Windows) et d’un driver
correspondant au SGBD utilisé.
14
DCE (Distribution Computing Environment) : permet l’appel à des procédures
distantes depuis une application. Correspond à RPC (Remote Procedure Call) qui
permet d’exécuter des procédures distantes.
III- CONCEPTION D’UNE APPLICATION CLIENT-SERVEUR
Comment découper une application informatique en clients et serveurs ?

Une application informatique est représentée selon un modèle en trois couches :
o la couche présentation (interface Homme/Machine) :
gestion de l’affichage…
o la couche traitements (ou logique) qui assure la fonctionnalité intrinsèque de
l’application (algorithme)
o la couche données qui assure la gestion des données de l'application
(stockage et accès)
Exemples de découpage Client/Serveur :

o le module de gestion des données peut être hébergé par un serveur
distant (SGBD, serveur web)
o le module de gestion de l’affichage peut également être géré par un
serveur distant (un terminal X par exemple)
Autres exemples
15
Modèle de Gartner pour les systèmes à 2 niveaux (2-tiers) :
Modèle de Gartner pour les systèmes à 3 niveaux (3-tiers) :
IV- LES MODE DE COMMUNICATION
4.1- Mode connecté
16
4.2- Mode non connecté
V- LES TYPES DE SERVEURS
Serveur itératif :
traite séquentiellement les requêtes
adapté aux requêtes qui peuvent s'exécuter rapidement
souvent utilisé en mode non connecté (recherche de la performance)
Serveur concurrent :
le serveur accepte les requêtes puis les "délègue" à un processus fils (traitement de
plusieurs clients)
adapté aux requêtes qui demandent un certain traitement (le coût du traitement est
suffisamment important pour que la création du processus fils ne soit pas
pénalisante)
souvent utilisé en mode connecté
17
PARTIE II : PROGRAMMATION DES SOCKETS
18
CHAPITRE 3 : LES SOCKETS
I- INTRODUTION
Le socket est utilisé pour permettre aux processus de communiquer entre eux de la même
manière que le téléphone nous permet de communiquer entre nous.
L’analogie entre le concept de socket et le téléphone est assez proche, et sera utilisé pour
éclaircir la notion de socket.
Pour recevoir des coups de téléphone :

1. vous devez d’abord installer le téléphone chez vous. De la même façon vous devez
commencer par créer un socket avant d’attendre des demandes de communications.
La commande socket() est alors utilisé pour créer un nouveau socket. Seulement il
faut créer un socket avec les bonnes options. Vous devez spécifier le type
d’adressage du socket. Les deux types d’adressage les plus répandus sont
o AF_UNIX (famille d’adresse UNIX) et AF_INET (famille d’adresse
Internet).
o AF_INET utilise les adresses Internet qui sont du format suivant X.X.X.X
(ex: 178.33.174.34). En plus des adresses Internet, on a besoin aussi d’un
numéro de port sur la machine pour pouvoir utiliser plusieurs socket
simultanément.
Une autre option a spécifier lors de la création d’un socket est son type. Les deux
types les plus répandus sont :
o SOCK_STREAM, spécifique en mode connecté et
o SOCK_DGRAM sont spécifiques au mode déconnecté.
2. De la même façon qu’on vous attribue un numéro de téléphone pour recevoir vos
appels, on doit spécifier au socket une adresse, laquelle il doit recevoir les messages
qui lui sont destinés. Ceci est réalisé par la fonction bind() qui associe un numéro au
socket.
3. Les sockets de type SOCK_STREAM ont la possibilité. de mettre les requêtes de

communication dans une file d’attente , de la même façon que vous pouvez recevoir
un appel pendant une conversation téléphonique. C’est la fonction listen() qui permet
de définir la capacité. de la file d’attente (jusqu’a. 5) . Il n’est pas indispensable
d’utiliser cette fonction mais c’est plutôt une bonne habitude que de ne pas l’oublier.
4. L’étape suivante est d’attendre les demandes de communication. C’est le rôle de la

fonction accept(). Cette fonction retourne un nouveau socket qui est connecté à
l’appelant. Le socket initial peut alors se remettre à attendre les demandes de
communication. C’est pour cette raison qu’on exécute un fork() à chaque demande
de connexion.
On sait maintenant comment créer un socket qui reçoit des demandes de communication,
mais comment l’appeler ?
1. Pour le téléphone vous devez d’abord avoir le numéro avant de pouvoir appeler. Le
rôle de la fonction connect() est de connecter un socket a un autre socket qui est en
attente de demande de communication.
2. Maintenant qu’une connexion est établie entre deux sockets, la conversation peut
commencer. C’est le rôle des fonction read() et write().
3. A la fin de la communication on doit raccrocher le téléphone ou fermer le socket qui a
servi la communication. C’est le rôle de la fonction close().
19
Sous UNIX l’implémentation est de la forme suivante:
III - ADRESSES DE SOCKETS

1- les familles d’adresse
Il existe plusieurs familles d’adresses, chacune correspondant . un protocole
particulier. Les familles les plus répandues sont:
AF_UNIX Protocoles internes de UNIX
AF_INET Protocoles Internet
AF_NS Protocols de Xerox NS
AF_IMPLINK Famille spéciale pour des applications particulières auxquelles nous ne
nous intéresserons pas.
2- les structures d’adresse

Plusieurs appels systèmes réseaux sous Unix nécessitent un pointeur sur une
20
structure d’adresse de socket. La définition de cette structure se trouve dans
<sys/socket.h> ;
struct sockaddr
{
u_short sa_family ;
char sa_data[14] ;
};
sa_family : adresse de famille : prend la valeur AF_xxx

sa_data : peut contenir jusqu’à 14 octets de protocole spécifique d’adresse interprété selon
le type d’adresse.
Pour la famille Internet les structures suivantes sont définis dans le fichier
<netinet/in.h>.
struct in_addr
{
u_long s_addr ;
};
s_addr : 32 bits constituants l’identificateur du réseau et de la machine hôte ordonnes selon

l’ordre réseau.
struct sockaddr_in
{
short sin_family ;
u_short sin_port ;
struct in_addr sin_addr ;
char sin_zero[8] ;
};
sin_family : AF_INET ;
sin_port : 16 bits de num.ro de port ( ordonnancement réseau) ;
sin_addr : 32 bits constituants l’identificateur du réseau et de la machine hôte
ordonnes selon l’ordre réseau.
sin_zero[8] : inutilisés ;
Le fichier <sys/types.h> fourni des définitions de C et de types de donn.es qui sont utilisés
dans le système.
IV - LES APPELS SYSTEME
4.1- L’appel système socket

#include <sys/types.h>
#include <sys/socket.h>
int socket(int family, int type, int protocole) ;
La variable family peut prendre 4 valeurs dont les préfixes commencent par AF
21
comme Famille d’adresse :
AF_UNIX Protocoles internes de UNIX
AF_INET Protocoles Internet
AF_NS Protocols de Xerox NS
AF_IMPLINK Famille spéciale pour des applications particulières auxquelles nous ne
nous intéresserons pas.
La variable type peut prendre 5 valeurs :
SOCK_STREAM utilisé en mode connecté au-dessus de TCP.

SOCK_DGRAM utilisé en mode déconnecté avec des datagrammes au-dessus de
UDP.
SOCK_RAW utilisé au-dessus de IP
SOCK_SEQPACKET Sequenced Packet socket. Ce type n’est pas utilisable avec
TCP/IP ni avec UDP/IP.
Le mode raw accessible par l’option SOCK_RAW lors de la création d’un socket, permet
l’accès aux interfaces internes du réseau. Ce mode n’est accessible qu’au super-utilisateur
et ne sera pas détaillé..
L’argument protocole dans l’appel système socket est généralement mis à 0. Dans certaines
applications spécifiques, il faut cependant spécifier la valeur du protocole. Les combinaisons
valides pour la famille AF_INET sont les suivantes :
Les constantes IPPROTO_xxx sont définies dans le fichier <netinet/in.h>.

L’appel système socket retourne un entier dont la fonction est similaire à celle d’un
descripteur de fichier. Nous appellerons cette entier descripteur de sockets (sockfd).
4.2 – L’appel système bind

int bind (int sockfd, struct sockaddr *myaddr , int addrlen) ;
Le premier argument est le descripteur de socket retourné. par l’appel socket.

Le second argument est un pointeur sur une adresse de protocole spécifique et le troisième
est la taille de cette structure d’adresse. Il y a 3 utilisations possibles de bind :
1. Le serveur enregistre sa propre adresse auprès du système. Il indique au système

que tout message reçu pour cette adresse doit lui être fourni. Que la liaison soit
avec ou sans connexion l’appel de bind est nécessaire avant l’acceptation dune
requête d’un client.
2. Un client peut enregistrer une adresse spécifique pour lui-même.
3. Un client sans connexion doit s’assurer que le système lui a affecté une unique
adresse que ses correspondants utiliseront afin de lui envoyer des messages.
L’appel de bind rempli l’adresse locale et celle du process associé au socket.
22
4.3 - L’appel système connect
Un socket est initialement créé dans l’état non connecté, ce qui signifie qu’il n’est associé a
aucune destination éloignée. L’appel système connect associe de façon permanente un
socket a une destination éloignée et le place dans l’état connect..
Un programme d’application doit invoquer connect pour établir une connexion avant de
pouvoir transférer les donn.es via un socket de transfert fiable en mode connect.
Les sockets utilisées avec les services de transfert en mode datagramme n’ont pas besoin
d’établir une connexion avant d’être utilisés, mais procéder de la sorte interdit de transférer
des données sans mentionner à chaque fois, l’adresse de destination.
int connect (int sockfd, struct sockaddr *servaddr , int addrlen) ;
sockfd est le descripteur de socket retourné par l’appel socket.

servaddr est un pointeur sur une structure d’adresse de socket qui indique l’adresse
de destination avec laquelle le socket doit se connecter.
addrlen taille de la structure d’adresse.
4.4 – L’appel système listen

int listen ( int sockfd, int backlog) ;
Cet appel est généralement utilisé après les appels socket et bind et juste avant
les appels l’appel accept.
L’argument backlog spécifie le nombre de connections a

établir dans une file d’attente par le système lorsque le serveur exécute l’appel accept.
Cet argument est généralement mis a 5 qui est la valeur maximale utilisée.
4.5 – L’appel système accept

int accept (int sockfd, struct sockaddr *peer , int *addrlen) ;
L’argument sockfd désigne le descripteur de socket sur lequel seront attendues les
connexions.
Peer est un pointeur vers une structure d’adresse de socket.
Lorsqu’une requête arrive, le système enregistre l’adresse du client dans la stucture *peer et
la longueur de l’adresse dans *addrlen. Il crée alors un nouveau socket connect. avec la
destination spécifie par le client, et renvoie à l’appelant un descripteur de socket. Les
changes futurs avec ce client se feront donc par l’intermédiaire de ce socket.
Le socket initiale sockfd n’a donc pas de destination et reste ouvert pour accepter de futures
demandes.
Tant qu’il n’y a pas de connexions le serveur se bloque sur cette appel.
23
Lorsqu’une demande de connexion arrive, l’appel système accept se termine. Le serveur
peut gérer les demandes itérativement ou simultanément :
Dans l’approche itérative, le serveur traite lui-même la requête, ferme le nouveau

socket puis invoque de nouveau accept pour obtenir la demande suivante.
Dans l’approche parallèle, lorsque l’appel système accept se termine le serveur crée
un serveur fils chargé de traiter la demande (appel de fork et exec). Lorsque le fils à
terminer il ferme le socket et meurt. Le serveur maitre ferme quand à lui la copie du
nouveau socket après avoir exécuté le fork. Il appel ensuite de nouveau accept pour
obtenir la demande suivante.
Exemple de serveur itératif
int sockfd, newsockfd ;
if ( ( sockfd = socket (.....)) < 0 )

err_sys(“erreur de socket”) ;
if ( bind ( sockfd, ....) < 0 )
err_sys (‘’erreur de bind ‘’)
if ( listen ( sockfd , 5) < 0 ) ;
err_sys (‘’erreur de listen’’) ;
for ( ; ; )
{
newsockfd = accept ( sockfd, .....) ;
if ( newsockfd < 0)
err_sys( ‘’erreur de accept’’) ;
execute_la_demande( newsockfd ) ;
close ( newsockfd ) ;
}
Exemple de serveur à accès concurrent

int sockfd, newsockfd ;
if ( ( sockfd = socket (.....)) < 0 )
err_sys(‘’erreur de socket’’) ;
if ( bind ( sockfd, ....) < 0 )
err_sys (‘’erreur de bind’’)
if ( listen ( sockfd , 5) < 0 ) ;
err_sys (‘’erreur de listen’’) ;
for ( ; ; )
{
newsockfd = accept ( sockfd, .....) ;
if ( newsockfd < 0)
err_sys( ‘’erreur de accept’’) ;
if ( fork() == 0 )
{
close ( sockfd ) ;
execute_la_demande( newsockfd ) ;
exit (1) ;
}
24
close ( newsockfd ) ;
}
V - ECHANGES D’INFORMATIONS SUR UN SOCKET
5.1- Emission d’information

Une fois que le programme d’application dispose d’un socket, il peut l’utiliser afin de
transférer des données. Cinq appels système sont utilisables : send, sendto, sendmsg,
write et writev. Send, write et writev ne sont utilisables qu’avec des sockets en mode
connect. car ils ne permettent pas d’indiquer d’adresse de destination. Les différences entre
ces trois appels sont mineures :
write ( int sockfd, char *buff, int nbytes ) ;

writev ( int sockfd, iovec *vect_E/S, int lgr_vect_E/S ) ;
int send (int sockfd, char *buff, int nbytes, int flags ) ;
socket contient le descripteur de socket .

buff est un pointeur sur un tampon o sont stock.es les donn.es . envoyer.
nbytes est le nombre d’octets ou de caractères que l’on désire envoyer
vect_E/S est un pointeur vers un tableau de pointeurs sur des blocs qui constituent le
message à envoyer.
flags drapeau de contrôle de la transmission.
Pour le mode non connecté. on a deux appels sendto et sendmsg qui imposent
d’indiquer l’adresse de destination :
int sendto (int sockfd, char *buff, int nbytes, int flags, struct sockaddr *to, int addrlen) ;
Les quatre premiers arguments sont les mêmes que pour send, les deux derniers
sont l’adresse de destination et la taille de cette adresse.
Pour les cas où on utiliserait fréquemment l’appel sendto qui nécessite beaucoup
d’arguments et qui serait donc d’une utilisation trop lourde on définit la structure suivante:
struct struct_mesg
{
int *sockaddr ;
int sockaddr_len ;
iovec *vecteur_E/S
int vecteur_E/S_len
int *droit_dÕacces
int droit_dÕacces_len
}
Cette structure sera utilisée par l’appel sendmsg :
25
int sendmsg ( int sockfd, struct struct_mesg, int flags ) ;
5.2 – Réception d’information

On distingue 5 appels système de réception d’information qui sont symétriques au appels
d’envoi. Pour le mode connecté. on a les appelles read, readv et recv et pour le mode sans
connexion on a les appelles recvfrom et recvmsg.
int read ( int sockfd, char *buff, int nbytes ) ;

int readv ( int sockfd, iovec *vect_E/S, int lgr_vect_E/S ) ;
int recv (int sockfd, char *buff, int nbytes, int flags ) ;
sockfd est le descripteur sur lequel les données seront lues .

buff est un pointeur sur un buffer où seront stockées les donn.es lues
nbytes est le nombre maximal d’octets ou de caractères qui seront lus.
readv permet de mettre les donn.es lues dans des cases mémoire non contiguës.
Ces cases mémoires sont point.es par un tableau de pointeurs qui lui-même est point par
vect_E/S.
lgr_vect_E/S est la longueur de ce tableau.
Pour le mode sans connexion, il faut préciser les adresses des correspondants desquels on
attend des données.
int recvfrom (int sockfd, char *buff, int nbytes, int flags, struct sockaddr *from, int addrlen) ;
Pour les mêmes raisons que pour sendto et sendmsg, et pour des raison de symétrie on a
définie l’appel recvmsg qui utilise la même structure que sendmsg.
int recvmsg ( int sockfd, struct struct_mesg, int flags ) ;
DETAIL DES ARGUMENTS FLAGS

Les arguments flags sont soit zéro soit le résultat d’un or entre les trois constantes
suivantes :
MSG_OOB émission ou réception de donn.es hors bande
MSG_PEEK Cout d'œil au message entrant (recv ou recvfrom)
MSG_DONTROUTE dérivation du routage (send ou sendto)
MSG_PEEK le drapeau permet à l'appelant de regarder les données qui sont disponibles
pour la lecture, sans que le système ignore les données après le retour de la recv ou
recvfrom
MSG_OOB : les données hors bande sont des données urgentes.

Les données hors bande sont des transmissions indépendantes entre une paire de socket
connectés. Les donn.es hors bande sont délivrées indépendamment des données normales.
Pour les protocoles de communication qui ne supportent pas les donn.es hors bande, les
messages urgents sont extraits du flux de donn.es et stockés séparément. Ceci laisse le
choix à l’utilisateur entre recevoir les donn.es urgentes dans l’ordre ou pas, sans avoir à les
stocker dans un buffer.
Si un socket possède un process-group, un signal SIGURG est généré quand le protocole
prend connaissance de l’arrivé d’une donnée hors bande. Le processgroup ou le process id
qui devra très informé. de l’arrivé d’une donnée urgente peut être initialisé. par la fonction
fcntl().
26
si plusieurs sockets sont susceptibles de recevoir des donn.es hors bande, l’appel de la
fonction select() permet de sélectionner le socket devant recevoir la donnée urgente. Pour
envoyer des donn.es hors bande, l’option MSG_OOB doit très utilisé lors de l’appel de
send() ou sendto().
LE MULTIPLEXAGE
L’appel système qui permet le multiplexage des sockets est select(). select() examine les
descripteurs qui lui sont passés en paramètre et teste si certains sont prêts . lire, écrire ou
ont une condition d’exception. Les données hors bande sont les seules conditions
d’exception que peut recevoir un socket. description de l’appel système select():
int select ( int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval
*timeout )
On ne s’attardera pas sur les structures pass.es en paramètre, seuls les fonctions qui
permettront leur manipulation seront d.taill.es. Les arguments 2, 3 et 4 de select sont des
pointeurs sur des structures qui contiendront les descripteurs de sockets à tester en lecture,
écriture et en réception d’exception par le select.
Le dernier argument timeout, s’il est non nul , spécifie l’intervalle de temps maximal .
attendre avant de sortir de select. Si ce pointeur est nulle select() bloquera
indéfiniment. Pour réaliser un polling sur select() ( i.e. select ne rendra la main que lorsqu’au
moins un descripteur aura été sélectionnée) le pointeur timeout doit être non nul mais
pointant sur une STRUCTURE timeval nulle.
A la fin de select les structures passées en arguments contiennent les descripteurs

sélectionnés par la fonction select
Avant d’appeler select() , il faut initialiser ses arguments. On commencera toujours par les
initialiser à une structure nulle par la fonction FD_ZERO (fd_set &fdset).
void FD_SET ( int fd, fd_set &fdset ) ajoute le descripteur fd à fdset.
void FD_CLR ( int fd, fd_set &fdset ) retire le descripteur fd à fdset.
A la fin de select, la fonction int FD_ISSET ( int fd, fd_set &fdset ) nous permet de savoir si
le descripteur fd est sélectionnée dans fdset ou non. Cette fonction est à appeler après
select().
VI- ENCHAINEMENT DES APPELS SYSTEMES
6.1- Mode connect.

Deux approches de programmation de serveurs se présentent: l’approche itérative et
l’approche parallèle.
Rappelons que dans l’approche itérative, le serveur traite lui-même la requête, ferme le
nouveau socket puis invoque de nouveau accept pour obtenir la demande suivante.
L’enchainement dans le temps des appels système pour un serveur itératif se résume par la
figure suivante:
27
Dans l’approche parallèle, lorsque l’appel système accept se termine le serveur crée un
serveur fils chargé de traiter la demande (appel de fork et exec). Lorsque le fils à terminer il
ferme le socket et meurt. Le serveur maitre ferme quant à lui la copie du nouveau socket
après avoir exécuté le fork. Il appel ensuite de nouveau accept pour obtenir la demande
suivante.
L’enchainement des appels systèmes pour un serveur parallèle se résume par la figure
suivante:
28
6.2- Mode non connect.
Dans le cas d’un protocole sans connexion, les appels système sont différents. Le client
n’établit pas de connexion avec le serveur. Le client envoi un datagramme au serveur en
utilisant l’appel système sendto(). Symétriquement le serveur n’accepte pas de connexion
d’un client, mais attend un datagramme d’un client avec l’appel système recvfrom(). Ce
dernier revoie l’adresse réseau du client, avec le datagramme, pour que le serveur puisse
répondre à la bonne adresse. L’enchaînement dans le temps des appels systèmes pour une
communication en mode non connecté. et pour un serveur itératif se résume par la figure
suivante:
29
L’enchainement dans le temps des appels systèmes pour une communication en mode non
connecté. et pour un serveur parallèle se résume par la figure suivante:
30
VII - DES PROCEDURES BIEN UTILE
7.1- Procédures réseau de conversion de l’ordre des sockets

Les machines ont des façons différentes d’enregistrer les entiers et les protocoles TCP/IP
ont une représentation des octets normalisée et indépendante des machines.
Pour que les programmes soient portables sur toutes les machines il faut pouvoir convertir
les représentations réseaux en représentation machine à chaque de paquet et vice et versa.
Les fonction de conversion sont les suivantes :
htonl (val) :
host to network long : convertit une valeur sur 32 bits de la représentation machine vers la
représentation réseau.
htons (val) :
host to network short : convertit une valeur sur 16 bits de la représentation machine vers la
représentation réseau.
ntohl (val) :
network to host long : convertit une valeur sur 32 bits de la représentation réseau vers la
représentation machine.
ntohs (val) :
network to host short : convertit une valeur sur 16 bits de la représentation réseau vers la
représentation machine.
7.2- Les opérations sur les octets

Pour initialiser une structure où pour la mettre à. jour on dispose de deux fonctions:
Tout d’abord la fonction bzero() qui initialise à zéro tous les champs de la structure
passée en paramètre. Cette fonction doit être appelée avant l’utilisation de la
structure.
Il y a aussi la fonction bcopy() qui a pour paramètre deux structures et un entier n qui
indique le nombre d’octets à copier. Cette fonction copie les n premiers octets de la
structure 1 dans la structure 2.
7.3 –Demander et définir les noms de machine

Le système d’exploitation UNIX gère en interne un nom de machine. Pour les machines
reliées à l’Internet , le nom interne coïncide généralement avec celui du domaine qui
correspond avec l’interface réseau principale.
L’appel système ‘’rechercher’’ le nom de la machine ( gethostname ) permet aux processus
utilisateurs d’accéder au nom de la machine.
L’appel système ‘’définir’’ le nom de la machine ( sethostname ) permet à des processus
privilégiés de définir le nom de la machine.
Ces appels ont la forme suivante :

gethostname ( nom, longueur ) ;
sethostname ( nom, longueur ) ;
nom : est un pointeur sur une cha.ne de caractères contenant le nom de la machine
longueur : est la taille du nom.
7.4- Obtenir des informations relatives aux machines

31
Il existe des bibliothèques de procédures qui permettent de retrouver l’information relative .
une machine à partir de son nom de domaine ou de son adresse IP. Lorsqu’elles sont
utilis.es sur des machines qui ont accès à un serveur de noms de domaines. Elles .mettent
une requête et attendent la réponse. Lorsqu’elles sont utilisées
sur des machines qui n’ont pas accès à un serveur de nom, les machines obtiennent les
informations . partir d’une base de donn.es stockée sur mémoire secondaire.
La fonction gethostbyname (rechercher une machine par son nom) accept un nom de
domaine et renvoie un pointeur vers une structure qui contient l’information relative à cette
machine.
L’appel est le suivant :
ptr = gethostbyname (char *cha.ne_nom) ;
La structure où gethostbyname met les information est la suivante :

struct hostent
{
char *h_name ; /*nom officiel de la machine*/
char *h_aliases ; /*liste des surnoms de cette machine*/
int h_addrtype ; /*type d’adresse (exemple adresse IP) */
int h_length ; /*longueur de l’adresse */
char **h_addr_list ; /*liste des adresses de la machine */
/*une machine peut avoir plusieurs adresses comme c’est le cas pour les
Routeurs */
}
#define h_addr a_addr_list[0] ;
La fonction gethostbyaddr ( rechercher une machine par son adresse) produit le même
résultat . La différence entre les deux est que cette fonction a pour argument l’adresse de la
machine.
ptr = gethostbyaddr (char *addr,int lgr,int type ) ;
addr pointe vers l’adresse de la machine.
lgr longueur de l’adresse.
type indique le type d’adresse ( adresse IP par exemple ).
7.5- Obtenir des informations relatives aux réseaux

De la même façon que pour l’accès aux informations sur les machines à travers le réseau ou
une base de donn.es, on peut accéder aux informations sur le réseau par les procédures
‘’rechercher-nom-du reseau-par-nom’’ (getnetbyname).
Cette procédure prend comme paramètre un nom de réseau et rempli une structure dont elle
retourne le pointeur.
ptr = getnetbyname (char *nom) ;
La structure remplie est la suivante :

struct netent
{
char *n_name ; /*nom officiel de réseau *:
char **n_aliases ; /*surnom du réseau */
int n_addrtype ; /*type d’adresse */
int n_net ; /*adresse du réseau sur 32 bits */
/*une adresse IP par exemple où le numéro de machine sera z.ro */
};
32
La fonction getnetbyaddr ( rechercher-nom-de reseau-par-adresse) produit le même résultat.
La différence entre les deux est que cette fonction a pour argument l’adresse de la machine.
ptr = getnetbyaddr (addr_net, type ) ;
addr_net est une adresse sur 32 bits.
type indique le type d’adresse.
7.6 – Obtenir des informations relatives aux protocoles

Dans la base de donn.es des protocoles disponibles sur la machine, chaque protocole a un
nom officiel, des alias (surnoms) officiels et un num.ro de protocole officiel. La procédure
getprotobyname permet d’obtenir des informations sur le protocole en donnant son nom.
ptr = getprotobyname( char *proto_name) ;
La fonction renvoie un pointeur sur la structure d’information suivante :

struct protoent
{
char *p_name ; /*nom officiel du protocole*/
char **p_aliases ; /*surnoms du protocoles*/
int p_proto ; /*num.ro du protocole*/
};
La fonction getprotobynumber produit le même résultat mais fournie comme argument

le numéro du protocole.
ptr = getprotobynumber (int num_proto ) ;
7.7- Obtenir des informations relatives aux services réseaux

Certains numéros de ports sont réservés pour TCP comme pour UDP, ainsi par exemple le
port 43 correspond au service whois (qui_est_ce) qui permet de donner des informations sur
les utilisateurs d’une machine serveur.
La procédure getservbyname permet d’obtenir des informations sur le service en donnant
comme argument une cha.ne de caractères contenant le num.ro du port, et une chaîne
contenant le protocole utilisée.
ptr = getservbyname (char *num_port, char *proto) ;
ptr pointe sur la structure suivante :

struct servent
{
char *s_name ; /*nom du service */
char **s_aliases ; /*surnoms du service*/
int s_port ; /*num.ro du port */
char *s_proto ; /*nom du protocole*/
}
33
CHAPITRE 4 : LES APPELS DE PROCEDURES A DISTANCE
I- PRESENTATION DES RPC
Cette section présente d'abord les principes généraux des RPC, sans se fixer sur un
système particulier comme SUN RPC ou OSF DCE RPC (utilisé, notamment, par Microsoft).
Ensuite, SUN RPC, qui est typique, est présenté en détails.
1.1- Définition
Les appels de procédures éloignées (Remote Procedure Calls) permettent d'appeler des
procédures en dehors de l'espace d'adressage du processus
En d'autres mots, un programme local peut:
• exécuter une procédure sur une machine distante

• lui passer des données
• en récupérer des résultats
Les RPC permettent d'écrire des applications réparties qui peuvent exploiter des ressources
réparties dans tout le réseau.
Un système RPC est
• un ensemble de logiciels nécessaires pour permettre de programmer des appels de

procédures éloignées
• les primitives de communication à lier avec l'application et les programmes auxiliaires
nécessaires pour prendre en charge l'exécution d'appels de procédures éloignées et
permettre au programmeur de se concentrer sur l'application elle-même
Un système RPC est une manière de prendre en charge la répartition dans une application
informatique
Un système RPC n'est pas un environnement de traitement informatique parallèle.
34
1.2- Les RPCS en général
II- LES DIX (10) ETAPES DE L’EXECUTION D’UN RPC
1. Le processus client appelle une procédure locale: la souche cliente ("client stub").
2. La souche cliente emballe l'identification et les arguments de la procédure dans un
format normalisé et les envoie en un ou plusieurs messages sur le réseau.
3. Le réseau transmet les messages au système distant.
4. La souche serveur ("server stub") (un programme) reçoit et déballe les messages.
5. La souche serveur appelle la procédure locale demandée avec les arguments reçus
de la souche cliente.
6. Quand la procédure est terminée, elle renvoie ses résultats à la souche serveur.
7. La souche serveur emballe les résultats dans un format normalisé et les envoie en un
ou plusieurs messages sur le réseau.
8. Le réseau transmet les messages au système client.
9. La souche cliente reçoit et déballe les messages.
10. La souche cliente renvoie les résultats comme une procédure ordinaire.
35
III- PROBLEMES DE TRANSPARENCE DES RPC
• But: l'usage de RPC doit être identique à celui de procédures locales.

• Aspects à considérer:
o passage des paramètres,
o établissement des liens entre le programme appelant et la procédure,
o protocole de transport,
o traitement des exceptions (erreurs),
o sémantique de l'appel,
o représentation des données,
o performances,
o sécurité.
• Passage des paramètres sur le réseau:
o une structure de données passée par valeur;
o pas de pointeurs dans cette structure!
• Etablissement des liens:
o trouver une machine distante qui contienne le serveur nécessaire: c'est en
général l'application qui s'en charge;
o trouver le serveur voulu sur cette machine: une solution typique est le
portmapper (on y reviendra).
• Protocole de transport:
o orienté connexion
o ou sans connexion.
Lorsqu'on utilise un protocole sans connexion, c'est l'application qui doit se

préoccuper des pertes de packets, etc.
• Traitement des exceptions:

Les sources possibles de problèmes sont significativement plus nombreuses que lors
d'un appel local:
o une erreur peut se produire dans la procédure elle-même, sur le serveur,
o les souches, cliente et serveur, peuvent avoir un problème de réseau,
o le serveur peut se "planter" à tout moment,
o le client lui même peut se "planter", laissant le serveur orphelin
Il faut rapporter les erreurs, mais
o comment?
o quand?
o à qui?
• Sémantique de l'appel
Une procédure locale est exécutée exactement une fois.
Une procédure éloignée peut être exécutée
o exactement une fois,
o au moins une fois,
o au plus une fois.
Exemple: si le serveur se "plante"
o avant que la souche n'appelle la procédure –> 0 exécutions

o après l'exécution de la procédure –> 1 exécution
36
o idem mais après plusieurs essais (après "time-out") –> 2,3 exécutions?
Comment la souche cliente peut-elle savoir ce qui s'est passé?

Certaines procédures peuvent, sans inconvénients, être exécutées un certain nombre
de fois. on les appelle des procédures idempotentes:
o lire ou écrire un bloc sur disque,

o calculer une racine carrée.
D'autres procédures ne sont pas idempotentes
o ajouter 512 octets à la fin d'un fichier,

o soustraire un montant d'un compte en banque.
Quel est le comportement acceptable pour un système RPC?
oexactement une fois: difficile à garantir;

oau moins une fois: OK pour procédures idempotentes;
oau plus une fois:
si le RPC se termine normalement, la procédure distante a été
exécutée exactement une fois;
en cas d'erreur, on ne sait pas: une fois ou pas du tout.
• Représentation des données
Problèmes
o ordre des bytes dans les mots (machines petit-boutistes ou gros-boutistes),
o taille des structures de données (booléens, entiers,..),
o représentation des nombres en virgule flottante,
o ASCII vs EBCDIC vs ISO8859-1 vs UNICODE , ...
Solution: représentation normalisée des structures de données sur le réseau

2 philosophies:
o typage implicite: on ne transmet que les valeurs,

o typage explicite: chaque valeur est précédée de la déclaration de son type et
de sa longueur.
La plupart des systèmes utilisent le typage implicite.

BER (Basic Encoding Rules), la syntaxe de transfert associée à ISO ASN.1, utilise le
typage explicite.
• Performance: Perte d'un facteur 10 à 100 par rapport à un appel de procédure local.
Sécurité
• Permettre à un programme distant d'exécuter une procédure sur votre système est
comparable à lui permettre d'y exécuter une commande :chaque demande doit être
examinée du point de vue sécurité.
37
Sun RPC: un survol
Présentation
• Sun RPC est un environnement développé par Sun pour permettre la conception
d'applications réparties basées sur le paradigme d'Appels de Procédures Eloignées.
• Cet environnement a été construit sur base des sockets, mais peut maintenant
s'utiliser sur n'importe quel type d'interface réseau.
• Les détails des sockets sont tout-à-fait cachés aux utilisateurs.
• Il est possible d'utiliser seulement certaines composantes de l'environnement RPC
pour certaines applications. Dans ce cas, les sockets, ou une interface réseau
similaire peut être visible.
IV- LES ETAPES CLASSIQUES DU DEVELOPPEMENT CLASSIQUES DU

DEVELOPPEMENT D’APPLICATION
Une application basée sur Sun RPC est développée en 4 étapes:
• Définition du "protocole" spécifique, propre à l'application, utilisé au-dessus des RPC:

o définition des données envoyées aux serveurs,
o définition des résultats renvoyés au client.
• Programmation de la procédure main() du processus client .
• Développement des procédures du serveur.
• Grâce à un outil (RPCGEN), production des souches cliente et serveur qui se
chargent des détails de bas niveau de l'appel à distance.
38
Schéma d'une application RPC
V- ETABLISSEMENT DES LIENS
Chaque procédure RPC est définie par un numéro de programme, un numéro de version
et un numéro de procédure.
• Le numéro de programme désigne un groupe de procédures associées.

• Au sein d'un "programme", chaque procédure est identifiée par un numéro de
procédure.
• Le numéro de version permet d'identifier des versions successives du même
programme.
L'appelant d'une procédure éloignée doit utiliser ces trois nombres pour désigner cette
procédure.
Certaines applications bien connues ont reçu un numéro de programme repris dans /etc/rpc).
Protocole de transport et sémantique
• Sun RPC ne tient aucun compte du protocole de transport sous-jacent:

o RPC ne se préoccupe pas de la façon dont les messages sont transmis d'un
processus à l'autre;
o les protocoles RPC ne s'intéressent qu'au contenu des messages.
• Sun RPC ne fait rien en rapport avec la fiabilité
• Le programmeur d'application doit tenir compte du protocole utilisé sous les RPC:
39
o transport fiable –> sémantique=au plus une fois (pour autant qu'il n'y ait pas
de bogue dans le serveur) !): le seul problème possible est une coupure de la
connexion;
o transport non fiable –> grâce aux retransmissions sur time-out du système,
sémantique=au moins une fois (les time-out doivent être gérés par le
programmeur): ceci convient pour les procédures idempotentes.
• sémantique=au plus une fois peut être obtenue même avec un protocole non fiable
dans certaines des implémentations des RPC:
o dans le protocole Sun RPC, chaque appel d'un client est identifié par un
identificateur de transaction de 32 bits: le xid;
o avec un transport par datagramme (comme UDP), on peut demander au
serveur de maintenir une cache des réponses aux dernières transactions qu'il
a traitées (indexé par xid, prog., vers., proc. et adresse UDP du client);
o si, suite à une erreur réseau ou à un time-out, la souche cliente renvoie à
nouveau la même requète, le serveur ne répète pas l'opération, mais renvoie
le résultat précédent gardé dans sa cache.
o L'utilisateur est responsable de la taille de la cache et de la valeur du time-out
de retransmission; en cas de mauvais choix, le comportement est
imprévisible!
• Lorsque ce service n'est pas disponible, le programmeur peut l'implémenter lui-
même.
Sélection du protocole de transport
• UDP/IP conviendra mieux lorsque:

o les procédures sont idempotentes, ou, au moins, la même procédure peut être
exécutée plus d'une fois sans inconvénients,
o la taille des arguments et résultats est inférieure à un paquet UDP (8 Kbytes),
o le serveur est séquentiel et doit servir de nombreux clients.
• TCP/IP conviendra mieux lorsque:

o l'application doit être très fiable,
o les arguments ou les résultats prennent plus de 8 Kbytes.
Représentation des données sur le réseau
• Sun RPC fait l'hypothèse de l'existence de
eXternal Data Representation (XDR)
une norme de description et d'encodage de données indépendamment de la

machine où elles se trouvent
• Grâce à XDR, Sun RPC accepte n'importe quelles structures de données dans les
arguments et résultats, indépendamment de
o l'ordre des bytes dans les mots des différentes machines,
o les conventions de représentation en mémoire des structures de données.
• RPC convertit les structures de données dans le format XDR avant de les envoyer
sur le réseau (sérialisation),
• convertit dans le format local les données reçues encodées en XDR (désérialisation).
• Des outils sont disponibles pour construire automatiquement les procédures de
sérialisation et désérialisation.
40
Ces outils sont basés sur un langage de description des structures de données
(XDRL) assez proche de C.
Le "portmapper" (programme rpcbind ou portmap)
Le portmapper est un service destiné à localiser une procédure distante sur un hôte
donné:
• la localisation est le numéro du port par lequel le serveur attend les requêtes pour les
procédures d'une version donnée d'un certain programme;
• le serveur doit s'être enregistré auprès du portmapper en communiquant à celui-ci le
numéro de port sur lequel il attend les requêtes concernant les procédures de cette
version de ce programme ;
• la souche cliente consulte le portmapper de la machine du serveur pour découvrir ce
numéro de port.
•
o les arguments de cette demande sont les numéros de programme et de

version;
o le résultat est un numéro de port sur le serveur, s'il y en a un pour servir cette
version de ce programme.
• A partir de ce moment, la souche cliente s'adresse directement au serveur grâce à ce
numéro de port.
VI- DEUX APPROCHES DE CONCEPTION

41
Un concepteur d’application distribuée peut procéder selon deux approches :
conception orientée communication :
o définition du protocole d’application (format et syntaxe des messages)
inter-opérant entre le client et le serveur,
o conception des composants serveur et client, en spécifiant comment ils
réagissent aux messages entrants et génèrent les messages sortants.
conception orientée application :
o construction d’une application conventionnelle, dans un environnement
mono-machine,
o subdivision de l’application en plusieurs modules qui pourront s’exécuter
sur différentes machines.
VII- PRINCIPE GENERAL
Souvent, quand un client envoie une requête (des paramètres), il est bloqué jusqu'à la
réception d'une réponse.
Analogie avec un appel de fonction

o la fonction ou procédure ne rend la main au programme appelant qu'une fois le
traitement (calcul) terminé
RPC - Remote Procedure Call

o permettre à un processus de faire exécuter une fonction par un autre processus se
trouvant sur une machine distante
o se traduit par l'envoi d'un message contenant l'identification de la fonction et les
paramètres
o une fois le traitement terminé, un message retourne le résultat de la fonction à
l'appelant
L'objectif des RPC est de faire en sorte qu'un appel distant ressemble le plus possible à un
appel local
o Le processus client (l'appelant) est lié à une petite procédure de bibliothèque,
appelée stub client, qui représente la procédure du serveur dans l'espace
d'adressage du client
o Le processus serveur (l'exécutant) est lié à un stub serveur qui représente l'exécution
du client
o Dissimule le fait que l'appel de la procédure n'est pas local : le programmeur de
l'application utilise un appel de procédure "normal"
VIII- LE MODELE RPC
42
43
CHAPITRE 5 : LA PROGRAMMATION RESEAU TCP ET UDP EN C
I- PREAMBULE
Le réseau doit être configuré de la manière suivante :
II- UDP
Récupérez le programme les programmes : udpc1.c (client UDP en C), udps1.c (serveur
UDP en C).
2.1 Client/serveur UDP en C

1. compilez udpc1.c et udps1.c
2. ouvrez deux fenêtres séparées. Sur la première, exécutez le programme serveur
udps1.c
3. pendant que ce dernier est lancée, sur la deuxième fenêtre :
(a) vérifiez avec la commande ps -aux que le programme serveur udps1 est bien en
cours d’exécution et qu’il n’y en a qu’un seul
(b) vérifiiez avec la commande netstat -a -n que le port UDP/5000 est effectivement
ouvert
(c) lancez l’exécution du client udpc1
4. lisez les deux programmes udpc1.c et udps1.c et déduisez-en le protocole applicatif
dont vous dessinerez le diagramme.
5. lancez wireshark et relancez l’exécution de udpc1 et udps1. Verifiez que votre
diagramme d’´échange est correct.
6. lancez udps1 et udpc1 sur deux ordinateurs séparées. Vous prendrez soin de
modifier udpc1.c pour atteindre l’adresse adaptée.
III- TCP
Mêmes questions avec les programmes simples client/serveur TCP en C: tcp1c.c, tcp1s.c
3.1 Serveur TCP multiclient en C

Le programme serveur serveur tcp select.c permet de gérer plusieurs clients simultanément
et de gérer également un timeout. Compilez-le et exécutez le. Lancez simultanément en
local ou non des clients (par exemple tcpc1, netcat et ClientTCP)
IV- ANNEXE
44
4.1- Programmation en C avec les sockets
Programmation par socket

Création de la socket : socket
Etablissement de la connexion : bind, listen, connect ou accept
Echange de données : read et write (socket = descripteur de fichier) ou sendto et
recvfrom
Fermeture de la connexion : close ou shutdown
L’enchainement des opérations dépend du mode de connexion :
Mode connectée (TCP)
Mode non connectée (UDP)
Structure sockaddr in (IPv4) Point de communication défini par une adresse et un port.
Structure sockaddr in (IPv4)

sin_family représente le type de famille (AF INET pour IPv4)
sin_port représente le port à contacter. S’il est nul, il est laissée au choix du
système d’utiliser un port libre quelconque.
s_addr représente l’adresse de l’hôte. On utilise généralement
inet_addr (const char * adr) qui convertit une adresse IP notée sous la forme
”XXX.YYY.ZZZ.TTT”
INADDR ANY signifie que le socket peut être associé à n’importe quelle adresse IP
de la machine locale.
sin zéro contient uniquement des zéros (étant donné que l’adresse IP et le port
occupent 6 octets, les 8 octets restants doivent être à zéro)
Socket Création d’une socket du coté client ou du côté serveur
45
famille : famille de protocole utilisée (PF INET pour IP)
type : type de service (orientée connexion ou non).
o SOCK STREAM : mode connecté (TCP)
o SOCK DGRAM : mode déconnecté (UDP)
o SOCK RAW : (IP)
protocole : protocole permettant de fournir le service desiré. Dans le cas d’IP, on le
mettra ainsi toujours à 0 (le système choisit).
Options de la socket : setsockopt Manipule les options associées à une socket.
level : à quel niveau il faut interpréter les options (socket ? TCP?) En général
SOL SOCKET.
optname : options binaires :
SO KEEPALIVE : gardant la socket ouverte pour les sockets orientées
connexion
SO REUSEADDR : autoriser la reutilisation des adresses locales
SO LINGER : un appel close ou shutdown ne se terminera pas avant que tous
les messages en attente pour la socket aient été correctement émise ou que
le délai soit ´écoulé
SO BROADCAST Fixer ou lire l’attribut broadcast
bind Attache un point de communication (sockaddr) à une socket.
s la socket
adr l’adresse. Structure sockaddr in pour IPv4, sockaddr in6 pour IPv6.
lg est la taille de adr
Programmation TCP
Etapes de programmation TCP
Le serveur :
1. créée une socket (SOCK STREAM)
2. définit un point de communication sockaddr in
3. (INADDR ANY, port d’ecoute)
4. utilise bind pour lier les deux
5. place la socket en mode ouverture passive avec listen
46
6. attend une connexion d’un client avec accept sur la socket d’´écoute.
7. le dialogue se fait par read/write ou send/recv par la socket de dialogue renvoyée par
accept.
8. la socket de dialogue et la socket d’´écoute sont fermées (close).
Le client :
1. créée une socket (SOCK STREAM)
2. se connecte au serveur (désignée par un point de communication ”adresse IP du
serveur, numéro de port d’écoute du serveur”) avec connect
3. le dialogue se fait par read/write ou send/recv par la
4. socket.
5. la socket est fermée (close)
serveur : listen Pour indiquer que la socket pourra accepter des connexions entrantes.
nbmax : nombre maximal de connexions pouvant être mises en attente.

Renvoi SOCKET ERROR en cas d’erreur, 0 sinon.
serveur : accept permet la connexion en acceptant un appel.
En attente de connexion en provenance d’un client.

Utilisée uniquement par le serveur
Fonction bloquante qui ne se débloque qu’à la connexion d’un client (ou en
cas d’erreur).
cli addr est rempli avec l’adresse du client
cli len est rempli avec la longueur de cli addr
accept retourne un nouveau descripteur de socket pour la phase de dialogue,
et INVALID SOCKET si erreur.
client : connect Permet d’établir une connexion avec un serveur.
47
Assure la connexion vers le serveur
Utilisée uniquement par le client
serv addr l’adresse+port du serveur à contacter
serv len la longueur de serv addr
retourne 0 si la connexion s’est bien déroulée, sinon -1.
Envoi de données dans la socket avec write
s : la socket
buffer : tampon contenant les octets à envoyer au client
len : nombre d’octets à envoyer
renvoie le nombre d’octets effectivement envoyés
Envoi de données dans la socket avec send
s : la socket
buffer : tampon contenant les octets à envoyer au client
len : nombre d’octets à envoyer
flags : type d’envoi :
MSG DONTROUTE : les données ne routeront pas
MSG OOB : les données urgentes (Out Of Band) doivent être envoyées
le flag 0 : envoi normal
renvoie le nombre d’octets effectivement envoyées
Réception de données de la socket avec read
s : la socket
buffer : tampon qui sera rempli avec les octets reçus
len : nombre d’octets à lire
read est une fonction bloquante
Réception de données de la socket avec recv.
48
s : la socket
buffer : tampon qui sera rempli avec les octets reçus
len : nombre d’octets à lire
flags : type de lecture :
MSG PEEK : les données lues ne sont pas retirées de la file de réception
MSG OOB : les données urgentes (Out Of Band) doivent être lues.
le flag 0 : lecture normal
renvoie le nombre d’octets effectivement lus.
recv est une fonction bloquante.
Fermeture de socket – close/shutdown Fermeture d’un socket en permettant au système

d’envoyer les données restantes (pour TCP)
La fonction shutdown() permet la fermeture d’un socket dans un des deux sens (pour une
connexion full-duplex) ou les deux :
Suivant la valeur du sens :

0 : la socket est fermée en réception
1 : la socket est fermée en émission
2 : la socket est fermée dans les deux sens
close() comme shutdown() retournent -1 en cas d’erreur, 0 si la fermeture se déroule bien.
Programmation UDP
Etapes de la programmation UDP Suivant le dialogue, chaque participant est tour à tour
receveur et expéditeur.
Le receveur
1. crée une socket (SOCK DGRAM)
2. définit un point de communication sockaddr in (INADDR ANY, port d’écoute)
4. reçoit les messages avec rcvfrom
5. ferme la socket avec close
L’expéditeur
1. crée une socket (SOCK DGRAM)
2. définit un point de communication sockaddr in (INADDR ANY, 0)
4. cree le message à envoyer, et le point de communication décrivant le destinataire
sockaddr in (adresse + port)
5. envoie les messages avec sendto à cette adresse.
6. ferme la socket avec close
49
sendto Envoyer un message en mode non connecté
buf : le message a transmettre

len : la longueur du message
flag : 0 pour envoi de messages normaux
to : l’adresse destinataire
tolen : la taille de l’adresse destinataire
recvfrom Recevoir un message en mode non connecté
buf : là où sera stockée le message reçu

len : taille max du buffer
flag : 0 pour réception de messages normaux
from : l’adresse+port de la source du message y sera insérée
len : taille de l’adresse y sera insérée
le retour est la taille réelle du message
4.2- Multiplexage d’entrées/sorties synchrones : select

Attente passive bloquante débloquée soit :
lors du timeout
lors d’un changement d’état de descripteur parmi ceux surveillés
trois ensembles indépendants (et ´éventuellement NULL) de descripteurs
surveillés simultanément : lecture, ´écriture, erreur.
50
4.3- Programmation en C avec les chaines
Fonctions de manipulation de chaines :
remplit la chaine ch de n caractères nuls bzero (char *ch, int n)
copie la chaine src dans la chaine dest. char *strcpy(char *dest, const char
*src)
concatène la chaine ch à la chaine dest et met le résultat dans dest. char

*strcat(char *dest, const char *ch)
retourne 0 si les chaines ch1 et ch2 sont égales. int strcmp(const char *ch1,
const char *ch2)
4.4- Outils
Tests de protocoles
Etablissement d’un dialogue TCP : telnet <adresse à atteindre> <numéro de port> (pour
quitter : Ctrl AltGr ] en mode X ou Ctrl AltGr $ en mode console)
Emulation d’un client ou d’un serveur en TCP ou en UDP : netcat (ou nc) :
Client TCP : nc host port On peut également utiliser telnet adresse numéro de
port
Serveur TCP : nc -l -p port
Client UDP : nc -u host port
Serveur UDP : nc -u -l host -p port
51
BIBLIOGRAPHIE
1. Cours de programmation réseau sur les sockets E.N.S.I.M.A.G

2. TD Département Sciences Informatique de l’Université de Cergy Pontoise
WEBOGRAPHIE
1- http://www.commentcamarche.net/contents/221-reseaux-architecture-client-serveur-
a-3-niveaux
2- http://perso.univ-lyon1.fr/olivier.gluck/Cours/Supports/M2SIR_CS/SPAI-C1-ArchiC-
S.pdf
3- http://www.info.uqam.ca/~obaid/INF4481/A01/Plan.htm
52

Client-Serveur IST

Transféré par

Informations du document

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

Client-Serveur IST

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE BANGUI REPUBLIQUE CENTRAFRICAINE

Unité - Dignité – Travail

INSTITUT SUPERIEUR DE TECHNOLOGIE

Cours d’Architecture Client/Serveur

Conçu par : M. Edgard NDASSIMBA

Donner à l’étudiant(e) ou l’Ingénieur des connaissances sur :

• Un rappel sur le modèle TCP/IP

Le volume horaire recommandé pour ce cours est de 45 heures maximum

CHAPITRE 2 : LE MODELE CLIENT - SERVEUR

PARTIE II : PROGRAMMATION DES SOCKETS

CHAPITRE 4 : LES APPELS DE PROCEDURES A DISTANCE

CHAPITRE 5 : LA PROGRAMMATION RESEAU TCP ET UDP EN C

Couches TCP/IP Protocoles

Application FTP, Telnet, HTTP, POP3, SMTP, NFS

Transport TCP, UDP

Accès réseau Ethernet, Frame Relay, FDDI, RNIS

1.1- La couche application

L’application TCP/IP la plus connue est le navigateur WEB.

1.3- La couche Internet

1- Création et encapsulation des données avec des en – têtes de niveau Application

TCP Données Transport

IP TCP Données Internet

ETL IP TCP Données EQL Accès réseau

Les 5 étapes d’encapsulation

TCP Données Segment (Transport)

IP Données Paquet (Internet)

ETL Données EQL Trame (Accès réseau)

Trames, Paquets et Segments

Une application Client/Serveur, c'est

1.1- Présentation de l'architecture à 2 niveaux

Dans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau intermédiaire,

1. Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface

• Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise ;

• Une plus grande flexibilité/souplesse ;

1.4- L'architecture multiniveaux

Applications = la raison d'être des réseaux infos

L'application est généralement répartie (ou distribuée) sur plusieurs systèmes

2.1- Terminologie des applications réseaux

2.2- Protocoles de la couche application

Le protocole applicatif définit :

2.3- Interface de programmation réseau

Les principales APIs de l'Internet

Le Gartner Group définit le middleware comme une interface de communication universelle

L’objectif principal du middleware est d’unifier, pour les applications, l’accès et la

Les exemples des middleware sont :

SQL*Net : interface proprietaires permettant de faire dialoguer une application cliente

ODBC : Objet Data Base Connexion : interface standardisée isolant le client du

III- CONCEPTION D’UNE APPLICATION CLIENT-SERVEUR

Comment découper une application informatique en clients et serveurs ?

Exemples de découpage Client/Serveur :

Modèle de Gartner pour les systèmes à 3 niveaux (3-tiers) :

IV- LES MODE DE COMMUNICATION

4.1- Mode connecté

V- LES TYPES DE SERVEURS

Pour recevoir des coups de téléphone :

3. Les sockets de type SOCK_STREAM ont la possibilité. de mettre les requêtes de

4. L’étape suivante est d’attendre les demandes de communication. C’est le rôle de la

III - ADRESSES DE SOCKETS

2- les structures d’adresse

sa_family : adresse de famille : prend la valeur AF_xxx

s_addr : 32 bits constituants l’identificateur du réseau et de la machine hôte ordonnes selon

IV - LES APPELS SYSTEME

4.1- L’appel système socket

SOCK_STREAM utilisé en mode connecté au-dessus de TCP.