Network Address Translation

TSD5 1
 Saturation de l’espace d’adressage
• L’augmentation exponentielle du nombre d’ordinateurs connectés à
l’Internet a rapidement saturé l’espace d’adressage IP
• Phénomènes dû aux entreprises qu’aux particuliers
• Côté entreprises
– hébergent souvent des serveurs devant être joints en permanence
– leurs stations de travail ont aussi souvent besoin d’accéder à tout
moment à des services externes
• Côté particuliers
– nombreux à avoir choisi un abonnement ADSL ou câble payé au forfait
et qui restent connectés en permanence (que l’attribution d’adresse
soit fixe ou dynamique)
– le prix des ordinateurs est tel qu’une famille possède souvent
plusieurs ordinateurs qui doivent tous accéder à Internet
– du point de vue FAI, une famille a les mêmes besoins qu’une petite
entreprise

TSD5 2
 Solution : adresses privées
• Gérer la pénuerie d’adresses au sein d’un réseau
• Masquer l’intérieur du réseau par rapport à l’extérieur
• Améliorer la sécurité pour le réseau interne
• Assouplir la gestion des adresses du réseau interne
• Faciliter la modification de l’architecture du réseau
interne
• Les réseaux privés utilisent les adresses suivantes
– 10.0.0.0 – 10.255.255.255
– 172.16.0.0 – 172.31.255.255
– 192.168.0.0 – 192.168.255.255

TSD5 3
 Réseaux privés
• Un réseau IP privé qui n’est pas directement
connecté sur Internet
• Les adresses IP dans un réseau privé peuvent
être réservées aléatoirement
– Ne sont pas enregistrées
– Pas de garantie quelles soient globalement unique
• Les adresses privées ne sont jamais routées
par un routeur donc impossible d’aller sur
Internet

TSD5 4
Réseaux privés

TSD5 5
 Solution des réseaux privés
• NAT : Network Address Translation
• Quand une machine interne à un réseau veut
communiquer avec un hôte sur Internet
– Transmission du paquet au routeur de sortie
– Translation de l’adresse de réseau privé en adresse
publique
– Transmission du paquet modifié au hôte de
destination

TSD5 6
 Network Address Translation
• Fonction de routeur où les adresses IP (et les
numéros de port) sont remplacées à la frontière
d’un réseau privé
• Méthode qui permet aux stations appartenant à
des réseaux privés de communiquer avec des
stations reliées à l’Internet
• NAT est lancé sur les routeurs qui connectent les
réseaux privés à l’Internet publique, pour
remplacer la paire adressse IP-port (privée) d’un
paquet IP par une autre paire adresse IP-port
(publique)

TSD5 7
 Network Address Translation
• Cisco définit les termes suivant pour la
configuration du NAT
– Adresse locale interne : adresse IP de l’hôte sur le
réseau privé
– Adresse globale interne : adresse IP publique
derrière laquelle se trouve le réseau privé
– Adresse globale externe : adresse IP publique
extérieure au réseau privé

TSD5 8
Exemple

TSD5 9
Exemple

TSD5 10
Exemple

TSD5 11
Exemple

TSD5 12
Exemple

TSD5 13
 Operation de base de NAT
• Le NAT a une table de translation d’adresse

TSD5 14
 Translation d’adresse
• NAT statique
– Une adresse publique pour chaque adresse privée
• NAT dynamique (IP masquerading)
– Une adresse publique pour plusieurs adresses privées
mais le port change

TSD5 15
Exemple

TSD5 16
Exemple

TSD5 17
 Translation d’adresse
• Problème : Comment re-diriger les trames
provenant du serveur vers la bonne machine
du réseau privé ?

TSD5 18
 Translation d’adresse
• Solution : Modifier le numéro de port ou PAT
(Port Address Translation)
– Attribution d’un numéro de port unique au niveau
de la passerelle NAT/PAT

TSD5 19
Translation d’adresse

TSD5 20
 Exercice
• On considère le réseau privé suivant relié à
l’Internet par un rputeur et une passerelle
NAT

TSD5 21
 Questions
• Q 1. La table de la passerelle est vide. Donnez
à chaque étape, les actions effectuées par
celle-ci. On supposera que l’adresse publique
attribuée au réseau est 45.10.10.1 et que la
passerelle NAT attribue les numéros de port
séquentiellement en démarrant par 10000.
– La passerelle reçoit du réseau privé un paquet
avec source=10.0.0.2:10234 et
destination=14.24.164.2:80

TSD5 22
 Questions
– La passerelle reçoit du réseau privé un paquet
source=10.0.0.5:16777 et
destination=74.125.230.81:20
– La passerelle reçoit de l’Internet un paquet avec
source=74.125.230.81:20 et
destination=45.10.10.1:10001
– La passerelle reçoit de l’Internet un paquet avec
source=97.48.164.77:50 et
destination=45.10.10.1:80

