WEBVTT 00:05.080 --> 00:09.760 Nous allons maintenant discuter de la manière dont les demandes d'accès seront traitées. 00:10.090 --> 00:14.380 L'utilisateur peut émettre une demande d'accès à n'importe quel nœud de la topologie. 00:14.590 --> 00:22.840 L'objectif de la requête "get" est de récupérer la valeur de x correspondant à la clé spécifiée en tant qu'argument de 00:22.840 --> 00:24.250 la requête "get". 00:24.280 --> 00:30.370 La valeur correspondant à cette clé peut être présente sur n'importe quel nœud de la topologie. 00:31.020 --> 00:36.540 Essayons maintenant de comprendre la fonctionnalité de la requête get à l'aide d'un exemple. 00:37.020 --> 00:45.570 Supposons que l'utilisateur émette une demande d'obtention avec une valeur de clé égale à cinq, et que cette demande soit émise sur le nœud 00:45.570 --> 00:46.770 numéro trois. 00:46.860 --> 00:47.730 C'est vrai. 00:48.930 --> 00:55.570 Le nœud trois effectue une opération de hachage sur la clé égale à cinq. 00:55.590 --> 01:01.860 Nous savons déjà que la fonction de hachage pour cinq renvoie six, n'est-ce pas ? 01:02.590 --> 01:11.380 Le nœud trois sait maintenant qu'il n'a pas besoin d'aller chercher X contre K dans sa table de hachage locale et décide donc de transmettre 01:11.380 --> 01:18.580 la valeur de la clé au nœud qui lui succède dans la topologie en anneau, c'est-à-dire le nœud quatre, en utilisant 01:18.580 --> 01:20.530 le protocole UDP. 01:20.830 --> 01:24.670 Appelons ce type de message "get forward". 01:25.680 --> 01:28.830 Quel sera donc le contenu de ce message ? 01:28.860 --> 01:36.270 Le contenu de ce message de transfert sera la valeur d'une clé, l'adresse IP de l'expéditeur, 01:36.270 --> 01:44.340 qui est le nœud trois, et le numéro de port TCP de l'expéditeur, qui est également le nœud trois. 01:44.900 --> 01:51.410 Nous devons donc coder ces trois éléments d'information dans le message get forward. 01:53.160 --> 01:59.310 Ce message est ensuite transmis par le nœud trois au nœud quatre. 01:59.910 --> 02:04.950 Lorsque le nœud quatre reçoit ce message de transmission, il répète le processus. 02:04.980 --> 02:12.330 Il récupère la valeur de la clé dans le message de transfert qu'il a reçu du nœud 3 et applique la 02:12.330 --> 02:19.860 fonction de hachage à cette valeur K afin de déterminer s'il doit traiter ce message de transfert 02:19.860 --> 02:20.700 ou non. 02:20.940 --> 02:21.690 C'est vrai. 02:21.690 --> 02:28.680 Mais comme la fonction de hachage renvoie six, cela signifie simplement que le nœud quatre 02:28.680 --> 02:35.490 transmettra le message à son successeur, le nœud cinq, sans en modifier le contenu. 02:35.760 --> 02:42.390 Ce processus se poursuit jusqu'à ce que le nœud six reçoive le message "get forward". 02:43.690 --> 02:51.910 La note six sait qu'elle doit récupérer la valeur de X par rapport à une clé dont la valeur est cinq dans sa table de 02:51.910 --> 02:58.930 hachage locale, car la fonction de hachage pour cinq est égale à six, qui est un numéro de nœud. 02:59.110 --> 03:07.660 Le nœud six sait donc que pour k la clé est égale à cinq, x est égal à cinq car il a récupéré cette valeur dans sa table 03:07.660 --> 03:09.520 de hachage locale. 03:10.240 --> 03:16.300 La demande d'accès a été émise à l'origine par l'utilisateur du nœud numéro trois. 03:16.860 --> 03:22.140 L'utilisateur attend maintenant la valeur de X sur le nœud numéro trois. 03:23.070 --> 03:26.610 La prochaine étape consiste donc à acheminer le nœud trois. 03:26.640 --> 03:28.590 La valeur de X. 03:29.040 --> 03:36.120 Pour ce faire, le nœud six établit une connexion TCP avec l'auteur initial de la demande, 03:36.120 --> 03:42.690 c'est-à-dire le nœud numéro trois, et communique au nœud trois la valeur de X. 03:42.720 --> 03:46.530 Appelons ce message "obtenir une réponse x". 03:47.370 --> 03:53.430 Le nœud six envoie donc un message de réponse à l'expéditeur de la demande d'accès. 03:54.060 --> 04:01.830 Lorsque l'auteur de la requête reçoit ce message de réponse X, il imprime simplement la 04:01.830 --> 04:10.830 valeur de la clé et la valeur de x sur la console, ce qui indique à l'utilisateur que la valeur de la clé k et 04:10.830 --> 04:13.950 la valeur de x sont égales à cinq. 04:14.070 --> 04:22.230 Une fois que le nœud trois a reçu la valeur de x, le nœud trois ferme la connexion TCP avec le nœud six après avoir reçu 04:22.230 --> 04:23.700 X est égal à cinq. 04:23.820 --> 04:29.610 La note six ferme également la connexion TCP après l'envoi de X est égal à cinq. 04:30.660 --> 04:34.050 Voici donc la fonctionnalité de la requête "get". 04:34.830 --> 04:37.320 Résumons cela. 04:37.320 --> 04:43.650 Quels sont les différents types de messages dont nous avons parlé et qui seront utilisés dans ce projet ? 04:44.790 --> 04:50.550 Là encore, vous pouvez vous référer à l'organigramme que j'ai joint dans la section des ressources, qui explique 04:50.550 --> 04:54.270 l'algorithme de la requête get à l'aide d'un organigramme.