1 Programmation Client/Serveur basée sur TCP/IP

Outils Informatique pour l’ingénieur
TD 1
Réseau et Web
IP, Client/serveur
1 Programmation Client/Serveur basée sur TCP/IP
1.1 Buts de cette réalisation
Ce TP sur la programmation client/serveur a pour but :
• l’étude du fonctionnement d’une application de type client/serveur,
• la mise en œuvre d’un protocole de communication basé sur TCP/IP.
1.2 Quelques explications sur la programmation d’une application de type
client/serveur
L’architecture de type client/serveur est l’une des architectures
logicielles les plus utilisées pour faire communiquer des ordinateurs distants à
travers un réseau. Il s’agit de définir un ordinateur comme étant le serveur,
c’est à dire qu’il est à l’écoute des requêtes d’un ou plusieurs ordinateurs appelés
clients.
Afin de faire communiquer deux machines, il faut d’une part qu’elles soient
connectées via un réseau, et d’autre part qu’elles utilisent un protocole commun.
Nous utiliserons dans le cadre de ce TP le protocole de communication TCP/IP,
qui est le plus utilisé dans le monde (notamment par internet), et nous définirons
un protocole application qui permettra au serveur et aux clients de communiquer.
1.3 Définition de l’application
Un serveur mesure des températures et les envoie sur demande aux
clients.
Le serveur se met à l’écoute du port 12512, que nous choisissons
arbitrairement (la règle générale est d’éviter les ports de numéro faible pouvant
être réservés à des applications standards telles http sur le port 80, le mail sur
le port 25,…). Il est alors prêt à recevoir une connexion. Dès qu’un client se
connecte à ce port, le serveur lui envoie une ligne de texte, terminée par un
retour chariot
, afin de s’identifier. Par exemple il peut envoyer « Mon
protocole v1.0 ». Le client sait alors que le serveur est prêt et qu’ils vont pouvoir
dialoguer suivant le protocole établi.
Le serveur, de son côté, se met à l’écoute des ordres du client : s’il reçoit
la ligne de texte « read
» (dans le protocole choisi, les informations circulent
sous la forme de lignes de textes se terminant par un retour chariot
), il
envoie sa dernière mesure de température (après l’avoir transformée de nombre
flottant en texte), puis il se met à nouveau en attente. S’il ne reçoit pas de
commande pendant 2 secondes, ou bien s’il reçoit autre chose que « read
», il
ferme la connexion et se retrouve de nouveau en attente sur le port 12512.
L’application client, quant à elle, permet à l’utilisateur de saisir l’adresse
d’un serveur, et lui demande un relevé de température toutes les 50
millisecondes. Il affiche alors les températures reçues dans un graphe. Lorsque
l’utilisateur souhaite arrêter les mesures, le client envoie la ligne « quit
» au
serveur. D’après le protocole, le serveur fermera alors lui aussi sa connexion car
la ligne est différente de « read
».
:
• Programmer le serveur : sa fonction est d’écouter le port 12512,
puis d’écrire la ligne « Mon protocole v1.0
» dès qu’il reçoit une
demande de connexion. Attention, le protocole est sensible à la
casse (majuscules/minuscules).
Puis, en boucle, il lit le port TCP :
• Si l’ordre « read
» lui est envoyé, alors il envoie au client une
mesure de température terminée par
.
• Si il attend 2 secondes sans ordre ou bien s’il reçoit autre chose
que « read
», il sort de la boucle.
• La boucle se termine si il reçoit autre chose que « read
», si il y
a une erreur TCP, si le serveur attend 2 secondes, ou bien si
l’utilisateur appuie sur un bouton stop. A la fin de la boucle, le
serveur ferme la connexion et se retrouve à nouveau en attente sur
le port 12512
• La face avant de ce VI est donnée ci-dessous :
Indicateur
Figure 4.1: Face avant du serveur
:
• Programmer le client : sa fonction est de se connecter sur le port
12512 du serveur choisi par l’utilisateur. Après avoir vérifié qu’il se
trouve bien en communication avec un serveur du protocole désiré
(lecture de la ligne « Mon protocole v1.0
»), il envoie la commande
« read
» toutes les 50 millisecondes.
• Lorsque l’utilisateur clique sur un bouton « Fermer la connexion », le
client envoie le texte « quit
» au serveur et ferme la connexion.
• La boucle du client se termine donc sur erreur TCP ou sur l’appuie
du bouton stop.
• La face avant de ce VI est donnée ci-dessous :
Commande
Figure 4.2: Face avant du client
:
Graphe déroulant
• Lorsque tout fonctionne, réfléchir à la gestion des erreurs qui
peuvent être nombreuses (fermeture intempestive de la connexion,
mauvais protocole, client ou serveur bogué,…) et y proposer des
solutions : délai maximal d’attente, gestion de la variable status de la
sortie erreur des vi gérant TCP.
• Parallèlement à cela, tester son client avec le serveur du binôme
voisin, et vice-versa.
1.4 Quelques vi utiles
Gestion des erreurs
• Les erreurs sont présentées sous la forme
d’un
cluster
(équivalent
d’un
type
enregistrement ou record en Ada) composé
d’un booléen vrai si il y a une erreur, d’un code
d’erreur, et d’un texte. Afin de savoir si une
erreur a eu lieu, il suffit donc de tester le
champs status du cluster d’erreur. Pour
accéder à ce champs, on utilise le vi
Désassembler par nom du menu Cluster.
TCP Créer un auditeur
Menu : Communication
9 TCP
TCP
Attendre
auditeur
• Prépare le programme à se mettre en
attente de connexion sur le port spécifié:
- port : numéro du port à préparer
- ID de l’auditeur: identificateur de
l’auditeur utilisé par le vi d’écoute TCP
- adresse à distance : adresse de la
machine ayant demandé la connexion
- sortie d’erreur : cluster contenant des
informations sur le fonctionnement du vi. Si
il y a eu une erreur, son composant Status
vaut vrai en sortie, faux sinon.
un
Menu : Communication
9 TCP
• Se met en attente d’une connexion sur le
port de l’auditeur :
- ID d’auditeur d’entrée : identificateur de
l’auditeur sur lequel se mettre en attente
- résoudre l’adresse à distance : si vrai, le
vi utilise un DNS pour tenter d’obtenir
l’adresse alphanumérique du client, si faux,
c’est l’adresse IP du client qui figure dans
l’adresse à distance.
- timeout (-1) : ce vi provoquant une
attente potentiellement infinie (si absence
de demande de connexion), il est possible de
borner l’attente dans le temps
- ID de connexion: identificateur de
connexion utilisé par les autres vi utilisant
TCP.
- adresse à distance : adresse de la
machine ayant demandé la connexion
- sortie d’erreur : cluster contenant des
informations sur le fonctionnement du vi. Si
il y a eu une erreur, son composant Status
vaut vrai en sortie, faux sinon.
Ouverture
d’une
connexion sur un port
TCP distant
Menu : Communication
9 TCP
• Ouvre une connexion TCP sur le port spécifié
du serveur spécifié:
- adresse : adresse du serveur
- port : port du serveur sur lequel se
connecter
- timeout : idem TCP Attendre un auditeur
- id de connexion : identificateur de la
connexion créée utilisé par les autres vi TCP
- sortie d’erreur : idem TCP listen
Lecture sur un port TCP
ouvert
Menu : Communication
9 TCP
Utilisation typique en mode
CRLF
Ecriture sur
TCP ouvert
un
port
Menu : Communication
9 TCP
Utilisation typique en mode
CRLF
Fermeture
connexion TCP
• Tente de lire sur une connexion TCP:
- id de connexion : identificateur de la
connexion (provient de TCP Listen ou de TCP
Open Connexion)
- octets à lire : choisir 1024. Nombre
d’octets que le vi cherche à lire, si on ne
met rien, ce vi ne lit rien !!!
- timeout (-1) : idem TCP Listen
- mode (standard) : choisir le mode CRLF.
En mode CRLF, lit une ligne jusqu’au
prochain retour chariot
- id de connexion de sortie : identificateur
de connexion à utiliser pour des opérations
ultérieures sur la connexion, possède la
même valeur que id de connexion.
- sortie de données : chaîne de caractères
lue (attention, en mode CRLF, elle se
termine normalement par
)
- sortie d’erreur : idem TCP Listen
d’une
• Tente d’écrire sur une connexion TCP:
Les entrées/sorties de ce vi sont similaires
à TCP read.
- entrée de données : chaîne de caractère
à envoyer. Attention, si l’on a choisi le mode
CRLF, il faut penser à insérer un retour
chariot
à la fin.
Menu : Communication
9 TCP
• Ferme une connexion TCP:
- id de connexion : identificateur de la
connexion
Conversion d’une chaîne
en réel
Menu : Chaînes
9 Conversions chaînenombre
chaîne
:
chaîne
de
caractères
représentant un nombre au format ingénieur
- nombre : nombre résultant de la
conversion de chaîne
Conversion d’un réel en
chaîne
Menu : Chaînes
9 Conversions chaînenombre
Concaténation
chaînes
Menu : Chaînes
Fonction inverse de formatage
- nombre : réel à convertir
- chaîne au format ingénieur : chaîne de
caractères image du réel en entrée
de
Concatène (met bout à bout) des chaînes de
caractères. Ce vi est dimensionnable
(comme assembler un tableau)
Le calcul de la température sera fictif et basé sur un vi de simulation :
Menu Tutorial
Thermomètre numérique.vi
2 Adressage IP et masque de sous-réseau
Un site local est composé de deux sous-réseaux physiques, reliés au reste du monde via
une même passerelle. Ce site possède une unique adresse IP : 189.44.0.0.
Quelle est la classe de cette adresse ?
Proposez, en utilisant la notion de masque de sous-réseau, un mode d’adressage des
différentes stations sur le site pour que la passerelle n’ait pas à diffuser
systématiquement sur chacun des deux sous-réseaux tous les messages reçus du reste
du monde.
Proposez un mode d’adressage de l’IMP jouant le rôle de passerelle.