TSD5 23
 Questions
• Q 2. On souhaite installer un serveur HTTP
(port 80) sur la machine 10.0.0.5. Comment
doit-on procéder
• Q 3.La passerelle peut-elle recevoir un paquet
IP avec pour destination 10.0.0.4 ?

TSD5 24
 Serveur DHCP
• Partie 1
Les principes de fonctionnement

• Partie 2
Quelques éléments de configuration

01/02/2019 1
 Fonctionnement du DHCP
DHCP : Dynamic Host Configuration Protocol
Donc "Protocole de configuration Dynamique
des clients"

DHCP est une extension du protocole BOOTP

qui permet à un client sans disque dur
(terminal X, imprimante, etc.) de démarrer et
de configurer automatiquement TCP/IP.

01/02/2019 2
 Fonctionnement du DHCP
L'objectif du protocole DHCP est de permettre à
un client d'obtenir une adresse IP (et d'autres
paramètres éventuellement) auprès d'un
serveur DHCP.
Remarques préliminaires :
Un réseau peut avoir plusieurs serveurs
DHCP.
Le client ne désigne pas un serveur (cf.
seconde partie)
01/02/2019 3
 Fonctionnement du DHCP
L'obtention d'une adresse se fait en 4 phases :
 Demande de bail IP par le client.
 Offre de bail IP par un serveur.
 Sélection d'une offre par le client.
 Accusé de réception de bail IP par le
serveur.
(Notion de bail cf. plus loin)

01/02/2019 4
 Fonctionnement du DHCP
Phase 1 : Demande de bail IP par le client
• Initialisation du client avec une version
limitée de TCP/IP
• Le client diffuse une demande d'adresse IP
(message DhcpDiscover) avec :
• source 0.0.0.0
• destination 255.255.255.255

01/02/2019 5
 Fonctionnement du DHCP
Phase 2 : Offre de bail par un serveur
Tous les serveurs reçoivent la demande. S'ils
sont configurés pour répondre (message
DhcpOffer), ils diffusent une offre avec les
informations suivantes :
• L'adresse MAC du client
• Une adresse IP
• Un masque de sous-réseau
• Une durée de bail
• Son adresse IP (pour la phase 3)
01/02/2019 6
 Fonctionnement du DHCP
Un client DHCP attend une offre pendant une
seconde. En cas de non réponse il rediffuse sa
demande quatre fois (à des intervalle de 9, 13
et 16 secondes puis un intervalle aléatoire
entre 0 et 1000 millisecondes). Après ces
quatre tentatives, il renouvelle sa demande
toutes les 5 minutes.

01/02/2019 7
 Fonctionnement du DHCP
Phase 3 : Sélection d'un bail par le client
• Le client sélectionne une offre (en général la
première)
• Le client annonce par diffusion qu'il a accepté
une offre (message DhcpRequest). Son message
comporte l'identification du serveur
sélectionné. Ce dernier sait que son offre a été
retenue ; tous les autres retirent leur offre et
l'adresse redevient disponible.

01/02/2019 8
 Fonctionnement du DHCP
Phase 4 : Accusé de réception par le serveur

Le serveur sélectionné accuse réception au client

(message DhcpAck). Son message contient
éventuellement d'autres informations (serveur
DNS, Passerelle, etc.)

01/02/2019 9
 Fonctionnement du DHCP
Client Serveur
Demande de Bail IP

Offre de Bail IP

Sélection d'un Bail IP

Accusé de réception

En Résumé
01/02/2019 10
 Fonctionnement du DHCP
L'affectation d'une adresse IP n'est pas
permanente. Elle est accordée pour une
certaine durée : le bail.
Le client doit donc renouveler ce bail.
1ère demande de renouvellement :
• Elle est faite à la moitié du bail (message
DhcpRequest) au serveur à l'origine du bail.
• Si elle est accordée et le client continue avec
un nouveau bail et éventuellement de
nouveaux paramètres (message DhcpAck).
01/02/2019 11
 Fonctionnement du DHCP
1ère demande de renouvellement
• Si le serveur est absent, il reste 50 % du
temps.
2de demande de renouvellement
• Si à 50 % la demande a échoué, il y a
demande de renouvellement à 87,5 % du
bail.
• Cette fois la demande est adressée à tous les
serveurs (diffusion).
01/02/2019 12
 Fonctionnement du DHCP
2de demande de renouvellement
• Un serveur peut répondre en proposant un
nouveau bail (message DhcpAck) mais peut
également répondre avec un message
DhcpNack qui oblige le client à se
réinitialiser (reprise de la procédure
d'obtention d'un bail)
Si le bail expire (ou message DhcpNack)
• Reprise de la procédure d'obtention d'un
bail
01/02/2019 13
 Client DHCP
