WEBVTT

00:05.140 --> 00:09.940
Le pseudo-code du projet est donc affiché à l'écran.

00:09.970 --> 00:14.890
Ce pseudo-code vous aidera à démarrer la mise en œuvre de votre projet.

00:14.920 --> 00:23.210
Ce pseudo-code reprend en fait toute la logique de votre projet, mais à un niveau légèrement supérieur.

00:23.290 --> 00:31.180
Chaque fois que vous démarrez votre processus dans un terminal pour un nœud donné, le nœud doit créer un descripteur de fichier de socket principal

00:31.180 --> 00:35.020
TCP et un descripteur de fichier de socket principal UDP.

00:35.050 --> 00:35.830
C'est vrai.

00:35.830 --> 00:45.220
Et à la lecture de Fdset, le nœud doit ajouter les descripteurs de fichiers UDP et TCP qu'il a créés.

00:45.490 --> 00:51.280
En outre, le nœud doit également ajouter zéro à ce jeu de descripteurs de fichiers.

00:51.490 --> 00:56.530
Le descripteur de fichier zéro est une valeur spéciale, qui signifie votre console.

00:57.110 --> 01:04.760
Parce que l'utilisateur doit interagir avec votre application pour fournir, placer ou obtenir une requête.

01:06.020 --> 01:14.090
Votre projet ou votre application doit donc non seulement surveiller le descripteur de fichier TCP et

01:14.090 --> 01:18.470
le descripteur de fichier UDP, mais aussi la console.

01:18.590 --> 01:25.010
L'appel système select sera donc invoqué sur ce descripteur de fichier read, ce qui signifie que vous

01:25.010 --> 01:29.150
surveillez ces trois descripteurs de fichier en même temps.

01:29.480 --> 01:35.690
Vous pouvez donc voir que votre application surveille le descripteur de fichier TCP et le descripteur de fichier UDP

01:35.690 --> 01:36.620
en même temps.

01:36.620 --> 01:44.240
Cela signifie que votre application se comporte à la fois comme un serveur TCP et comme un serveur UDP.

01:45.030 --> 01:52.140
Maintenant, lorsque l'appel système sélectionné se débloque, vous devez vérifier quel descripteur de fichier a été activé.

01:52.260 --> 01:58.650
Si le descripteur de fichier TCP a été activé, cela signifie que vous avez reçu une demande d'établissement

01:58.650 --> 02:02.100
de connexion de la part d'un autre nœud de la topologie.

02:02.820 --> 02:12.120
Et, conformément à notre projet, vous allez recevoir ce message x, obtenir une réponse x ou mettre une réponse X sur une connexion TCP à partir

02:12.120 --> 02:16.020
d'un nœud distant dans la topologie de l'anneau.

02:16.440 --> 02:23.310
De même, si c'est le descripteur de fichier UDP qui est activé, cela signifie que votre nœud doit traiter,

02:23.310 --> 02:29.520
transmettre un message ou recevoir un message qu'il a reçu du nœud précédent de la topologie en

02:29.550 --> 02:30.420
anneau.

02:31.070 --> 02:38.540
En revanche, si le descripteur de fichier de votre console est activé, cela signifie que l'utilisateur a émis une requête

02:38.540 --> 02:41.240
put ou get sur ce nœud particulier.

02:41.570 --> 02:48.530
Voici donc le pseudo-code que vous devez garder à l'esprit et commencer à mettre en œuvre votre projet

02:48.530 --> 02:50.810
sur la base de ce pseudo-code.

02:51.020 --> 02:56.840
Et vous pouvez voir que toute cette logique est encapsulée dans une boucle infinie.