WEBVTT 00:05.510 --> 00:07.130 Bienvenue à tous. 00:07.280 --> 00:12.320 Nous allons maintenant aborder les étapes de la mise en œuvre d'un client TCP. 00:12.650 --> 00:19.370 Vous pouvez donc voir que vous devez mettre en œuvre les huit étapes suivantes afin d'implémenter un programme client 00:19.370 --> 00:20.060 TCP. 00:22.120 --> 00:29.140 La mise en œuvre d'un client TCP est donc beaucoup plus simple que celle d'un serveur TCP. 00:29.260 --> 00:35.860 Nous ferons une promenade dans le code et nous couvrirons toutes les étapes de l'implémentation d'un client TCP. 00:36.880 --> 00:42.130 Les huit étapes suivantes comprennent donc l'initialisation des variables. 00:42.430 --> 00:44.740 Indiquez ensuite les informations d'identification du serveur. 00:44.740 --> 00:50.890 En d'autres termes, le programme client doit connaître l'adresse IP et le numéro de port du serveur afin de se 00:50.890 --> 00:57.730 connecter au processus serveur, car l'adresse IP identifie de manière unique la machine serveur, qui peut se trouver n'importe 00:57.730 --> 01:05.920 où sur le réseau, et le numéro de port TCP permet d'identifier de manière unique un processus serveur s'exécutant sur cette machine. 01:06.730 --> 01:07.330 C'est vrai. 01:07.330 --> 01:14.200 Ainsi, une fois que le client TCP sait quelle machine serveur il doit connecter avec le client TCP, il crée 01:14.200 --> 01:16.120 un socket de communication. 01:16.270 --> 01:21.290 C'est à l'aide de ce socket que la machine cliente effectue tous les échanges de données avec le serveur. 01:21.950 --> 01:28.700 Lors de la quatrième étape, le client, après avoir créé un socket, envoie la demande d'établissement de la connexion 01:28.700 --> 01:29.750 au serveur. 01:30.050 --> 01:30.740 C'est vrai. 01:30.740 --> 01:35.630 Ainsi, après la quatrième étape, la connexion entre le client et le serveur est entièrement établie. 01:37.160 --> 01:45.770 Ensuite, dans les cinquième et sixième étapes, le client TCP peut échanger ses données avec le serveur TCP et, une fois que le 01:45.770 --> 01:53.210 client a terminé toutes sortes d'échanges de données avec le serveur, le client TCP peut choisir de fermer la 01:53.210 --> 02:00.170 connexion et, dans le cas contraire, le client TCP veut communiquer avec le serveur et souhaite échanger 02:00.170 --> 02:03.680 davantage de données avec le serveur TCP. 02:03.710 --> 02:08.360 Ensuite, à partir de l'étape huit, le client TCP peut passer directement à l'étape cinq. 02:09.400 --> 02:10.060 C'est vrai. 02:10.060 --> 02:13.030 Il s'agit donc d'une machine à états très simple pour un client TCP. 02:13.060 --> 02:19.570 Nous allons parcourir le code et voir comment ces huit étapes sont mises en œuvre dans un programme client TCP. 02:20.440 --> 02:23.290 Passons donc en revue ces étapes une à une. 02:24.850 --> 02:30.160 La fonctionnalité du client TCP est donc mise en œuvre dans le fichier TCP client dot C. 02:30.340 --> 02:37.240 Je vous communiquerai le chemin d'accès à ce fichier afin que vous puissiez le télécharger et l'exécuter sur votre machine. 02:38.140 --> 02:42.040 Je vais donc partager ce code dans la section des ressources. 02:43.310 --> 02:45.680 Passons donc en revue ce dossier. 02:46.550 --> 02:48.800 Commençons donc par la fonction principale. 02:48.890 --> 02:55.270 Ainsi, toute la fonctionnalité du client TCP est mise en œuvre dans la fonction de configuration de la communication TCP. 02:55.280 --> 02:59.420 Entrons donc dans cette fonction et voyons ce que nous y avons implémenté. 03:02.160 --> 03:08.730 Nous avons donc pris une variable locale dans cette fonction que nous utiliserons pour implémenter un programme 03:08.730 --> 03:09.450 client TCP. 03:10.110 --> 03:10.650 C'est vrai. 03:10.650 --> 03:15.030 Nous discuterons donc de l'utilisation de ces variables lorsque nous les utiliserons réellement. 03:15.630 --> 03:16.350 C'est vrai. 03:16.530 --> 03:21.480 Ce LAN contient une valeur constante, qui n'est rien, mais qui correspond à la taille de la structure socket. 03:21.480 --> 03:23.670 DDR Droit, Droit. 03:23.670 --> 03:27.270 Nous n'avons donc rien à discuter dans la phase d'initialisation. 03:27.990 --> 03:31.590 La deuxième étape consiste à spécifier les informations d'identification du serveur. 03:31.590 --> 03:35.580 En d'autres termes, le client TCP doit savoir à quel serveur il souhaite se connecter. 03:35.610 --> 03:39.990 Les informations d'identification comprennent donc l'adresse IP du serveur TCP et le numéro de port. 03:41.130 --> 03:48.150 Vous pouvez donc voir que pour enregistrer l'adresse IP du serveur et le numéro de port, nous avons pris la variable 03:48.150 --> 03:53.940 de type struct sockaddrin, qui est la structure C standard fournie par les API C, bien sûr. 03:54.630 --> 03:55.380 C'est vrai. 03:55.380 --> 04:01.260 À l'intérieur de cette structure, nous spécifierons les informations d'identification du serveur. 04:02.250 --> 04:04.950 Nous devons donc remplir les trois membres de cette structure. 04:04.980 --> 04:07.050 Le premier membre est la famille Syn. 04:07.290 --> 04:14.610 C'est le type de famille d'adresses que nous utiliserons puisque nous mettons en œuvre les sockets IPv4. 04:14.610 --> 04:17.490 Par conséquent, vous devez passer ici un inet f underscore. 04:17.970 --> 04:18.720 C'est vrai ? 04:18.750 --> 04:24.900 Si vous utilisez des sockets ipv6, vous auriez dû passer un f underscore inet six. 04:25.980 --> 04:29.580 La prochaine chose que vous devez spécifier est le numéro de port du serveur. 04:30.120 --> 04:34.020 Le port n'est donc rien, mais c'est le numéro de port du serveur. 04:34.320 --> 04:40.200 Vous pouvez donc voir que le port de destination a été initialisé à la valeur 2000. 04:43.530 --> 04:44.160 C'est vrai. 04:44.160 --> 04:49.620 Nous avons donc spécifié le numéro de port du serveur et la prochaine chose que nous devons spécifier est l'adresse 04:49.620 --> 04:50.580 IP du serveur. 04:50.910 --> 04:57.210 Les deux lignes suivantes, c'est-à-dire les lignes 40 et 41, sont utilisées pour spécifier l'adresse 04:57.210 --> 04:58.260 IP du serveur. 04:58.950 --> 05:00.480 Donc l'adresse IP du serveur. 05:00.480 --> 05:04.290 Dans ce cas, nous avons pris 127 . 0. 0. 1. 05:04.710 --> 05:07.710 Il s'agit donc d'une adresse IP spéciale. 05:08.400 --> 05:10.290 Il s'agit de l'adresse IP d'une machine actuelle. 05:11.410 --> 05:13.840 sur lequel vous allez exécuter ce programme. 05:14.530 --> 05:15.160 C'est vrai. 05:15.160 --> 05:19.450 En fait, votre serveur fonctionnera sur la base d'une adresse IP. 05:19.450 --> 05:26.320 127. 0. 0. 1 et votre programme client se connectera au serveur sur cette adresse IP. 05:26.470 --> 05:32.380 En fait, les programmes du serveur et du client s'exécutent sur la même machine. 05:33.590 --> 05:34.100 C'est vrai. 05:34.340 --> 05:40.310 Vous pouvez exécuter les programmes client et serveur dans des terminaux distincts sur votre machine virtuelle. 05:41.240 --> 05:45.260 Pour cela, vous devez faire fonctionner le serveur avec une adresse IP. 05:45.260 --> 05:47.630 127 . 0. 0. 1. 05:48.680 --> 05:49.400 C'est vrai. 05:50.060 --> 05:54.770 Vous pouvez donc voir que nous avons spécifié le numéro de port du serveur ainsi que l'adresse IP du serveur. 05:55.010 --> 05:58.910 Vous devez utiliser cette API pour obtenir le . 05:59.450 --> 06:03.890 Pour spécifier l'adresse IP du serveur telle qu'elle est. 06:03.890 --> 06:04.460 C'est vrai. 06:06.990 --> 06:14.010 Ainsi, les décès dans l'ADR stockent finalement l'adresse IP du serveur dans un format entier. 06:16.120 --> 06:19.650 L'étape suivante consiste à créer un socket de communication. 06:19.660 --> 06:25.000 Notre client doit donc maintenant créer un socket de communication afin de pouvoir communiquer 06:25.000 --> 06:25.960 avec le serveur. 06:26.050 --> 06:30.900 Pour créer un descripteur de fichier de socket de communication, il faut donc utiliser un système de socket et appeler. 06:30.910 --> 06:33.940 Le premier argument à transmettre est la famille d'adresses. 06:33.940 --> 06:41.170 Et comme nous créons un client TCP, les deuxième et troisième arguments doivent être socket stream 06:41.170 --> 06:42.730 et IP proto TCP. 06:44.660 --> 06:50.090 Le deuxième argument identifie le type de socket que vous créez. 06:50.090 --> 06:52.220 Vous créez donc une socket TCP. 06:52.220 --> 06:58.970 Spécifiez donc le flux de socket et le protocole de couche de transport que vous essayez d'utiliser est le protocole 06:58.970 --> 06:59.690 TCP. 06:59.690 --> 07:03.950 L'identifiant du protocole TCP est donc IP, proto TCP. 07:04.370 --> 07:10.490 Il s'agit donc de constantes fournies par les API du réseau. 07:11.890 --> 07:15.940 Ensuite, dans la quatrième étape, vous devez vous connecter au serveur. 07:16.480 --> 07:17.050 C'est vrai. 07:17.050 --> 07:24.700 En effet, notre client TCP a créé un socket et peut maintenant envoyer une demande de connexion. 07:24.700 --> 07:27.760 Il s'agit de la demande d'établissement de la connexion au serveur. 07:28.090 --> 07:34.120 En effet, notre serveur connaît maintenant l'adresse IP et le numéro de port du serveur auquel il veut se 07:34.120 --> 07:34.900 connecter. 07:37.250 --> 07:43.850 L'étape suivante n'est donc rien d'autre que l'envoi par notre client TCP d'une demande d'établissement de connexion au serveur à 07:43.850 --> 07:45.710 l'aide de l'appel système connect. 07:46.610 --> 07:51.140 Vous pouvez voir que dans l'appel système connect, le premier argument est le descripteur de fichier de la socket, 07:51.140 --> 07:52.760 qui a été créé à l'étape précédente. 07:53.000 --> 07:58.760 Le deuxième argument contient les informations d'identification du serveur auquel le client veut se connecter. 07:58.760 --> 08:01.490 Il s'agit de l'adresse IP et du numéro de port. 08:01.580 --> 08:07.550 Le troisième argument est une constante qui représente la taille de la structure struct socket. 08:09.390 --> 08:09.990 C'est vrai. 08:09.990 --> 08:17.820 Ainsi, après l'invocation de l'appel système Connect, la connexion entre le client TCP et le serveur TCP 08:17.820 --> 08:18.960 a été établie. 08:18.990 --> 08:23.520 Notre client est maintenant en mesure d'échanger des données avec le serveur TCP. 08:24.780 --> 08:31.950 Vous pouvez donc voir qu'à l'étape cinq, notre client TCP peut envoyer des données au serveur et à l'étape six. 08:31.980 --> 08:35.820 Notre client TCP peut effectivement recevoir les données du serveur. 08:37.380 --> 08:45.060 À l'étape suivante, le client TCP invite l'utilisateur à saisir les valeurs de A et de B. Ces valeurs 08:45.060 --> 08:52.320 servent donc de données au client TCP, qui les envoie au serveur pour traitement. 08:53.520 --> 08:54.120 C'est vrai. 08:54.900 --> 09:02.310 Ainsi, une fois que l'utilisateur a saisi la valeur de A et B, le client TCP utilise l'appel système "send to" pour envoyer 09:02.310 --> 09:05.610 les données au serveur en vue de leur traitement. 09:05.940 --> 09:08.790 Vous pouvez donc voir cela dans l'appel au système "send to". 09:08.790 --> 09:14.760 Le premier argument est le descripteur de fichier de communication, que le client TCP a créé à l'aide de l'appel 09:14.760 --> 09:15.660 système socket. 09:15.660 --> 09:21.030 Et le deuxième argument est la structure qui porte la valeur de A et B. 09:21.330 --> 09:25.860 Le troisième argument est la taille des données que vous envoyez au serveur. 09:26.220 --> 09:29.310 Le quatrième argument peut toujours être considéré comme nul. 09:30.120 --> 09:33.270 Le cinquième argument est l'identifiant du serveur. 09:33.300 --> 09:37.890 Il s'agit de l'identité du serveur auquel le client essaie d'envoyer les données. 09:38.520 --> 09:39.210 C'est vrai. 09:39.210 --> 09:45.750 Et le dernier argument n'est rien mais c'est la valeur constante qui est la taille de la structure socket. 09:46.140 --> 09:53.550 Vous pouvez donc voir que le client TCP a envoyé les données au serveur TCP en utilisant l'appel système send to. La valeur 09:53.550 --> 09:59.350 de retour de l'appel système send to est en fait le nombre d'octets que le client TCP a envoyé au 09:59.350 --> 10:00.070 serveur. 10:00.820 --> 10:02.110 En ce moment même. 10:02.110 --> 10:08.830 Après avoir envoyé les données au serveur, le client TCP doit attendre la réponse du serveur. 10:08.830 --> 10:15.610 Pour ce faire, le client TCP invoque l'appel système "Recevoir de" et se souvient que l'appel système "Recevoir de" est un appel 10:15.610 --> 10:22.990 système bloquant, ce qui signifie que le programme client ne s'exécutera pas au-delà de ce point jusqu'à ce que les données arrivent sur 10:22.990 --> 10:25.300 la socket en provenance du serveur. 10:25.780 --> 10:34.600 Le client TCP se bloque donc ici et restera bloqué jusqu'à ce que les données du serveur TCP arrivent. 10:34.600 --> 10:38.740 C'est-à-dire que la réponse du serveur TCP est reçue. 10:40.550 --> 10:42.710 Vous pouvez donc voir dans la réception de l'appel système. 10:42.710 --> 10:48.440 Le deuxième argument est la mémoire tampon dans laquelle la réponse reçue du serveur 10:48.440 --> 10:49.790 sera copiée. 10:51.110 --> 10:52.910 Et qui copiera cette réponse ? 10:52.940 --> 10:59.750 La couche transport est chargée de copier la réponse du serveur dans ce tampon. 11:02.380 --> 11:03.070 C'est vrai. 11:03.070 --> 11:08.470 La valeur de retour de l'appel système receive from est donc à nouveau le nombre d'octets reçus 11:08.470 --> 11:09.190 du serveur. 11:09.490 --> 11:14.190 Et dans la dernière, nous imprimons simplement la valeur reçue du serveur. 11:14.200 --> 11:19.870 Souvenez-vous donc que la fonction de notre serveur TCP était de recevoir la valeur de A et B du client. 11:19.900 --> 11:24.670 Additionner ces deux valeurs et renvoyer la somme de ces deux valeurs au client. 11:25.150 --> 11:30.640 Ici, nous imprimons simplement le résultat reçu du serveur Dhcp, qui est 11:30.640 --> 11:39.040 l'addition des valeurs A et B, et après cela, notre client TCP veut continuer à communiquer avec le serveur TCP. 11:39.040 --> 11:43.690 En d'autres termes, il souhaite envoyer deux autres valeurs de A et B au serveur. 11:43.690 --> 11:49.930 Pour cela, notre client TCP entre dans la boucle en utilisant l'appel système "go to". 11:49.930 --> 11:55.150 Vous êtes libre d'implémenter cette boucle en utilisant une boucle for ou while ou n'importe quelle autre méthode. 11:55.660 --> 12:02.200 Ainsi, le client TCP demande à nouveau deux valeurs à l'utilisateur et, après avoir obtenu ces deux valeurs, le client 12:02.300 --> 12:08.480 TCP utilise l'appel système "send to" et envoie à nouveau ces deux valeurs au serveur, qui les reçoit. 12:08.480 --> 12:13.730 Ces deux valeurs calculent le résultat et le renvoient au client TCP. 12:13.820 --> 12:17.600 Le client TCP reçoit la réponse à l'aide de l'appel système "receive from". 12:17.600 --> 12:24.020 Le client TCP revient à la charge et demande à nouveau à l'utilisateur de fournir deux autres valeurs, et ainsi de suite. 12:25.100 --> 12:31.310 Vous pouvez donc constater que les étapes de la mise en œuvre d'un client TCP sont relativement simples. 12:33.970 --> 12:35.850 Dans le client TCP. 12:35.860 --> 12:42.520 Vous remarquez que nous n'avons spécifié nulle part le numéro de port TCP à utiliser par le client TCP. 12:42.670 --> 12:43.810 C'est donc le cas. 12:45.940 --> 12:49.480 Il n'y a donc pas d'attribution de numéro de port par le programmeur. 12:50.410 --> 12:57.400 Souvenez-vous, lorsque nous avons créé le serveur TCP, l'utilisateur qu'est le programmeur a dû spécifier explicitement 12:57.400 --> 13:01.110 le numéro de port sur lequel le serveur TCP est censé écouter. 13:01.120 --> 13:04.000 Mais ce n'est pas le cas pour le client TCP. 13:04.600 --> 13:12.820 La raison en est que le client TCP, lorsqu'il envoie l'appel système correct au serveur, le système d'exploitation 13:12.820 --> 13:18.220 attribue automatiquement un numéro de port TCP à notre client TCP. 13:20.640 --> 13:24.690 Et cette valeur est choisie dynamiquement par le système d'exploitation. 13:28.680 --> 13:34.680 Lorsque nous ferons une démonstration de ce programme, vous verrez que le système d'exploitation attribue 13:34.680 --> 13:38.040 dynamiquement un numéro de port TCP au client TCP. 13:38.670 --> 13:44.700 La deuxième chose à noter ici est qu'il n'y a pas de concept d'appel système bind du côté du client TCP, n'est-ce 13:45.210 --> 13:45.960 pas ? 13:46.050 --> 13:53.250 De plus, il n'est pas nécessaire de maintenir un jeu de lecture ou un jeu de descripteurs de fichiers du côté du client. 13:56.010 --> 14:03.570 Vous remarquerez également que nous n'avons pas utilisé de descripteur de fichier dans ce bloc de code. 14:03.870 --> 14:11.150 La raison en est que notre client TCP ne communique qu'avec un seul serveur TCP, n'est-ce pas ? 14:11.160 --> 14:18.990 Si notre client TCP communiquait avec plusieurs serveurs TCP en même temps, il devrait maintenir plusieurs 14:18.990 --> 14:25.110 descripteurs de fichiers de sockets, chacun d'entre eux étant utilisé pour communiquer 14:25.110 --> 14:28.050 avec un serveur TCP. 14:30.150 --> 14:30.780 C'est vrai. 14:30.780 --> 14:37.680 Ce n'est donc pas comme si le client Dhcp n'avait pas besoin d'utiliser le jeu de descripteurs de fichiers. 14:37.920 --> 14:43.950 En fait, toute machine, qu'il s'agisse d'un client ou d'un serveur, si elle communique avec 14:43.950 --> 14:50.910 d'autres machines multiples, doit maintenir plus d'un descripteur de fichier de communication. 14:50.910 --> 14:56.520 Pour ce faire, la machine doit utiliser le jeu de descripteurs de fichiers. 14:58.860 --> 15:03.540 Vous pouvez également remarquer qu'il n'y a pas de concept d'acceptation d'appel système. 15:03.570 --> 15:10.290 L'appel système accept est destiné uniquement aux serveurs TCP qui acceptent la demande d'initiation du client. 15:11.610 --> 15:18.780 Alors les gars, faisons maintenant une démonstration de ce programme client Dhcp et serveur Dhcp dont nous avons parlé.