Le paramétrage d'un client DHCP est très
simple :

01/02/2019 14
 Serveur DHCP
Installation, création du serveur.

01/02/2019 15
 Serveur DHCP
Installation, création du serveur.

01/02/2019 16
 Serveur DHCP
Création et configuration d'une étendue.

01/02/2019 17
 Serveur DHCP
Création et configuration d'une étendue.

01/02/2019 18
 Serveur DHCP
Création et configuration d'une étendue.

01/02/2019 19
 Serveur DHCP
Les réservations d'adresses.

01/02/2019 20
 Serveur DHCP
Les réservations d'adresses.

Permettent de faire un adressage statique à l'aide d'un

serveur DHCP.
Intéressantes avec l'utilisation d'un système de restauration
d'images machine.
01/02/2019 21
 Serveur DHCP
Les Options

01/02/2019 22
 Serveur DHCP
Les Options

01/02/2019 23
 Serveur DHCP
Les Options

01/02/2019 24
 4 - Couches Transport

transmission de blocs d'octets entre processus

principes
les solutions TCP et UDP

Couche Transport 1
 Le rôle d'une couche
-Transport
le rôle d'une couche Transport est d’acheminer des octets
● entre des processus s'exécutant dans des systèmes appartenant à la
même couche Réseau,
● sans qu'ils aient à se préoccuper des problèmes de médium, de
routage, etc...

PA2 PC2
PA1 PB1 PC1
PA3 PB2 PC3

couche Réseau => transmission entre systèmes

couche Transport => transmission entre processus

Couche Transport 2
 Services et Protocoles de
Transport
Service
● transmission de données entre processus (de bout en bout)
● données normales, données express
● Transparence des données transférées (format, taille et types de codage
de données)
● mode connecté, mode non connecté

Protocole
● classes de protocole, selon la qualité du Service Réseau
● optimisation des ressources Réseau

les couches Transport les plus utilisées

1 Service en mode connecté (COTS), 5 protocoles
ISO
1 Service en mode non connecté (CLTS), 1 protocole

technologie 1 Service en mode connecté (TCP), 1 protocole

TCP/IP 1 Service en mode non connecté (UDP), 1 protocole

Couche Transport 3
 Les protocoles de Transport
Transport ISO technologie TCP/IP
COTS
CLTS TCP UDP
0 1 2 3 4
transfert de données oui oui oui oui oui oui oui oui
connexion oui oui oui oui oui - oui -
correction des erreurs
non oui non oui oui - - -
signalées
détection et correction
non non non non oui non oui non
des erreurs non signalées
contrôle de flux non non oui oui oui non oui non
données exprès non non oui oui oui non oui non
multiplexage non non oui oui oui non non non
éclatement sur plusieurs
non non non non oui non non non
connexions Réseau

COTS : Connection Oriented Transport Service

CLTS : Connectionless Transport Service

Classes (de qualité) de Service Réseau → A B C

dét ect e les erreurs oui oui non
t ent e de corriger les erreurs détectées oui non -
signale les erreurs non corrigées oui oui -

Couche Transport 4
 Les solutions de la
technologie TCP/IP
TCP
● Transmission Control Protocol
● service en mode connecté
● détection des pertes et
duplications
● tentative de correction
● signalement des échecs
● livraison dans l'ordre d'émission
● contrôle de flux
● champ protocole 6
UDP
● User Datagram Protocol
● service en mode non connecté
● non fiable : ps d'accusé de réception,
aucun contrôle de flux, ni ré-
ordonnancement de segments
● champ protocole 17
● simple : peu de mémoire utiliséee,
assez rapide
● adapté aux petites quantités de
données

Couche Transport 5
 Le Service TCP

mode connecté
● 2 canaux de transmission indépendants
● files d'attente des octets en attente de livraison
● 3 facilités
● établissement (création des 2 canaux)
● transmission
● terminaison (destruction des canaux)

utilisateur utilisateur
normale

normale
express

express
Fournisseur de
Service de Transport

Couche Transport 6
 Adresse des points d'accès au
Service-TCP ( a n a l o g u e p o u r U D P )
adresse d'un TCP-SAP 193.54.51.1/6/80 (6=TCP 17=UDP)
● identification de l'entité-IP du système (adresse-IP)
● adresse du point d'accès au Service-IP pour les entités-TCP [6]
● adresse du point d'accès au Service-TCP (n°port)
● privilégié bien connu enregistré
identification d'une connexion-TCP
● les TCP-SAP des deux extrémités de la connexion-TCP
193.54.51.1/6/80 ↔ 192.168.51.189/6/1595

serveur Web
serveur SMTP navigateur

80 25 1595
entité-TCP entité-TCP
tcp tcp

