Il s'agit donc d'un module très court.
Dans ce module, nous allons apprendre le concept de multiplexage et nous verrons comment le multiplexage
peut être appliqué à un processus grâce auquel le processus peut recevoir les données de plusieurs mécanismes IPC en même
temps.
Nous avons donc étudié le multiplexage dans le contexte des sockets de domaine Unix.
Si vous vous souvenez de l'étude du multiplexage dans le contexte des sockets de domaine Unix, notre processus
serveur pouvait en fait lire les données envoyées par n'importe quel client connecté.
Le multiplexage a donc aidé notre serveur à traiter simultanément les données qui pouvaient être reçues à tout
moment de n'importe quel client connecté.
Nous allons maintenant appliquer le concept de multiplexage au niveau de l'IPC.
C'est-à-dire que nous avons un processus serveur et que ce processus serveur peut recevoir des données de manière asynchrone à partir
d'un socket réseau Unix domain socket.
Il peut recevoir les données de la console, c'est-à-dire de l'utilisateur, et il peut recevoir les données de la file d'attente
des messages.
Vous pouvez donc voir que notre processus serveur a ouvert une file d'attente de messages de socket réseau de domaine
Unix ainsi qu'une console.
Et à partir de n'importe lequel de ces canaux, notre processus serveur peut effectivement recevoir des données à tout moment.
À tout moment signifie de manière asynchrone.
La question est donc de savoir comment concevoir un processus qui récupère les données envoyées par n'importe
quel mécanisme IPC et les traite.
Voyons donc comment procéder.
Vous pouvez donc voir dans ce diagramme que nous avons un processus serveur et que ce processus serveur
peut recevoir les données de n'importe quel client de domaine Unix ou de n'importe quel client réseau qui est un client TCP ou UDP ou de n'importe quel client
qui communique sur le réseau.
Notre processus serveur peut également recevoir les données des files d'attente de messages.
Notez qu'il peut y avoir plus d'un message parce qu'il peut y avoir plus d'un client
réseau et plus d'un client de domaine Unix.
Le processus serveur va donc récupérer les données envoyées par n'importe quel client, qu'il s'agisse
d'un client socket de domaine Unix ou d'un client socket de domaine réseau, ou encore d'un
client qui tourne sur la même machine et qui envoie les données à notre processus serveur à l'aide
de files d'attente de messages.
Passons donc en revue ces points.
Si vous remarquez que les sockets réseau, les sockets de domaine Unix et les files d'attente de messages ont des descripteurs de fichiers.
Nous savons déjà que lorsque vous créez une socket Unix, une socket réseau ou une file d'attente de messages,
l'API renvoie le descripteur de fichier.
Ce descripteur de fichier est donc en fait la représentation d'un socket, n'est-ce pas ?
Nous avons déjà appris le multiplexage dans le contexte des sockets dans le module 1.
Dans ce cas, il suffit donc d'ajouter tous les descripteurs de fichiers à la structure de données set et d'invoquer l'appel
système select sur ce set.
Ce faisant, notre processus serveur va effectuer un multiplexage sur tous les descripteurs de fichiers présents dans la structure
de données de l'ensemble.
Ainsi, l'appel système select se débloquera si le serveur reçoit des données sur un descripteur de fichier par le biais d'un mécanisme IPC.
Le concept est donc le même.
Le contenu du descripteur de fichier doit donc indiquer qu'il doit contenir des données sur les sockets des clients du réseau.
Il s'agit des descripteurs de fichiers de communication de tous les clients du réseau, plus le descripteur de fichiers du socket principal
du socket du réseau.
C'est vrai.
Il doit également disposer des sockets de données de tous les clients du domaine Unix et du socket maître du
socket du domaine Unix, que nous appelons socket de connexion.
C'est vrai.
En outre, les descripteurs de fichiers de toutes les files d'attente de messages à partir desquelles notre processus
serveur souhaite lire les messages.
C'est vrai.
La dernière chose que vous pouvez ajouter à cette structure de données est la valeur zéro, qui représente en fait
une console.
L'ajout d'un descripteur de fichier zéro à l'ensemble permet à notre processus serveur d'écouter la console.
Cela permettra donc à l'utilisateur ou à l'administrateur d'interagir avec le processus du serveur pendant que ce dernier est bloqué
par l'appel système de sélection parce que zéro en tant que descripteur de fichier a été ajouté à l'ensemble, la structure de données
et la structure de données de l'ensemble sont surveillées par l'appel système de sélection.
Vous pouvez donc voir que si vous ajoutez tous ces descripteurs de fichiers à la structure de données set et que vous invoquez
select system, call sur cette structure de données set, notre processus serveur va surveiller toutes les interfaces IPC qu'il a ouvertes
afin d'interagir avec d'autres processus s'exécutant sur le même système ou sur un système différent.
Le concept est donc simple.
Nous pouvons invoquer le système de sélection, faire appel à des descripteurs de fichiers.
Peu importe que le descripteur de fichier appartienne au domaine Unix sockets ou network socket
ou message queue ou autre.
L'appel système select fonctionne avec tous les types de descripteurs de fichiers.
C'était donc le concept du multiplexage et de l'utilisation du multiplexage.
Vous pouvez concevoir votre processus serveur de manière à ce qu'il puisse lire simultanément les données provenant de divers
mécanismes IPC.