diff --git a/common/inetdoc.urls.xml b/common/inetdoc.urls.xml
index 0258a1ef..2af10eaa 100644
--- a/common/inetdoc.urls.xml
+++ b/common/inetdoc.urls.xml
@@ -250,6 +250,9 @@
Initiation au développement C sur les sockets'>
+Code du programme udp-client.c'>
+
diff --git a/dev/Makefile b/dev/Makefile
index 91ab519a..643cee47 100644
--- a/dev/Makefile
+++ b/dev/Makefile
@@ -6,14 +6,16 @@ ABSTRACT_FILE = transform_output/abstract.xml
# Liste des répertoires à traiter à partir de ce niveau
SUBDIRS = \
- socket-c
+ socket-c \
+ socket-qt
# Type(s) de traitement
PROCESS = subdirs xml2xhtml xml2pdf
XML_FILES = \
biblio-dev.xml \
- socket-c/$(ABSTRACT_FILE)
+ socket-c/$(ABSTRACT_FILE) \
+ socket-qt/$(ABSTRACT_FILE)
all: $(PROCESS)
diff --git a/dev/biblio-dev.xml b/dev/biblio-dev.xml
index d3c8473d..49f02e82 100644
--- a/dev/biblio-dev.xml
+++ b/dev/biblio-dev.xml
@@ -3,6 +3,7 @@
"/usr/share/xml/docbook/schema/dtd/5.0/docbook.dtd"[
+
]>
@@ -19,6 +20,13 @@
&socket-c.abstract;
+
+
+
+ Les sockets en Langage C++ avec Qt
+ &socket-qt.abstract;
+
+
diff --git a/dev/socket-c/files/tcp-client.c b/dev/socket-c/files/tcp-client.c
index 90021f20..e75568c0 100644
--- a/dev/socket-c/files/tcp-client.c
+++ b/dev/socket-c/files/tcp-client.c
@@ -67,8 +67,8 @@ int main()
puts("\nEntrez quelques caractères au clavier.");
puts("Le serveur les modifiera et les renverra.");
puts("Pour sortir, entrez une ligne avec le caractère '.' uniquement.");
- puts("Si une ligne dépasse MAX_MSG caractères,");
- puts("seuls les MAX_MSG premiers caractères seront utilisés.\n");
+ puts("Si une ligne dépasse "xstr(MAX_MSG)" caractères,");
+ puts("seuls les "xstr(MAX_MSG)" premiers caractères seront utilisés.\n");
// Invite de commande pour l'utilisateur et lecture des caractères jusqu'à la
// limite MAX_MSG. Puis suppression du saut de ligne en mémoire tampon.
diff --git a/dev/socket-c/files/udp-client.c b/dev/socket-c/files/udp-client.c
index c50a58a3..d786d30c 100644
--- a/dev/socket-c/files/udp-client.c
+++ b/dev/socket-c/files/udp-client.c
@@ -61,8 +61,8 @@ int main()
puts("\nEntrez quelques caractères au clavier.");
puts("Le serveur les modifiera et les renverra.");
puts("Pour sortir, entrez une ligne avec le caractère '.' uniquement.");
- puts("Si une ligne dépasse MAX_MSG caractères,");
- puts("seuls les MAX_MSG premiers caractères seront utilisés.\n");
+ puts("Si une ligne dépasse "xstr(MAX_MSG)" caractères,");
+ puts("seuls les "xstr(MAX_MSG)" premiers caractères seront utilisés.\n");
// Invite de commande pour l'utilisateur et lecture des caractères jusqu'à la
// limite MAX_MSG. Puis suppression du saut de ligne en mémoire tampon.
diff --git a/dev/socket-c/socket-c.xml b/dev/socket-c/socket-c.xml
index c227519b..04920331 100644
--- a/dev/socket-c/socket-c.xml
+++ b/dev/socket-c/socket-c.xml
@@ -101,7 +101,7 @@
.
-
+ Instructions de compilationIl est possible de compiler les deux programmes
@@ -151,8 +151,8 @@ Entrez le numéro de port du serveur :
Entrez quelques caractères au clavier.
Le serveur les modifiera et les renverra.
Pour sortir, entrez une ligne avec le caractère '.' uniquement.
-Si une ligne dépasse MAX_MSG caractères,
-seuls les MAX_MSG premiers caractères seront utilisés.
+Si une ligne dépasse 100 caractères,
+seuls les 100 premiers caractères seront utilisés.
Saisie du message :
texte avec tabulation et espaces
@@ -790,8 +790,8 @@ Entrez le numéro de port du serveur :
Entrez quelques caractères au clavier.
Le serveur les modifiera et les renverra.
Pour sortir, entrez une ligne avec le caractère '.' uniquement.
-Si une ligne dépasse MAX_MSG caractères,
-seuls les MAX_MSG premiers caractères seront utilisés.
+Si une ligne dépasse 100 caractères,
+seuls les 100 premiers caractères seront utilisés.
Saisie du message :
message de test UDP
@@ -868,8 +868,8 @@ Entrez le numéro de port du serveur :
Entrez quelques caractères au clavier.
Le serveur les modifiera et les renverra.
Pour sortir, entrez une ligne avec le caractère '.' uniquement.
-Si une ligne dépasse MAX_MSG caractères,
-seuls les MAX_MSG premiers caractères seront utilisés.
+Si une ligne dépasse 100 caractères,
+seuls les 100 premiers caractères seront utilisés.
Saisie du message :
message de test TCP
diff --git a/dev/socket-qt/.gitignore b/dev/socket-qt/.gitignore
new file mode 100644
index 00000000..7d69c44e
--- /dev/null
+++ b/dev/socket-qt/.gitignore
@@ -0,0 +1,6 @@
+author.xml
+legal.xml
+inetdoc.urls.xml
+transform_output
+*.css
+*.html
diff --git a/dev/socket-qt/Makefile b/dev/socket-qt/Makefile
new file mode 100644
index 00000000..3cc6ed57
--- /dev/null
+++ b/dev/socket-qt/Makefile
@@ -0,0 +1,25 @@
+ifndef $(MAIN_DIR)
+MAIN_DIR = $(HOME)/inetdoc
+endif
+
+# Liste des répertoires à traiter à partir de ce niveau
+#SUBDIRS = \
+ files
+
+# Type(s) de traitement
+PROCESS = subdirs symlink xml2xhtml xml2pdf
+
+SYMLINKS = \
+ $(MAIN_DIR)/common/author.xml \
+ $(MAIN_DIR)/common/legal.xml \
+ $(MAIN_DIR)/common/inetdoc.urls.xml
+
+XML_FILES = \
+ socket-qt.xml \
+ author.xml \
+ legal.xml \
+ inetdoc.urls.xml
+
+all: $(PROCESS)
+
+include $(MAIN_DIR)/common/Makefile.Rules
diff --git a/dev/socket-qt/images/qt-architecture.png b/dev/socket-qt/images/qt-architecture.png
new file mode 100644
index 00000000..64461837
Binary files /dev/null and b/dev/socket-qt/images/qt-architecture.png differ
diff --git a/dev/socket-qt/images/qt-creator-nogui-udp-receiver.png b/dev/socket-qt/images/qt-creator-nogui-udp-receiver.png
new file mode 100644
index 00000000..d3e11182
Binary files /dev/null and b/dev/socket-qt/images/qt-creator-nogui-udp-receiver.png differ
diff --git a/dev/socket-qt/socket-qt.xml b/dev/socket-qt/socket-qt.xml
new file mode 100644
index 00000000..35e53bf7
--- /dev/null
+++ b/dev/socket-qt/socket-qt.xml
@@ -0,0 +1,805 @@
+
+
+
+
+
+%inetdoc_urls;
+
+]>
+
+
+
+
+ Initiation au développement Qt sur les sockets
+
+ &author;
+
+ Ce support est la suite de l'initiation au développement en Langage C
+ sur les sockets. L'objectif est à nouveau le même ; utiliser un code
+ minimaliste accessible aux débutants. Les bibliothèques Qt présentent un
+ grand intérêt lorsque l'on souhaite produire du code indépendant du système
+ d'exploitation sous-jacent. On aborde aussi la programmation orientée objet
+ avec ces bibliothèques.
+
+
+ GNU
+ Linux
+ inetdoc
+ socket
+ udp
+ tcp
+ client
+ serveur
+ qt
+ qtcreator
+
+
+
+
+ &legal;
+
+
+ Meta-information
+
+ Cet article est écrit avec DocBook XML
+ sur un système Debian
+ GNU/Linux. Il est disponible en version imprimable au
+ format PDF : __printbasename__.
+
+
+
+
+
+ Contexte de développement
+
+ Comme ce support est la suite de celui sur le Langage C, on reprend le
+ même découpage en deux programmes distincts : un serveur et un client. À la
+ différence du support précédent, on ne présente pas le code des deux
+ programmes. Dans le but de limiter le volume du document, on introduit
+ uniquement le code de la partie serveur qui reçoit le message, le traite et
+ le réexpédie au client. On peut très bien réutiliser le programme client déjà
+ développé en Langage C : &url.socket-c.udp-client;
+
+ Le principe d'illustration des communications réseau reste le même :
+ l'échange de chaînes de caractères. Le client émet un
+ message que le serveur traite et retransmet vers le
+ client. Le traitement est toujours aussi minimaliste ;
+ le serveur convertit la chaîne de caractères en
+ majuscules.
+
+
+ Bibliothèques Qt
+
+ Le diagramme ci-dessous présente l'architecture des bibliothèques Qt.
+ Il met en évidence l'indépendance entre les développements et les systèmes
+ d'exploitation cibles.
+
+
+
+
+
+
+
+
+
+ Architecture Qt - source qt.nokia.com
+
+
+
+ Dans notre contexte, on utilise le Langage C++ et l'environnement de
+ développement intégré Qt Creator. Cet environnement de
+ développement intègre les bibliothèques Qt réseau dont nous avons
+ besoin.
+
+ On se propose de développer le programme serveur en deux temps.
+
+
+
+ Une version sans graphisme mettant en évidence les appels de
+ bibliothèques propres à l'utilisation des
+ sockets.
+
+
+ Une version avec une fenêtre graphique dans laquelle on affiche les
+ messages reçus depuis un programme client ainsi que l'adresse
+ IP et le numéro de port utilisés par ce programme
+ client.
+
+
+
+
+
+ Instructions d'exécution
+
+ On exécute le programme client déjà développé en
+ Langage C dans un Shell alors que le programme
+ serveur est géré directement par l'environnement
+ Qt Creator. On peut exécuter ces deux programmes sur
+ le même hôte en utilisant l'interface de boucle locale pour les
+ communications réseau.
+
+
+
+ Le programme serveur
+ nogui-udp-receiver
+
+
+
+
+
+
+
+
+
+
+ Qt Creator - exécution du programme serveur
+
+
+
+
+ Déplacer le pointeur de la souris sur l'image, clicker sur le
+ bouton droit et lancer «Afficher l'image» pour lire les messages.
+
+
+ C'est dans la partie inférieure droite de la copie d'écran que l'on
+ retrouve en rouge les messages échangés entre les programmes
+ client et serveur. Le code
+ utilisé ici correspond à la version sans graphisme du programme
+ serveur.
+
+
+
+
+ Le programme client
+ udp-client.o
+
+$ ./udp-client.o
+Entrez le nom du serveur ou son adresse IP :
+127.0.0.1
+Entrez le numéro de port du serveur :
+8888
+
+Entrez quelques caractères au clavier.
+Le serveur les modifiera et les renverra.
+Pour sortir, entrez une ligne avec le caractère '.' uniquement.
+Si une ligne dépasse 100 caractères,
+seuls les 100 premiers caractères seront utilisés.
+
+Saisie du message :
+ texte de test avec tabulation et espaces
+Message traité : TEXTE DE TEST AVEC TABULATION ET ESPACES
+Saisie du message :
+_exit_
+Message traité : _EXIT_
+Saisie du message :
+serveur arrêté
+** Le serveur n'a répondu dans la seconde.
+Saisie du message :
+.
+
+
+
+
+ Lorsque le programme serveur est en cours
+ d'exécution, il est possible de visualiser la correspondance entre le
+ processus en cours d'exécution et le numéro de port en écoute à l'aide de la
+ commande netstat.
+
+$ netstat -aup | grep -e Proto -e 8888
+(Tous les processus ne peuvent être identifiés, les infos sur les processus
+non possédés ne seront pas affichées, vous devez être root pour les voir toutes.)
+Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
+udp 0 0 *:8888 *:* 3321/QtCreator_UDP
+
+ Dans l'exemple ci-dessus, le numéro de port 8888
+ apparaît dans la colonne et processus numéro
+ 3321 correspond bien au programme
+ QtCreator_UDP_receiver dans la colonne .
+
+
+
+ Bibliothèques utilisées
+
+ Les bibliothèques standards du Langage C utilisées par le programme
+ client sont présentées dans le document &url.socket-c;.
+ On ne s'intéresse ici qu'à l'utilisation de la «brique» réseau des
+ bibliothèques Qt.
+
+
+
+ libc6-dev
+ netdb.h
+
+ Opérations sur les bases de données réseau. Ici, c'est la fonction
+ gethostbyname() qui est utilisée. Elle renvoie une
+ structure de type hostent pour l'hôte
+ name. La chaîne name est
+ soit un nom d'hôte, soit une adresse IPv4, soit une
+ adresse IPv6. Pour obtenir plus d'informations, il
+ faut consulter les pages de manuels : man
+ gethostbyname.
+
+
+
+ libc6-dev
+ netinet/in.h
+
+ Famille du protocole Internet. Ici, plusieurs fonctions sont
+ utilisées à partir du paramètre de description de socket
+ sockaddr_in. Les quatre fonctions importantes
+ traitent de la conversion des nombres représentés suivant le format hôte
+ (octet le moins significatif en premier sur processeur Intel x86) ou
+ suivant le format défini dans les en-têtes réseau (octet le plus
+ significatif en premier). Ici le format hôte fait référence à
+ l'architecture du processeur utilisé. Cette architecture est dite
+ «petit-boutiste» pour les processeurs de marque
+ Intel majoritairement utilisés dans les
+ ordinateurs de type PC. À l'inverse, le format défini
+ dans les en-têtes réseau est dit «gros-boutiste». Cette définition
+ appelée Network Byte Order provient à la fois du
+ protocole IP et de la couche liaison du modèle
+ OSI.
+
+
+ htonl() et
+ htons() : conversion d'un entier long et d'un
+ entier court depuis la représentation hôte (octet le moins significatif
+ en premier ou Least Significant Byte First)
+ vers la représentation réseau standard (octet le plus significatif en
+ premier ou Most Significant Byte
+ First).
+
+
+ ntohl() et
+ ntohs() : fonctions opposées aux précédentes.
+ Conversion de la représentation réseau vers la représentation
+ hôte.
+
+
+
+
+
+ libstdc++6-dev
+ stdio.h
+
+ Opérations sur les flux d'entrées/sorties de base tels que l'écran
+ et le clavier. Ici, toutes les opérations de saisie de nom d'hôte,
+ d'adresse IP, de numéro de port ou de texte sont
+ gérées à l'aide des fonctions usuelles du langage C.
+
+ Les fonctions d'affichage sans formatage puts
+ et fputs ainsi que la fonction d'affichage avec
+ formatage printf sont utilisées de façon
+ classique.
+
+ En revanche, la saisie des chaînes de caractères à l'aide de la
+ fonction scanf est plus singulière. Comme le but des
+ communications réseau évaluées ici est d'échanger des chaînes de
+ caractères, il est nécessaire de transmettre ou recevoir des suites de
+ caractères comprenant aussi bien des espaces que des tabulations.
+
+ La syntaxe usuelle de saisie d'une chaîne de caractère est :
+
+scanf("%s", msg);
+
+ Si on se contente de cette syntaxe par défaut, la chaîne saisie est
+ transmise par le programme client mot par mot. En
+ conséquence, le traitement par le programme serveur
+ est aussi effectué mot par mot.
+
+ Pour transmettre une chaîne complète, on utilise une syntaxe du
+ type suivant :
+
+scanf(" %[^\n]%*c", msg);
+
+ Le caractère espace situé entre les guillemets de gauche et le
+ signe pourcentage a pour but d'éliminer les caractères '
+ ', '\t' et '\n' qui
+ subsisteraient dans la mémoire tampon du flux d'entrée standard
+ stdin avant la saisie de nouveaux caractères.
+
+ La syntaxe [^\n] précise que tous les caractères
+ différents du saut de ligne sont admis dans la saisie. On évite ainsi que
+ les caractères ' ' et '\t' soient
+ considérés comme délimiteurs.
+
+ L'ajout de %*c permet d'éliminer le
+ délimiteur '\n' et tout caractère situé après dans la
+ mémoire tampon du flux d'entrée standard.
+
+ Enfin, pour éviter tout débordement de la mémoire tampon du même
+ flux d'entrée standard, on limite le nombre maximum des caractères saisis
+ à la quantité de mémoire réservée pour stocker la chaîne de caractères.
+ La «constante» MAX_MSG définie via une directive de
+ préprocesseur est introduite dans la syntaxe de formatage de la saisie.
+ Pour cette manipulation, on fait appel à une fonction macro qui renvoie
+ la valeur de MAX_MSG comme nombre maximum de
+ caractères à saisir.
+
+ On obtient donc finalement le formatage de la saisie d'une chaîne
+ de caractères suivant :
+
+scanf(" %"xstr(MAX_MSG)"[^\n]%*c", msg);
+
+
+
+
+ D'une manière générale, toutes les fonctions sont documentées à l'aide
+ des pages de manuels Unix classiques. Soit on entre directement à la console
+ une commande du type : man inet_ntoa, soit on
+ utilise l'aide du gestionnaire graphique pour accéder aux mêmes informations
+ en saisissant une URL du type suivant à partir du
+ gestionnaire de fichiers : man:/inet_ntoa.
+
+
+
+ Choix du premier protocole de transport étudié
+
+ Au dessus du protocole de couche réseau IP, on doit
+ choisir entre deux protocoles de couche transport :
+ TCP ou UDP.
+
+ Dans l'ordre chronologique, le protocole TCP est le
+ premier protocole à avoir été développé. Il «porte la moitié» de la
+ philosophie du modèle Internet. Cette philosophie veut que la couche
+ transport soit le lieu de la fiabilisation des communications. Ce protocole
+ fonctionne donc en mode connecté et contient tout les outils nécessaires à
+ l'établissement, au maintien et à la libération de connexion. De plus, des
+ numéros de séquences garantissent l'intégrité de la transmission et le
+ fenêtrage de ces numéros de séquences assure un contrôle de flux. Tout ces
+ mécanismes ne sont pas évidents à appréhender pour un public débutant.
+
+ Le protocole UDP a été développé après
+ TCP. La philosophie de ce mode de transport suppose que le
+ réseau de communication est intrinsèquement fiable et qu'il n'est pas
+ nécessaire de garantir l'intégrité des transmissions et de contrôler les
+ flux. On dit que le protocole UDP n'est pas orienté
+ connexion ; ce qui a pour conséquence d'alléger considérablement les
+ mécanismes de transport.
+
+ L'objectif du présent document étant d'initier à l'utilisation des
+ sockets, on s'appuie dans un premier temps sur le protocole de transport le
+ plus simple : UDP. Les programmes «client» et
+ «serveur» sont repris dans un second temps en utilisant le protocole
+ TCP. En termes de développement, les différences de mise
+ en œuvre des sockets sont minimes. C'est à l'analyse réseau que la différence
+ se fait sachant que les mécanismes de fonctionnement des deux protocoles sont
+ très différents.
+
+ Pour plus d'informations, consulter le support .
+
+
+
+ Sockets & protocole de transport UDP
+
+ Le schéma ci-dessous présente les sous-programmes sélectionnés côté
+ client et côté serveur pour la mise en œuvre des sockets avec le protocole de
+ transport UDP.
+
+ Les appels de sous-programmes avec les passages de paramètres sont
+ détaillés dans les sections suivantes.
+
+
+
+ Serveur :
+
+
+
+
+
+
+
+
+
+
+
+ Socket et protocole UDP
+
+
+
+
+
+ Sockets & protocole de transport TCP
+
+ Le schéma ci-dessous présente les sous-programmes sélectionnés côté
+ client et côté serveur pour la mise en œuvre des sockets avec le protocole de
+ transport TCP.
+
+ Les appels de sous-programmes avec les passages de paramètres sont
+ détaillés dans les sections suivantes.
+
+
+
+ Serveur :
+
+
+
+
+
+
+
+
+
+
+
+ Socket et protocole TCP
+
+
+
+
+
+
+ Programme serveur UDP
+
+
+ Utilisation des sockets avec le serveur UDP
+
+ Au niveau du serveur, l'objectif est aussi
+ d'ouvrir un nouveau socket ; ce qui revient aussi à
+ ouvrir un canal de communication réseau avec la fonction
+ socket.
+
+
+ int listenSocket;
+
+<snipped/>
+listenSocket = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
+if (listenSocket < 0) {
+ fputs("Impossible de créer le socket en écoute", stderr);
+ exit(EXIT_FAILURE);
+ }
+
+ Cette étape ne présentant aucune différence avec le niveau client, on
+ relie le numéro de socket avec le numéro de port choisi.
+
+
+ int listenSocket;
+ struct sockaddr_in serverAddress;
+
+<snipped/>
+serverAddress.sin_family = PF_INET;
+serverAddress.sin_addr.s_addr = htonl(INADDR_ANY);
+serverAddress.sin_port = htons(listenPort);
+
+if (bind(listenSocket,
+ (struct sockaddr *) &serverAddress,
+ sizeof(serverAddress)) < 0) {
+ fputs("Impossible de lier le socket en écoute", stderr);
+ exit(EXIT_FAILURE);
+ }
+
+
+
+ spécifie que le programme est en écoute
+ sur toutes les adresses IP sources.
+
+
+ contient le résultat de l'appel de
+ la fonction socket ; le numéro du canal de
+ communication entre le programme et la pile des protocoles réseau.
+
+
+ et
+ correspondent à la structure de
+ désignation de l'adresse IP et du numéro de port du
+ serveur puis à la taille de cette structure.
+
+
+
+ Une fois la liaison en place, le programme attend les datagrammes
+ provenant du client.
+
+ int listenSocket;
+ struct sockaddr_in clientAddress;
+ char line[(MAX_MSG+1)];
+
+<snipped/>
+listen(listenSocket, 5);
+
+<snipped/>
+if (recvfrom(listenSocket, msg, MAX_MSG, 0,
+ (struct sockaddr *) &clientAddress,
+ &clientAddressLength) < 0) {
+ fputs("Problème de réception du messsage", stderr);
+ exit(EXIT_FAILURE);
+ }
+
+
+
+ La fonction listen «active» l'utilisation du
+ canal de communication initié avec la fonction
+ socket. Le second paramètre définit
+ le nombre maximal de demandes de «connexions» en attente.
+
+
+ Les paramètres et
+ correspondent au datagramme et à sa longueur.
+
+
+
+ Enfin, les émissions de datagramme du serveur vers le client utilisent
+ exactement les mêmes appels à la fonction sendto que les
+ émissions du client vers le serveur.
+
+
+
+ Code source complet
+
+ Code du programme udp-server.c :
+
+
+
+
+
+
+ Programme serveur TCP
+
+
+ Utilisation des sockets avec le serveur TCP
+
+ Comme dans le cas du programme client, le fait que le protocole
+ TCP soit un service orienté
+ connexion entraîne un changement important dans le code source du
+ programme serveur précédent. Le contrôle d'erreur est directement intégré
+ dans la couche transport.
+
+ Si le client fait appel à la fonction connect pour
+ demander l'établissement d'une connexion, le serveur fait appel à la fonction
+ accept pour recevoir les nouvelles demandes de
+ connexion.
+
+ int socketDescriptor;
+ struct sockaddr_in serverAddress;
+
+<snipped/>
+connectSocket = accept(listenSocket,
+ (struct sockaddr *) &clientAddress,
+ &clientAddressLength);
+
+if (connectSocket < 0) {
+ fputs("Impossible d'accepter une connexion", stderr);
+ close(listenSocket);
+ exit(EXIT_FAILURE);
+ }
+
+ En cas d'échec de l'ouverture du socket de réception des demandes
+ d'établissement de connexion, on abandonne le traitement.
+
+
+
+ Patch code source
+
+ Patch du programme tcp-server.c :
+
+
+
+
+
+
+ Analyse réseau avec Wireshark
+
+ L'analyse réseau présente un grand intérêt dans la validation des
+ développements. Elle permet de contrôler le bon fonctionnement des
+ communications suivant les jeux de protocoles utilisés. Ici, on peut
+ différencier le fonctionnement des deux protocoles de la couche transport en
+ analysant les échanges entre les deux programmes client
+ et serveur.
+
+ L'utilisation de l'analyseur wireshark est
+ présentée dans le support &url.intro.analyse;.
+
+ Les analyses présentées ci-après ont été réalisées dans les conditions
+ suivantes :
+
+
+
+ Le programme serveur est exécuté sur l'hôte
+ ayant l'adresse IP 192.200.0.1. Ce programme est toujours en
+ écoute sur le port 4000.
+
+
+ Le programme client est exécuté sur l'hôte ayant
+ l'adresse IP 192.200.0.30.
+
+
+
+ Voici deux captures réseau d'échange de datagramme entre un client avec
+ l'adresse IP 192.168.1.1 et un serveur avec l'adresse
+ IP 192.168.1.101. Le serveur est en
+ écoute sur le port 4000.
+
+
+ Analyse avec le protocole UDP
+
+ Avant de passer à l'analyse, voici les copies d'écran de l'exécution
+ des programmes.
+
+
+
+ Côté serveur :
+
+$ ./udp-server.o
+Entrez le numéro de port utilisé en écoute (entre 1500 et 65000) :
+4000
+Attente de requête sur le port 4000
+>> depuis 192.200.0.30:45686
+ Message reçu : message de test UDP
+^C
+
+
+ Côté client :
+
+$ ./udp-client.o
+Entrez le nom du serveur ou son adresse IP :
+192.200.0.1
+Entrez le numéro de port du serveur :
+4000
+
+Entrez quelques caractères au clavier.
+Le serveur les modifiera et les renverra.
+Pour sortir, entrez une ligne avec le caractère '.' uniquement.
+Si une ligne dépasse MAX_MSG caractères,
+seuls les MAX_MSG premiers caractères seront utilisés.
+
+Saisie du message :
+ message de test UDP
+Message traité : MESSAGE DE TEST UDP
+Saisie du message :
+.
+
+
+
+ Dans la copie d'écran ci-dessous, on retrouve l'ensemble des éléments
+ énoncés auparavant.
+
+
+
+ Chaîne de caractères traitée dans la partie données de la couche
+ application.
+
+
+ Numéros de ports utilisés dans les en-têtes de la couche transport.
+
+
+ Adresses IP utilisées dans les en-têtes de la
+ couche réseau.
+
+
+
+
+
+
+
+
+
+
+
+ Wireshark et protocole UDP
+
+
+
+ Enfin, le fait que la capture se limite à deux échanges illustre la
+ principale caractéristique du protocole UDP : un service
+ de datagramme non orienté connexion qui suppose un réseau sous-jacent fiable
+ et sans erreur.
+
+
+
+ Analyse avec le protocole TCP
+
+ Comme dans le cas précédent, voici les copies d'écran de l'exécution
+ des programmes avant de passer à l'analyse réseau.
+
+
+
+ Côté serveur :
+
+$ ./tcp-server.o
+Entrez le numéro de port utilisé en écoute (entre 1500 et 65000) :
+4000
+Attente de connexion TCP sur le port 4000
+>> connecté à 192.200.0.30:59490
+ -- message de test TCP
+ -- nouveau message avant clôture de la connexion
+Attente de connexion TCP sur le port 4000
+^C
+
+
+ Côté client :
+
+$ ./tcp-client.o
+Entrez le nom du serveur ou son adresse IP :
+192.200.0.1
+Entrez le numéro de port du serveur :
+4000
+
+Entrez quelques caractères au clavier.
+Le serveur les modifiera et les renverra.
+Pour sortir, entrez une ligne avec le caractère '.' uniquement.
+Si une ligne dépasse MAX_MSG caractères,
+seuls les MAX_MSG premiers caractères seront utilisés.
+
+Saisie du message :
+message de test TCP
+Message traité : MESSAGE DE TEST TCP
+Saisie du message :
+nouveau message avant clôture de la connexion
+Message traité : NOUVEAU MESSAGE AVANT CLôTURE DE LA CONNEXION
+Saisie du message :
+.
+
+
+
+ Dans la copie d'écran ci-dessous, on retrouve l'ensemble des éléments
+ déjà connus : chaîne de caractères traitée, numéros de port en couche
+ transport et adresses IP en couche réseau.
+
+
+
+
+
+
+
+
+
+ Wireshark et protocole TCP
+
+
+
+ Cette copie d'écran se distingue de la précédente, par le nombre de
+ trames capturées alors que le traitement effectué est quasiment le même. La
+ capture réseau fait apparaître les phases d'établissement, de maintien et de
+ libération d'une connexion. On illustre ainsi toutes les fonctions de
+ fiabilisation apportées par le protocole TCP.
+
+ À partir de ces quelques trames, on peut reprendre l'analyse de la
+ poignée de main à trois voies, de l'évolution des numéros de séquence et de
+ l'évolution de la fenêtre d'acquittement.
+
+
+
+
+ Documents de référence
+
+
+
+ Modélisations réseau
+
+ &url.modelisations; : présentation et comparaison des
+ modélisations OSI et Internet.
+
+
+
+
+ Adressage IPv4
+
+ &url.adressage.ipv4; : support complet sur l'adressage du
+ protocole de couche réseau de l'Internet
+ (IP).
+
+
+
+
+ Configuration d'une interface réseau
+
+ &url.config.interface.lan; : support sur la configuration des
+ interfaces réseau. Il permet notamment de relever les adresses
+ IP des hôtes en communication.
+
+
+
+
+