6 6
entité-IP entité-IP
193.54.51.1 192.168.51.189

Couche Transport 7
 Transmission de données par
UDP ou TCP
les données sont transmises dans des PDU-TCP ou des PDU-
UDP, transportées par le Service IP qui livre ... peut-être,
une seule fois
les risques
● perte de PDU-IP → perte de la PDU-TCP ou PDU-UDP encapsulée et des
données qu'elle contient
● livraisons multiples de la même PDU (duplication), donc de données
● livraison d'une suite d'octets dans un ordre différent de celui de la
soumission

➔ TCP tente de détecter tous les problèmes et de les corriger

➔ UDP ne fait ni détection, ni correction → ce sont les entités
qui utilisent le Service-UDP qui doivent le faire si
nécessaire

Couche Transport 8
 Protocole TCP - transmission
de données
les octets de données expédiés sont numérotés
● initialisation à l'établissement de connexion
● le n° du prochain octet à expédier
● le n° du prochain octet attendu en réception
● actualisés au fur et à mesure des expéditions et des réceptions
expédition d'un bloc d'octets
● le n° du 1er octet du bloc,est placé dans la PDU, ainsi que le n° du
prochain octet attendu (champs seq et ack)
● le bloc est conservé en mémoire tampon
réception d'un bloc : comparaison n°reçu et n°attendu
● n°reçu = n° du prochain octet attendu → OK
● n°reçu < n° du prochain octet attendu → une duplication - ignorer
● n°reçu > n° du prochain octet attendu → une perte
correction de perte
● si, à l'échéance du RTT d'un bloc expédié, une entité-TCP n'a pas reçu un
ack supérieur au n°du dernier octet expédié, elle renvoie le bloc

Couche Transport 9
 Protocole TCP - établissement
de connexion
←appelant→ ←appelé→
primitives entité-TCP PDU transmises entité-TCP primitives
listen

accept
connect
calcule 1er n° (G)
réserve buffers Phase 1
type=SY
N, seq= mémorise G+1
G
calcule 1er n° (D)
réserve buffers
Phase 2
A C K, ac k=G+1
type= D
t ype= S YN, seq=
+
connect mémorise D+1
type=AC
K, ack=
D+1
Phase 3
Couche Transport 10
 Protocole TCP - établissement
de connexion
phase 1
● L'expéditeur indique son numéro de séquence initial G par exemple dans
le seq du segment SYN

phase 2
● Le récepteur indique son numéro de séquence initial D par exemple dans
le champ seq du segment SYN/ACK et indique le numéro de séquence de
l'expéditeur plus un (soit G+1) dan le champ ack du segment

phase 3
● L'expéditeur confirme en envoyant un ACK avec un numéro de séquence
augmenté de un (soit G+1) et un numéro d'acquittement correspondant
au numéro de séquence du serveur plus un (soit D+1)

Couche Transport 11
 Protocole TCP - terminaison de
connexion
terminaison ordonnée (ordered termination)
● sur primitive shutdown

● l'entité-TCP avertit l'autre entité-TCP qu'il n'y aura plus PDU transmises
de transmission, par une type=
FIN+
PDU-TCP de type FIN, ACK

ACK
l'autre acquitte par une PDU-TCP de type

entité-TCP
type=

entité-TCP
●

FIN+ACK
CK
● 2 fois (pour chaque sens de transmission) e = FIN+A
typ
type=
ACK
terminaison brutale (abort)
● sur primitive close
● l'entité-TCP envoie une PDU-TCP de type RST, et détruit les buffers (les
données non livrées sont perdues)
● l'autre entité-TCP détruit aussi les buffers,
● avertit l'utilisateur par une erreur sur la prochaine primitive

Couche Transport 12
 Protocole TCP - contrôle de
flux
une entité-TCP place les octets reçus pour l'utilisateur
dans des files d'attente où il peut en prendre livraison
● place libre dans la file d'attente = capacité de réception
● file d'attente pleine → impossible de recevoir de nouveaux octets, et
consommation inutile de ressources de (re)transmission

le contrôle de flux permet d'éviter à l'entité-TCP

expéditrice d'envoyer plus que l'entité-TCP réceptrice peut
mémoriser dans les files d'attente
● chaque entité-TCP place dans chaque PDU qu'elle envoie le nb d'octets
libres dans la file d'attente (champ win)

Remarque : autre technique : "stop and go"

Couche Transport 13
 la PDU TCP
n° du 1er octet
n°port source n°port destination de données
= 4229 = 21 (FTP)

AA AA AA AA AA AA AA AB 08 00 2B 91 B0 D0 00 e0
b1 45 12 06 08 00 45 00 00 32 0e f1 00 00 39 06
5e 65 c1 37 5f 01 c1 36 33 01 0f 85 00 15 3f b5
1b 97 1f 24 de b9 50 18 40 00 c6 fa 00 00 55 53
45 52 20 6d 63 76 0d 0a 36 A2 5D 24
données =
n° du prochain PDU FTP
place libre dans la file
octet attendu d'attente de réception somme de
lg l'entête contrôle

