WEBVTT 00:05.140 --> 00:12.130 Passons donc rapidement en revue les API de programmation de sockets que nous avons utilisées dans notre code de programmation 00:12.130 --> 00:13.930 de sockets jusqu'à présent. 00:14.350 --> 00:21.610 Le premier est l'appel système de la socket L'appel système de la socket est utilisé pour créer un descripteur de fichier de la socket principale 00:21.610 --> 00:22.570 TCP ou UDP. 00:22.660 --> 00:26.290 Il est utilisé aussi bien du côté serveur que du côté client. 00:26.590 --> 00:28.860 Le second est l'appel système de sélection. 00:28.870 --> 00:32.620 Il est utilisé pour surveiller plusieurs descripteurs de fichiers. 00:32.650 --> 00:37.460 Il peut être utilisé aussi bien du côté client que du côté serveur. 00:37.480 --> 00:39.820 Il s'agit d'un appel système bloquant. 00:41.240 --> 00:48.050 L'appel système sélectionné se bloque donc jusqu'à ce qu'une nouvelle demande de connexion arrive ou que de nouvelles données arrivent 00:48.050 --> 00:49.220 du client existant. 00:49.460 --> 00:58.130 L'écriture sur n'importe quel descripteur de fichier surveillé et présent dans l'ensemble des fichiers acceptés par le système est utilisée 00:58.130 --> 01:00.590 uniquement du côté du serveur TCP. 01:00.590 --> 01:05.000 Notez donc que l'appel système excepté est spécifique au serveur TCP. 01:05.120 --> 01:12.380 Il n'est même pas utilisé pour les serveurs UDP, si ce n'est que l'appel système est utilisé pour accepter la demande de connexion du client et 01:12.380 --> 01:15.530 compléter l'échange de données à trois voies avec le client. 01:16.370 --> 01:18.470 Le quatrième est l'appel système bind. 01:19.100 --> 01:23.540 L'appel système Bind est utilisé du côté du serveur TCP ou UDP. 01:23.570 --> 01:28.400 Il est utilisé par le processus d'application du serveur pour informer le système d'exploitation. 01:28.400 --> 01:34.400 Il s'agit du système d'exploitation sous-jacent, des critères des paquets qui nous intéressent. 01:37.390 --> 01:39.640 Le cinquième est l'appel du système de leçons. 01:39.670 --> 01:42.890 Il est utilisé du côté du serveur TCP ou UDP. 01:42.910 --> 01:50.170 Il est utilisé par le processus d'application du serveur pour informer le système d'exploitation de la longueur de la file d'attente 01:50.170 --> 01:53.860 des demandes de connexion ou de données entrantes des clients. 01:54.970 --> 01:56.820 Puis recevoir l'appel du système. 01:56.890 --> 02:01.180 Il est utilisé du côté du serveur et du client TCP ou UDP. 02:01.180 --> 02:03.700 C'est-à-dire qu'il est utilisé des deux côtés. 02:03.790 --> 02:10.750 Il est utilisé par le serveur ou le processus client pour lire les données qui arrivent sur les descripteurs de fichiers de communication. 02:10.780 --> 02:14.560 Cet appel est également un appel système bloquant par défaut. 02:14.680 --> 02:15.910 Bloc de processus. 02:15.910 --> 02:23.050 Si les données ne sont pas arrivées sur un descripteur de fichier, le septième est assigné à l'appel système. 02:23.200 --> 02:28.480 Il est utilisé pour envoyer des données au client ou au serveur qui est une autre machine. 02:28.810 --> 02:33.940 Cet appel système est utilisé aussi bien du côté du serveur que du côté du client. 02:34.690 --> 02:40.420 Enfin, nous avons l'appel système close qui est utilisé pour fermer la connexion. 02:40.510 --> 02:47.650 Elle est utilisée par le client ou par le serveur, qui peut choisir de fermer la 02:47.650 --> 02:53.410 socket qu'il utilise pour communiquer avec l'autre machine. 02:54.930 --> 02:57.420 Passons maintenant aux observations. 02:57.420 --> 03:05.490 En d'autres termes, quels sont les éléments que nous aimerions observer dans le cadre de notre étude de la programmation des sockets client-serveur 03:05.490 --> 03:06.720 Dhcp. 03:07.500 --> 03:13.710 Notre serveur TCP peut donc accepter et maintenir jusqu'à 31 demandes de connexion. 03:13.710 --> 03:16.020 Cela représente jusqu'à 31 clients. 03:16.020 --> 03:20.730 La demande de connexion peut être acceptée par notre serveur et peut être maintenue. 03:20.940 --> 03:21.780 C'est vrai. 03:21.990 --> 03:28.710 En outre, 31 clients demandent une connexion, l'un d'entre eux étant le descripteur de fichier du socket principal. 03:28.830 --> 03:29.610 C'est vrai. 03:29.610 --> 03:32.880 Le serveur ne peut donc servir qu'un seul client à la fois. 03:34.030 --> 03:34.450 C'est vrai. 03:34.450 --> 03:41.620 Que notre serveur soit un serveur multi plex ou un serveur normal, il ne peut servir qu'un seul client 03:41.620 --> 03:42.800 à la fois. 03:42.820 --> 03:46.840 Cependant, notre serveur peut maintenir 31 connexions. 03:47.620 --> 03:48.290 C'est vrai. 03:48.310 --> 03:55.210 Si la demande de données de plusieurs clients est groupée, c'est-à-dire jusqu'à n, tous les clients 03:55.210 --> 04:01.210 seront servis, mais un par un, n étant la valeur spécifiée dans l'appel système. 04:02.050 --> 04:08.890 Avec l'augmentation du nombre de clients, ceux-ci peuvent commencer à souffrir de latence lorsqu'ils sont 04:08.890 --> 04:11.200 servis un par un par le serveur. 04:12.920 --> 04:16.250 Ainsi, la conception de ce serveur est bien meilleure que la précédente. 04:16.430 --> 04:20.720 Il s'agit de la conception du serveur qui ne peut gérer qu'un seul client à la fois. 04:21.020 --> 04:27.350 Notre serveur TCP avec multiplexage peut gérer plusieurs clients en même temps. 04:27.710 --> 04:28.520 C'est vrai. 04:28.610 --> 04:34.280 Mais notre serveur TCP avec multiplexage présente toujours des limites d'extensibilité. 04:35.120 --> 04:41.510 Les limites de l'évolutivité seront toujours présentes, quelle que soit la manière dont vous concevez le serveur pour gérer un plus grand nombre 04:41.510 --> 04:42.210 de clients. 04:42.230 --> 04:46.050 Nous devons déployer davantage de serveurs indépendants. 04:46.070 --> 04:52.280 C'est la raison pour laquelle les grandes multinationales comme Facebook et Google possèdent des centres 04:52.280 --> 04:55.970 de données dans lesquels se trouvent des milliers de serveurs. 04:56.710 --> 05:01.510 Ils traitent collectivement des millions de demandes de clients. 05:02.050 --> 05:08.350 Il ne faut donc pas s'attendre à ce qu'un seul serveur puisse gérer un nombre important de clients. 05:08.500 --> 05:14.410 Un tel serveur n'est pas limité par la conception du logiciel, mais par les limites du matériel. 05:14.410 --> 05:22.030 Ce que j'essaie de dire ici, c'est que si vous avez un grand nombre de clients, disons un million de clients, la façon 05:22.030 --> 05:28.490 dont vous concevez votre serveur n'a pas d'importance, vous êtes limité par le matériel. 05:28.510 --> 05:32.500 Vous avez besoin de plus de serveurs pour gérer un plus grand nombre de clients. 05:32.500 --> 05:38.140 C'est la raison pour laquelle les grandes agences ont des centres de données dans lesquels il y a des milliers 05:38.140 --> 05:45.220 de machines serveurs et la charge de millions de clients est plus ou moins uniformément répartie sur ces machines serveurs. 05:47.090 --> 05:52.520 Ensuite, nous allons parler de la programmation UDP, donc nous allons conclure la programmation UDP. 05:54.010 --> 06:00.790 Très rapide car la création d'une machine serveur UDP et d'une machine client UDP est très simple. 06:00.910 --> 06:07.270 Puisque nous avons appris à mettre en œuvre le client et le serveur TCP, il est très facile de mettre en œuvre le 06:07.270 --> 06:08.800 client et le serveur UDP. 06:09.190 --> 06:15.430 Si vous avez appris à créer une machine serveur TCP, la programmation UDP est beaucoup plus simple que la programmation 06:15.430 --> 06:22.840 TCP et c'est la raison pour laquelle il vous est donné comme devoir d'écrire votre propre serveur et client UDP. 06:22.870 --> 06:30.520 Si vous avez compris les étapes de la mise en œuvre d'un serveur TCP et d'un client TCP, il est très facile 06:30.520 --> 06:34.510 de mettre en œuvre un serveur UDP et un client UDP. 06:35.630 --> 06:39.560 Il s'agit donc d'un devoir pour vous d'implémenter un programme client-serveur UDP.