WEBVTT 00:05.020 --> 00:11.140 Cette diapositive montre le diagramme de la machine à états d'un serveur TCP. 00:11.530 --> 00:17.380 Nous allons donc examiner toutes les étapes de la mise en œuvre d'un serveur TCP typique. 00:17.800 --> 00:24.160 Les étapes que nous allons aborder seront entièrement conformes à ce schéma d'état. 00:24.460 --> 00:27.730 Nous avons déjà discuté de ce diagramme d'état. 00:28.390 --> 00:34.900 Voyons donc le code et les différentes étapes de la mise en œuvre d'un serveur TCP. 00:36.190 --> 00:41.920 Vous pouvez donc voir que vous devez suivre ces dix étapes pour mettre en œuvre un serveur TCP typique. 00:42.430 --> 00:49.750 Nous allons passer en revue ces étapes une à une et voir comment elles sont mises en œuvre dans la programmation des sockets. 00:50.710 --> 00:53.080 Alors les gars, faisons un tour de code. 00:55.840 --> 01:05.660 J'ai écrit un fichier appelé TCP Server dot C. Vous pouvez voir ici un fichier, TCP server dot C, et dans ce fichier j'ai implémenté 01:05.660 --> 01:09.740 la fonctionnalité d'un serveur TCP. 01:11.080 --> 01:14.260 Je partagerai ce code avec vous dans la section des ressources. 01:14.950 --> 01:19.180 Ouvrons donc ce fichier et voyons comment le serveur TCP est mis en œuvre. 01:19.750 --> 01:23.050 Commençons donc par la grande ligne droite. 01:24.580 --> 01:25.240 C'est vrai. 01:25.240 --> 01:27.130 Commençons donc par la fonction principale. 01:27.130 --> 01:33.190 Dans la fonction principale, vous voyez que je ne fais rien, mais je n'appelle qu'une seule fonction qui est la configuration de la communication 01:33.190 --> 01:34.210 serveur TCP. 01:34.300 --> 01:39.070 Dans cette fonction, j'implémente donc l'ensemble des fonctionnalités d'un serveur TCP. 01:39.760 --> 01:41.890 Discutons donc de cette fonction. 01:43.960 --> 01:46.690 Voici donc le début de cette fonction. 01:46.930 --> 01:50.050 La première étape est donc la phase d'initialisation. 01:50.080 --> 01:54.430 Comme vous pouvez le constater, la première étape consiste uniquement à initialiser les variables. 01:55.000 --> 02:01.120 Ainsi, dans la première étape, nous avons pris toutes les variables requises dont nous aurons besoin pour mettre en œuvre 02:01.120 --> 02:02.290 un serveur Dhcp. 02:02.470 --> 02:05.860 Comme nous l'avons déjà vu, lorsque le serveur démarre, il est possible d'obtenir des informations sur l'état d'avancement de l'installation. 02:08.840 --> 02:15.170 Comme nous l'avons déjà vu, lorsque le serveur démarre, il crée un descripteur de fichier de socket principal 02:15.170 --> 02:19.520 et place ce descripteur de fichier de socket principal dans un ensemble. 02:20.510 --> 02:27.980 Nous avons donc pris une variable de descripteur de fichier de la socket principale qui est à nouveau une valeur entière, n'est-ce pas ? 02:27.980 --> 02:31.730 Pour le reste des variables, nous discuterons du moment où nous les utiliserons. 02:32.000 --> 02:37.550 Nous avons pris un jeu de lecture qui est de type FD, jeu de soulignement. 02:37.940 --> 02:46.700 Il s'agit donc d'un ensemble et comme notre serveur TCP continue à créer des descripteurs de fichiers, notre serveur va ajouter ces descripteurs 02:46.700 --> 02:48.800 de fichiers à cet ensemble. 02:50.530 --> 02:51.280 C'est vrai. 02:51.670 --> 02:59.590 Nous avons pris des variables de type struct soc addr qui sont l'adresse du serveur et l'adresse du client. 02:59.740 --> 03:07.300 Ce type de données, struct sockaddrin, est donc utilisé pour stocker l'identité de la machine. 03:07.300 --> 03:13.230 Il s'agit de l'adresse IP et du numéro de port de notre serveur et du client. 03:13.240 --> 03:16.780 Nous allons donc voir comment utiliser ces variables. 03:18.670 --> 03:19.450 C'est vrai. 03:20.290 --> 03:25.360 Vous pouvez donc voir que dans la première étape, nous devons créer un descripteur de fichier de socket maître et le placer dans le jeu 03:25.640 --> 03:26.210 de lecture. 03:27.130 --> 03:33.100 Vous pouvez voir que dans la deuxième étape, nous devons créer un descripteur de fichier de socket maître. 03:34.060 --> 03:34.720 C'est vrai. 03:34.720 --> 03:40.420 Passons donc à l'étape 2 et vous pouvez voir que nous avons tout de suite créé un descripteur de fichier de 03:40.420 --> 03:41.380 socket maître. 03:42.310 --> 03:48.140 Le descripteur de fichier de la socket principale est donc créé à l'aide de l'appel système de la socket L'appel système de la socket accepte 03:48.140 --> 03:49.010 trois arguments. 03:49.340 --> 03:56.510 La première est la famille d'adresses, car nous avons affaire à des adresses IPv4 et nous devons donc créer 03:56.510 --> 03:58.340 des sockets IPV quatre. 03:58.850 --> 04:02.120 Le premier argument définit donc cela. 04:02.120 --> 04:04.340 Quelle est la famille d'adresses que vous utilisez ? 04:04.430 --> 04:09.110 Ainsi, pour IPV, quatre réseaux passent toujours AF underscore Inet. 04:09.230 --> 04:14.120 Si c'est le cas, si vous travaillez avec six adresses IPV, alors... 04:14.830 --> 04:18.310 Vous auriez dû passer af underscore inet six. 04:21.700 --> 04:25.690 Le deuxième argument que vous devez passer est donc le flux de la socket. 04:25.690 --> 04:27.670 Si vous souhaitez créer une socket TCP. 04:27.700 --> 04:32.030 Le deuxième argument doit être un flux de socket pour les sockets UDP. 04:32.050 --> 04:34.510 Cette valeur doit être soc d gram. 04:36.150 --> 04:36.910 C'est vrai. 04:36.930 --> 04:37.380 Et... 04:39.380 --> 04:46.610 Le troisième argument définit le protocole que vous souhaitez exécuter au sommet de la couche réseau. 04:47.210 --> 04:52.250 Ainsi, au sommet de la couche réseau, nous essayons d'exécuter le protocole TCP. 04:52.490 --> 04:57.500 Le protocole TCP est donc identifié à l'aide de cette constante IP, proto TCP. 04:57.980 --> 05:06.920 Il s'agit donc de socket stream et de proto TCP, tous deux combinés ensemble pour identifier le protocole 05:06.920 --> 05:08.120 TCP. 05:08.360 --> 05:14.750 Pour créer une socket TCP, il faut donc passer le deuxième argument au système de socket, appelé 05:14.750 --> 05:15.830 socket stream. 05:15.830 --> 05:19.310 Et le troisième argument doit être IP proto TCP. 05:21.050 --> 05:21.710 C'est vrai. 05:21.710 --> 05:26.210 Et si vous vouliez créer un socket UDP au lieu de. 05:26.900 --> 05:27.900 Socket TCP. 05:27.920 --> 05:33.080 Le deuxième argument aurait alors été sock underscore d gram. 05:33.230 --> 05:37.880 Et le troisième argument aurait été IP, proto UDP. 05:40.080 --> 05:40.800 C'est vrai. 05:41.070 --> 05:45.780 Ainsi, après la deuxième étape, vous obtiendrez le descripteur de fichier de la socket maître. 05:47.030 --> 05:51.830 Ainsi, après la deuxième étape, la création du descripteur de fichier du socket maître est terminée. 05:52.910 --> 05:55.640 La troisième étape est l'appel système bind. 05:58.050 --> 05:59.820 L'appel au système de liaison est donc ici. 05:59.820 --> 06:03.660 Il s'agit de l'étape trois de l'appel au système de liaison, ce qui signifie que. 06:04.520 --> 06:05.840 Votre processus de serveur. 06:05.840 --> 06:12.320 En d'autres termes, ce serveur Dhcp transmet les critères au système d'exploitation sous-jacent. 06:13.090 --> 06:16.240 du paquet que le serveur veut recevoir. 06:17.580 --> 06:18.210 C'est vrai. 06:18.210 --> 06:23.010 Vous pouvez donc voir que le premier argument de l'appel système bind est le descripteur de fichier de la socket 06:23.010 --> 06:24.810 maître que vous avez créé à l'étape 2. 06:25.350 --> 06:34.050 Le deuxième argument de l'appel système bind est en fait l'identité du serveur, c'est-à-dire l'adresse IP et le numéro 06:34.080 --> 06:35.580 de port du serveur. 06:35.820 --> 06:43.620 Vous pouvez donc voir ici que le serveur a rempli cette variable qui est server underscore addr. 06:44.950 --> 06:46.480 Avec quelques informations. 06:46.480 --> 06:47.080 Voyons donc. 06:47.110 --> 06:48.430 Quelle est cette information ? 06:49.090 --> 06:53.680 La première information renseignée dans cette structure est la famille SIM. 06:53.860 --> 06:58.390 Comme je l'ai dit, pour IPV quatre réseaux vous devez passer un f underscore inet. 06:59.370 --> 07:00.000 C'est vrai. 07:00.210 --> 07:06.600 Notre serveur est donc en fait notre serveur TCP et il doit donc fonctionner sur un numéro de port. 07:09.290 --> 07:18.620 Nous avons donc indiqué le numéro de port du serveur dans server underscore addr dot sin port member, en attribuant simplement la valeur 07:18.620 --> 07:21.080 du numéro de port d'un serveur. 07:21.230 --> 07:28.100 Le numéro de port du serveur est donc en fait une constante définie par hachage et sa valeur est 2000. 07:30.470 --> 07:34.160 Vous pouvez voir qu'il s'agit d'une constante et que sa valeur est 2000. 07:38.840 --> 07:39.520 C'est vrai. 07:39.830 --> 07:47.720 Le troisième élément à remplir dans cette structure est l'adresse IP du serveur. 07:48.110 --> 07:49.010 Aujourd'hui. 07:50.190 --> 07:55.500 Ici, vous pouvez transmettre une adresse IP particulière sous forme d'un nombre entier. 07:55.860 --> 08:02.430 Par exemple, si votre serveur souhaite recevoir un paquet dans lequel l'adresse IP de destination spécifiée est l'adresse IP 08:02.430 --> 08:11.700 du serveur et que cette adresse IP est 192. 168. 56. 101. 08:12.120 --> 08:15.960 Cela signifie qu'il s'agit de l'adresse IP d'un serveur. 08:16.260 --> 08:21.600 L'équivalent en nombres entiers de cette adresse IP est donc cette valeur. 08:21.840 --> 08:28.260 Vous devez donc transmettre cette valeur particulière à ce membre. 08:28.590 --> 08:33.540 Mais ici, vous pouvez voir que j'ai passé quelque chose d'autre qui s'appelle n underscore n. 08:34.290 --> 08:36.030 Qu'est-ce que cela signifie ? 08:37.550 --> 08:41.090 En d'autres termes, supposons que vous disposiez d'un serveur. 08:45.110 --> 08:50.300 Et votre machine serveur peut avoir des interfaces, des interfaces multiples, n'est-ce pas ? 08:50.510 --> 08:55.670 Chaque interface peut avoir une adresse IP comme 2. 1. 1 barre oblique 24. 08:55.850 --> 09:00.080 2. 1. 2. 1 entaille 24. 09:00.380 --> 09:03.740 et 2. 1. 3. 1 entaille 24. 09:04.270 --> 09:04.960 C'est vrai. 09:06.070 --> 09:14.260 Par conséquent, n'importe quelle adresse IP peut appartenir à n'importe quelle interface locale de ce serveur. 09:14.650 --> 09:20.590 Ainsi, chaque fois que le serveur reçoit un paquet dont l'adresse IP de destination est égale à . 09:20.890 --> 09:28.030 adresse IP de n'importe quelle interface locale de ce serveur, alors ce serveur va traiter ce paquet. 09:28.830 --> 09:29.460 C'est vrai. 09:30.270 --> 09:36.590 Et au lieu de dans n'importe quel, avez-vous transmis l'équivalent entier de l'adresse IP ? 09:36.720 --> 09:41.190 2. 1. 2. 1 qui correspond à cette adresse IP. 09:41.760 --> 09:45.270 Ensuite, seul le paquet avec l'adresse IP de destination est pris en compte. 09:45.270 --> 09:47.310 2. 1. 2. 1. 09:47.760 --> 09:50.760 Ensuite, seuls les paquets avec l'adresse IP de destination sont pris en compte. 09:50.760 --> 10:00.900 2. 1. 2. 1 aurait été transmis à votre processus serveur fonctionnant dans la couche application par la 10:00.900 --> 10:01.380 couche socket. 10:03.450 --> 10:12.690 En fait, l'ADR de soulignement du serveur est une structure qui est remplie avec l'identité de la machine serveur. 10:12.780 --> 10:14.670 Il s'agit de l'adresse IP. 10:16.110 --> 10:21.240 Et le numéro de port et parce que votre machine serveur peut avoir plusieurs adresses IP. 10:21.950 --> 10:25.550 Qui est l'adresse de chaque interface du serveur. 10:25.730 --> 10:31.880 C'est donc le serveur qui choisit l'adresse IP avec laquelle il veut recevoir le paquet. 10:31.910 --> 10:39.470 Ainsi, si vous indiquez addr underscore any, cela signifie que le serveur souhaite recevoir le paquet dont l'adresse 10:39.470 --> 10:45.530 IP de destination est égale à l'adresse IP de n'importe quelle interface locale du serveur. 10:45.950 --> 10:53.600 Ainsi, tant que l'adresse IP du paquet est égale à l'adresse IP d'une interface locale de ce serveur, la couche 10:53.600 --> 11:01.490 "socket" de la pile TCP IP se chargera de transmettre le paquet au processus du serveur qui s'exécute dans la couche 11:01.490 --> 11:02.900 "application". 11:04.240 --> 11:04.900 C'est vrai. 11:05.380 --> 11:07.870 C'est donc quelque chose qu'il faut comprendre. 11:11.630 --> 11:18.550 Il faut alors une constante comme underscore Len qui est égale à la taille de la structure socket ADR. 11:19.920 --> 11:23.160 Nous allons donc voir comment cette constante est utilisée. 11:24.740 --> 11:29.330 Nous voici donc à la troisième étape, où l'appel système bind est lancé. 11:29.360 --> 11:33.950 Le premier argument de l'appel système bind, comme je l'ai dit, est le descripteur de fichier de la socket principale. 11:34.190 --> 11:38.780 Le deuxième argument de l'appel système bind est l'information sur le serveur. 11:38.780 --> 11:47.240 En d'autres termes, le serveur transmet au système d'exploitation l'information qu'il est un serveur et qu'il souhaite 11:47.240 --> 11:50.540 recevoir le paquet avec l'adresse IP. 11:50.540 --> 11:53.570 2. 1. 2. 1 par exemple. 11:54.410 --> 11:55.190 C'est vrai. 11:55.700 --> 11:59.690 Et vous pouvez voir que nous avons rempli cette structure avec le numéro de port également. 11:59.930 --> 12:06.890 Le serveur indique donc également au système d'exploitation que je souhaite recevoir un paquet dans 12:06.890 --> 12:12.530 lequel le numéro de port TCP spécifié dans l'en-tête de transport est 2000. 12:14.620 --> 12:15.300 C'est vrai. 12:15.310 --> 12:22.870 Ainsi, avec l'appel système bind, le serveur transmet au système d'exploitation. 12:24.700 --> 12:30.190 N'oubliez pas que le serveur s'exécute dans la couche d'application et que le système d'exploitation s'exécute sous la couche 12:30.190 --> 12:31.220 d'application. 12:31.240 --> 12:37.990 Le serveur transmet donc au système d'exploitation l'information selon laquelle je suis un serveur avec une adresse IP, 12:37.990 --> 12:38.710 bla bla bla. 12:38.920 --> 12:47.380 Et si vous recevez un paquet avec l'adresse IP, bla bla bla et le numéro de port x, y, z alors s'il vous plaît 12:47.380 --> 12:49.450 livrez ces paquets à moi. 12:50.380 --> 12:52.900 C'est donc le concept de l'appel système bind. 12:54.240 --> 12:57.450 L'étape suivante est l'appel au système d'écoute. 12:58.680 --> 13:06.120 Par l'intermédiaire de l'appel système listen, le processus serveur demande au système d'exploitation de maintenir une file d'attente de longueur 13:06.120 --> 13:06.840 maximale. 13:07.790 --> 13:14.540 Cinq parce que nous avons passé cinq comme deuxième argument à l'appel système de la leçon et avec l'appel système de la leçon 13:14.540 --> 13:16.000 le processus du serveur. 13:16.010 --> 13:22.940 Le processus serveur demande au système d'exploitation sous-jacent de maintenir une file d'attente de longueur cinq. 13:24.110 --> 13:27.320 Qu'est-ce qui fait que c'est possible ? 13:29.640 --> 13:35.490 Le serveur peut recevoir des demandes de connexion ou des demandes de données de la part du client C1. 13:35.520 --> 13:36.870 Client C2. 13:36.900 --> 13:40.770 Le client C3 et le client disent C9. 13:41.280 --> 13:49.230 Vous voyez donc que le serveur peut recevoir une demande de connexion ou de données de la part d'un nombre quelconque de clients 13:49.230 --> 13:50.540 en même temps. 13:50.550 --> 13:58.410 Ainsi, lorsque les demandes arrivent en même temps, le système d'exploitation maintient une file d'attente de longueur 13:58.410 --> 14:05.280 cinq et, parce que les neuf demandes arrivent en même temps, le système d'exploitation ne met en file 14:05.280 --> 14:10.020 d'attente que cinq d'entre elles et abandonne les autres. 14:12.990 --> 14:19.590 Oui, parce que vous ne voulez pas que le système sur lequel tourne le processus serveur soit submergé 14:19.590 --> 14:26.280 ou surchargé par un grand nombre de demandes simultanées émanant d'un grand nombre de clients. 14:26.760 --> 14:29.370 C'est donc l'objectif de l'appel de système d'écoute.