type de PDU-TCP
type de
URG ACK PSH RST SYN FIN
PDU-TCP
(ACK+PSH) 20 10 8 4 2 1

Couche Transport 14
 Développement

1. contexte
2. spécification abstraite – exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
4. exemple : utilisation d'un Service de Transport

Développement 1
 Contexte
le développement dans le domaine de l'interconnexion de systèmes
consiste à bâtir les entités d'un fournisseur de Service (N), qui
s'appuient sur un fournisseur de Service(N-1) pour collaborer par la
transmission de PDU(N-1).
voir « Modèle de référence »
le développeur a donc besoin de :
● la spécification de Service (N)
Utilisateur
● la spécification de Protocole (N)
● la spécification de Service (N-1)

entité entité
PDU-N
Utilisateur

Fournisseur de Service N-1

Fournisseur de Service N
Développement 2
 Spécification d'une solution
la spécification d'un Service contient
● une définition générale du Service
● la définition des facilités
● la spécification des primitives de chaque facilité, de leurs paramètres
● la spécification des enchaînements de primitives possibles
la spécification d'un Protocole contient
● la spécification des PDU
● la spécification du fonctionnement d'une entité de fournisseur :
● que faire quand arrive une primitive demande ou réponse ?
● que faire quand arrive une PDU ?

ces spécifications sont indépendantes de tout

système dans lequel une entité du fournisseur peut
être installée

Développement 3
 Implantation des entités d'un
fournisseur
l'implantation d'une entité du fournisseur dans un
système peut produire une API (Application Programming
Interface) qui peut être utilisée dans les programmes des
utilisateurs du Service
● des fonctions qui traduisent les primitives
● des types de données pour les paramètres
● des fonctions annexes

l'ensemble se trouve dans

● des fichiers d'entête
● constantes
● types de données
● prototypes des fonctions
● des bibliothèques

Développement 4
 Développement

1. contexte
2. spécification abstraite
exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
4. exemple : utilisation d'un Service de Transport

Développement 5
 Spécification abstraite
Définitions générales
un fournisseur de Transport fournit un Service de Transport de
blocs d'octets entre deux processus, en les libérant de toute
préoccupation de communication

2 Services (ISO/IEC 8072)

● COTS (Connection Oriented Transport Service)
● CLTS (ConnectionLess Transport Service)

caractéristiques
le transfert de bout en bout

COTS et CLTS
●

● la transparence des informations transmises

● l'indépendance vis-à-vis des couches inférieures
● l'optimisation des ressources, selon la qualité (QOS) demandée
● l'adressage des TSAP
● la livraison des blocs d'octets transmis dans leur ordre d'émission

COTS
● le signalement des impossibilités de livraison

Développement 6
 CLTS - Service de Transport
en mode non connecté
une seule facilité : T_UnitData

deux primitives : T_UnitData.demande

T_UnitData.indication

chronogramme

paramètres
demande indication
adresse du TSAP expéditeur F
adresse du TSAP destinataire O
qualité de service F
TSDU F =

Développement 7
 COTS - Service de Transport
en mode connecté
3 phases
● établissement de connexion
● transfert de données
● terminaison de connexion

4 facilités
● établissement de connexion T_Connect
● transfert de données normales T_Data
● transfert de données express T_ExpeditedData
● terminaison de connexion T_Disconnect

Développement 8
 COTS : établissement de
connexion
chronogramme

confirmation
indication
demande

réponse
paramètres

adresse du TSAP appelant F

adresse du TSAP appelé O =
adresse du TSAP répondeur F
id. extrémité appelant F
id. extrémité appelé F
options (*) F N F N
qualité de service (*) F N F N
TSDU F = F =

(N) négociation
● des options

● de la qualité de service
le fournisseur et l'appelé peuvent modifier à la baisse

Développement 9
 COTS : transfert de données
expéditeur COTS Destinataire
paramètres

chronogramme
● id.extrémités T_Data.demande
● TSDU T_Data.indication

T_Data.demande
erreur
T_Disconnect.indication T_Disconnect.indication

utilisateur utilisateur
normale

normale
express

express
Fournisseur de
Service de Transport

Développement 10
 COTS : terminaison de
connexion
paramètres
● initiateur de la terminaison
● cause de la terminaison

autre définition
● fermeture indépendante de chaque "tuyau" de la connexion

Développement 11
 Fonctionnement d'une entité du
