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 compilation Il 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. + + + + +