WEBVTT 00:05.440 --> 00:07.270 Bienvenue à tous. 00:07.300 --> 00:12.430 Je vais maintenant discuter d'un projet de programmation sur la programmation des sockets. 00:12.460 --> 00:16.210 Le nom du projet est "Mémoire transparente distribuée". 00:16.240 --> 00:21.910 La condition préalable à la réalisation de ce projet est que vous soyez bien familiarisé avec les concepts de programmation 00:21.910 --> 00:23.410 de socket en C. 00:25.260 --> 00:31.830 Je vous encourage à réaliser ce projet en C, mais si vous avez des connaissances en programmation de sockets 00:31.830 --> 00:40.170 dans un autre langage, par exemple C Plus Plus ou Python ou Java, vous êtes également le bienvenu pour réaliser ce projet. 00:40.650 --> 00:48.240 Mais je vais discuter et présenter l'énoncé du problème de ce projet en termes de langage C. 00:48.570 --> 00:55.530 Discutons maintenant des objectifs du projet, de ce que nous essayons exactement de réaliser à travers ce projet. 00:55.860 --> 01:03.570 Ainsi, de nombreux nœuds partagent leur morceau de mémoire locale en un grand morceau de mémoire, et cette ligne est l'essence 01:03.570 --> 01:05.430 même de ce projet. 01:05.520 --> 01:09.000 Essayons donc de comprendre ce point en détail. 01:09.090 --> 01:16.620 Supposons donc que vous ayez quatre machines physiques et que chacune d'entre elles dispose d'un disque 01:16.650 --> 01:17.520 dur de 2 Go. 01:17.550 --> 01:26.590 Au total, vous disposez donc de huit Go de mémoire, mais ces huit Go de mémoire sont en fait répartis sur quatre machines 01:26.590 --> 01:28.780 physiques différentes. 01:29.230 --> 01:37.180 La mémoire est donc répartie sur quatre nœuds, mais l'utilisateur n'est pas conscient de cette répartition, et c'est à 01:37.180 --> 01:40.300 cela que se rapporte le terme "transparent". 01:40.960 --> 01:48.070 L'utilisateur final pourra accéder à l'ensemble des huit Go de mémoire par l'intermédiaire d'un réseau. 01:48.070 --> 01:48.820 C'est vrai. 01:48.850 --> 01:57.850 Vous pouvez donc voir que dans ce diagramme, il y a un réseau entre l'utilisateur et le stockage qui est distribué sur des 01:57.850 --> 01:59.740 machines physiques. 02:00.430 --> 02:06.850 Ce modèle de mémoire est utilisé lorsque de grandes quantités de données doivent être stockées sur plusieurs machines. 02:06.880 --> 02:14.320 Le système de fichiers distribués Hadoop, qui repose sur ce modèle, est un exemple de ce type de stockage distribué. 02:14.530 --> 02:15.400 C'est vrai. 02:15.910 --> 02:21.760 Ainsi, dans ce projet, nous allons construire une mémoire distribuée et l'utilisateur n'aura pas à suivre 02:21.760 --> 02:27.910 les informations relatives à l'emplacement des données ou à la manière dont elles sont récupérées. 02:27.910 --> 02:28.700 C'est vrai. 02:28.720 --> 02:31.350 Voici donc ce qu'il en est réellement. 02:31.360 --> 02:33.790 C'est-à-dire que nous avons un utilisateur ici. 02:33.790 --> 02:38.980 Nous disposons d'un réseau qui se situe entre l'utilisateur et les machines physiques. 02:39.250 --> 02:48.940 Cet utilisateur a désormais accès à un total de 8 Go de stockage, répartis sur plusieurs machines 02:48.940 --> 02:50.350 physiques. 02:51.070 --> 02:58.480 L'objectif final de ce projet est donc que l'utilisateur final ait l'impression d'avoir accès 02:58.480 --> 03:00.160 à huit Go de mémoire. 03:01.300 --> 03:06.970 L'utilisateur n'a pas besoin de garder une trace de la machine physique sur laquelle il travaille. 03:06.970 --> 03:11.980 En fait, les données qui l'intéressent sont réservées à l'utilisateur final. 03:11.980 --> 03:18.730 Il semblerait que la totalité des huit Go de mémoire physique soit disponible. 03:19.560 --> 03:26.940 En d'autres termes, ce projet vise à donner l'illusion à l'utilisateur final qu'il a 03:26.940 --> 03:31.010 accès à un plus gros morceau de mémoire unifié. 03:31.020 --> 03:37.140 Ce gros morceau de mémoire est en fait réparti sur plusieurs machines physiques. 03:37.410 --> 03:42.930 Ce diagramme reflète donc l'objectif global de notre projet.