fournisseur (1)
elle attend un événement :
● l'arrivée d'une primitive issue d'un utilisateur, implanté dans le même
système
● l'arrivée d'une primitive issue d'un fournisseur de Service support,
contenant éventuellement une PDU venant d'une autre entité du même
fournisseur
● l'échéance d'une temporisation préalablement activée

alors elle effectue une ou plusieurs actions parmi :

● envoi d'une primitive à un utilisateur implanté dans le même système
● envoi d'une primitive à un fournisseur de Service support, contenant
éventuellement une PDU à transmettre à une autre entité

Développement 12
 Fonctionnement d'une entité du
fournisseur (2)

entité utilisateur

primitive de soumission primitive de livraison

demande / réponse indication / confirmation

entité de fournisseur

primitive de livraison primitive de soumission

indication / confirmation demande / réponse

entité de fournisseur support

Développement 13
 Les protocoles de Transport
Transport ISO technologie TCP/IP
COTS
CLTS TCP UDP
0 1 2 3 4
transfert de données oui oui oui oui oui oui oui oui
connexion oui oui oui oui oui - oui -
correction des erreurs
non oui non oui oui - - -
signalées
détection et correction
non non non non oui non oui non
des erreurs non signalées
contrôle de flux non non oui oui oui non oui non
données exprès non non oui oui oui non oui non
multiplexage non non oui oui oui non non non
éclatement sur plusieurs
non non non non oui non non non
connexions Réseau

COTS : Connection Oriented Transport Service

CLTS : Connectionless Transport Service

Classes (de qualité) de Service Réseau → A B C

dét ecte les erreurs oui oui non
tente de corriger les erreurs dét ect ées oui non -
signale les erreurs non corrigées oui oui -

Développement 14
 Développement

1. contexte
2. spécification abstraite; exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
4. exemple : utilisation d'un Service de Transport

Développement 15
 Implémentation
l'implémentation d'une spécification abstraite dans
un système consiste à
● traduire le concept abstrait de point d'accès en un concept du système visé
permettant la communication entre une entité utilisatrice du Service, et l'entité du
fournisseur de Service installée dans le système
cela dépend
● de la manière selon laquelle est installée l'entité du fournisseur de Service

● des moyens de communication dans le système

● traduire les primitives et leurs paramètres en API (Application Programming Interface

- Interface de Programmation)
● un ensemble de définitions de types de données ou de classes d'objets

● un ensemble de fonctions

● fichiers de définitions des types, classes, et prototypes

● bibliothèque(s)

Développement 16
 API pour les Services de
Transport TCP et UDP
socket
● issue de BSD 4.2 (1983)
● fichier des prototypes et types : <sys/socket.h>
● bibliothèque : libc.a
● gratuit et maintenant installé dans tous les systèmes

XTI-TLI (X/Open Transport Interface, Transport Level Interface)

● issue de Open Group (depuis 1986)
● fichier des prototypes et types : <xti.h>
● bibliothèque : libxti.a
● pas dans tous les systèmes
● installée dans luna (Tru64)
● implémentation libre pour Linux : projet OpenSS7

Développement 17
 Développement

1. contexte
2. spécification abstraite; exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
1. point d'accès et fonctions annexes
2. interface de programmation XTI/TLI
3. interface de programmation « socket »
4. exemple : utilisation d'un Service de Transport

Développement 18
 Adresse des points d'accès au
Services TCP et UDP
adresse d'un TCP-SAP ou d'un UDP-SAP
● identification de l'entité-IP du système (adresse-IP)
● adresse du point d'accès au Service-IP pour les entités-TCP[6] ou les
entités-UDP [17]
● adresse du point d'accès au Service-TCP (n°port)

serveur Web
navigateur
serveur SMTP

80 25 1595
entité-TCP entité-TCP
tcp tcp

6 6
entité-IP entité-IP
193.54.51.1 192.168.51.189

Développement 19
 API pour les adresses des
points d'accès TCP et UDP
type de données (défini dans <netinet/in.h>)
struct sockaddr_in {
8 bits sin_family; /* la constante AF_INET */
16 bits sin_port; /* à partir de htons (int port) */
32 bits sin_addr; /* à partir de gethostbyname ou htonl */
char sin_zero[8];
};
les noms des types varient selon les systèmes

des fonctions de traduction

ntohs, htons, ntohl, htonl
pour que les octets des nombres entiers soient dans le bon ordre
inet_addr, inet_ntoa
pour traduire des adresse-IP de la notation pointée à la forme 32 bits
gethostbyname
pour traduire un nom en adresse-IP
http://www.cs.vu.nl/~jms/socket-info.html

Développement 20
 Développement

1. contexte
2. spécification abstraite; exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
1. point d'accès et fonctions annexes
2. interface de programmation XTI/TLI
3. interface de programmation « socket »
4. exemple : utilisation d'un Service de Transport

Développement 22
 XTI/TLI – principes
les TSAP sont créés à la demande par les processus

état d'un TSAP

● définit la liste des événements qui peuvent se produire
● définit la liste des fonctions que l'utilisateur peut appeler
● t_getstate donne la valeur de l'état
primitives de soumission → fonctions
primitives de livraison → événements
● une file d'attente d'événements en attente de traitement
● l'erreur T_LOOK indique qu'il y a des événements en attente

● la fonction t_look donne la liste des événements en attente

● l'exécution d'une fonction, la survenue d'un événement font évoluer l'état du TSAP
paramètres des primitives → types de arguments de fonctions
● t_alloccrée une variable à utiliser en argument
● t_free libère la mémoire réservée par t_alloc
en cas d'erreur, les fonctions renvoient -1
● la variable t_errno contient le code de l'erreur

● la fonction t_error affiche le libellé de l'erreur

Développement 23
 XTI/TLI - fonctions annexes
int tsap = t_open (char *stream, int flags, struct t_info *p)
crée un TSAP, en état T_UNBND
renvoie l'identificateur du TSAP
renvoie les capacités du fournisseur de Service dans *p
stream = AIX : "/dev/xti/udp" "/dev/xti/tcp"
Solaris: "/dev/udp" "/dev/tcp"

int t_bind (int tsap, struct t_bind *a1, struct t_bind *a2)
tente d'attribuer l'adresse *a1 au TSAP
renvoie dans *a2 l'adresse attribuée
met le TSAP dans l'état T_IDLE

int t_unbind (int tsap) t_open t_bind

libère l'adresse attribuée au TSAP
met le TSAP dans l'état T_UNBND
T_UNINIT T_UNBND T_IDLE

t_close t_unbind
int t_close (int tsap)
détruit le TSAP

Développement 24
 XTI/TLI - primitives pour UDP

XTI - TLI
primitive
événement fonction
T_UnitData.demande int t_sndudata (int tsap, struct t_unit_data *ud)
T_UnitData.indication T_DATA int t_rcvudata (int tsap, struct t_unit_data *ud, int *flags)
T_UDERR int t_rcvuderr (int tsap, struct t_uderr *uderr)

t_sndudata t_rcvudata les arguments de type struct t_unit_data contiennent 3

champs de type struct netbuf
T_IDLE
ud->addr adresse de TSAP, de type struct sockaddr_in

t_rcvuderr ud->opt options spécifiques à UDP

ud->udata donnée à transmettre ou transmise

l'événement T_UDERR signale à un expéditeur l'échec d'une demande de transmission

l'argument uderr contient 3 champs de type struct netbuf
uderr->addr adresse du TSAP destinataire

uderr->opt options spécifiques à UDP

uderr->error code erreur

les champs addr sont de type struct sockaddr_in défini dans <netinet/in.h>

Développement 25
 Schéma avec UDP

t_open()

t_bind()
t_open() t_open()

autant de fois que nécessaire autant de fois que nécessaire

t_sndudata() t_rcvudata() t_sndudata()

t_rcvudata() t_sndudata() t_rcvudata()

t_close() t_close()

t_close()

appelant appelé appelant

Développement 26
 XTI/TLI - primitives pour TCP
1 – établissement de connexion
XTI - TLI
primitive
événement fonction
T_Connect.demande int t_connect (int tsap, struct t_call *appelé, *appelant)
T_Connect.indication T_LISTEN int t_listen (int tsap, struct t_call *appelant)
T_Connect.réponse int t_accept (int tsap, int tsap2, struct t_call *appelé)
T_Connect.conf... T_CONNECT int t_rcvconnect (int tsap, struct t_call *répondeur)

T_INCON
T_LISTEN, t_listen t_accept

T_IDLE T_DATAXFER

t_connect
T_OUTCON
T_CONNECT, t_rcvconnect

les arguments de type struct t_call contiennent 4 champs de type struct netbuf
appel->addr adresse de TSAP, de type struct sockaddr_in

appel->opt options spécifiques à TCP

appel->udata donnée à transmettre ou transmise

appel->sequence n°de connexion, si plusieurs

Développement 27
 XTI/TLI - primitives pour TCP
2 – transmission de blocs d'octets

XTI - TLI
primitive
événement fonction
T_Data.demande T_GODATA
int t_snd (int tsap, char * buf, unsigned lg, int flags)
T_ExpeditedData.demande T_GOEXDATA
T_Data.indication T_DATA
int t_rcv (int tsap, char * buf, unsigned lg, int flags)
T_ExpeditedData.indication T_EXDATA

l'argument buf pointe sur la mémoire contenant le bloc d'octets à

transmettre ou destinée à recevoir le bloc d'octets transmis T_GODATA T_GOEXDATA
t_snd t_snd
l'argument lg de t_snd indique la taille de la donnée à
transmettre

l'argument lg de t_rcv indique la taille de buf T_DATAXFER

si elle est plus petite que la donnée, seule le début du message est
placé dans buf par t_rcv, qui met T_MORE dans l'argument flags
T_DATA T_EXDATA
pour une donnée express, l'argument flags contient T_EXPEDITED t_rcv t_rcv

l'entier renvoyé par les fonctions indique le nombre d'octets pris

en charge, s'il n'y a pas d'erreur

Développement 28
 XTI/TLI - primitives pour TCP
3 – terminaison de connexion
XTI - TLI
primitive
événement fonction
T_Disconnect.demande int t_sndrel (int tsap)
int t_snddis (int tsap, struct t_discon *dis)
T_Disconnect.indication T_ORDREL int t_rcvrel (int tsap)
T_DISCONNECT int t_rcvdis (int tsap, struct t_discon *dis)

t_sndrel T_INREL T_ORDREL

t_rcvrel

t_snddis
T_IDLE T_DATAXFER
T_DISCONNECT
t_rcvdis
T_ORDREL t_sndrel
t_rcvrel T_OUTREL

terminaison ordonnée terminaison brutale

● des données peuvent encore être émises par l'argument dis contient 3 champs
l'utilisateur lié au TSAP en état T_INREL
dis->udata données utilisateur
● des données peuvent encore être reçues par dis->reason cause de la terminaison
l'utilisateur lié au TSAP en état T_OUTREL dis->sequence n° de connexion

Développement 29
 Schéma avec TCP

t_open()
t_bind()
t_listen()
t_open() t_open()

t_connect() t_accept() t_connect()

t_snd() t_rcv() t_snd()

t_rcv() t_snd() t_rcv()

t_sndrel() t_rcvrel() t_sndrel()

t_close() t_close() t_close()

t_close()

appelant appelé appelant

Développement 30
 Développement

1. contexte
2. spécification abstraite; exemple : Services de Transport
3. implémentation – exemple : les API XTI et socket
1. point d'accès et fonctions annexes
2. interface de programmation XTI/TLI
3. interface de programmation « socket »
4. exemple : utilisation d'un Service de Transport

Développement 31
 Sockets - fonctions annexes

création d'une socket

pour UDP : int id_socket = socket (PF_INET,SOCK_DGRAM,0)
pour TCP : int id_socket = socket (PF_INET,SOCK_STREAM,0)

attribution d'une adresse à une socket

int bind (int id_socket, struct sockaddr_in *adresse, int lg_adr)

destruction d'une socket

int close (int id_socket)

si une fonction échoue

elle renvoie -1
la variable errno contient le code de l'erreur
la fonction perror() affiche le libellé de l'erreur

Développement 32
 Sockets – fonctions pour UDP

primitive fonctions
int sendto (int id_socket,
T_UnitData.demande void *buf, int lg_buf, int flags,
struct sockaddr_in *dest, int lg_dest)

int recvfrom (int id_socket,

T_UnitData.indication void *buf, int lg_buf, int flags,
struct sockaddr_in *expéditeur, int *lg_exp)

l'entier renvoyé indique

● sendto : le nombre d'octets pris en charge pour la transmission
● recvfrom : le nombre d'octets placés dans le buffer de réception
● soit une erreur (valeur -1)

Développement 33
 Schéma avec UDP

socket()

bind()
socket() socket()

autant de fois que nécessaire autant de fois que nécessaire

sendto() recvfrom() sendto()

recvfrom() sendto() recvfrom()

close() close()

close()

appelant appelé appelant

Développement 34
 Sockets - fonctions pour TCP
établissement de connexion
côté appelé
• int listen (int id_socket, int max_queue) pour signaler que l'utilisateur sera appelé
• int accept (int id_socket, struct sockaddr_in *appelant, int *lg_appelant)
pour recevoir un appel
côté appelant
• int connect (int id_socket, struct sockaddr_in *appelé, int lg_appelant)

transmission de données
sans données express
• int write (int id_socket, void *buf, int lg_buf)
• int read (int id_socket, void *buf, int lg_buf)
avec données express (flags peut contenir MSG_OOB)
• int send (int id_socket, void *buf, int lg_buf, int flags)
• int recv (int id_socket, void *buf, int lg_buf, int *flags)

terminaison ordonnée de connexion

pour chaque côté SHUT_RD interdit de recevoir
SHUT_WR interdit d'émettre
• int shutdown (int id_socket, int flags)
SHUT_RDWR interdit de recevoir et d'émettre

Développement 35
 Schéma avec TCP

socket()
bind()
listen()
socket() socket()

connect() accept() connect()

send() recv() send()

recv() send() recv()

shutdown() shutdown() shutdown()

close() close() close()

close()

appelant appelé appelant

Développement 36