Avant de plonger dans l'appel système Select and Accept, il est important de discuter de la conception de la communication
de haut niveau basée sur les sockets de Linux.
Pour commencer, les messages envoyés par le client au serveur peuvent être classés en deux catégories.
Le premier type de messages est appelé message de demande d'établissement de connexion.
Ces messages sont utilisés par le client pour demander à un serveur d'établir une connexion spécialisée seulement après que la
connexion a été établie.
Ensuite, seul le client peut envoyer.
Le deuxième type de messages est appelé messages de demande de service.
Le deuxième type de message est donc un message de demande de service.
Le client peut envoyer ce type de messages au serveur une fois que la connexion est entièrement établie par le biais
de ces messages.
Le client demande au serveur de fournir un service.
C'est vrai.
Il existe donc deux types de messages : les messages de connexion, les messages d'initiation et les messages de demande.
Ainsi, lorsque le client C veut se connecter au serveur s, il doit envoyer le message appelé demande
d'initiation de connexion.
Il s'agit donc du premier type de messages.
À l'aide de ces messages, le client demande au serveur d'établir une connexion.
Une fois la connexion établie, seul le client peut utiliser les services du serveur en utilisant un deuxième
type de messages appelés messages de demande de service.
Le serveur identifie et traite donc les deux types de messages de manière très différente.
Nous y reviendrons dans la diapositive suivante.
En résumé, il existe deux types de messages : les messages de demande d'établissement de connexion, qui sont envoyés
par le client au serveur.
Le client envoie ces messages à l'aide d'un appel système "connect".
Connect est donc un appel système Linux qui est utilisé du côté du client, lorsque celui-ci souhaite
établir une connexion avec le serveur.
Le serveur, quant à lui, utilise l'appel système accept pour recevoir la demande d'établissement de la connexion
de la part du client et terminer la connexion.
À cette fin, Linux fournit l'appel système accept, qui doit être utilisé du côté du serveur.
Les autres types de messages sont les messages de demande de service.
Ces messages sont envoyés par le client à l'aide d'API telles que envoyer un message ou envoyer au serveur.
Reçoit les messages de demande de service du client à l'aide de l'API de réception de messages ou de l'API de réception.
C'est vrai.
Vous verrez tous ces appels système en action lorsque nous aborderons la programmation des sockets
en détail plus loin dans ce module.
Essayons maintenant de comprendre le cycle de vie d'une communication client-serveur.
Lorsque le serveur démarre, la toute première chose qu'il fait est de créer un socket principal.
Ce socket maître est créé à l'aide d'un système Linux appelé socket.
C'est vrai.
Nous avons donc ici un serveur et supposons qu'il a démarré.
C'est-à-dire que ce serveur a démarré et que la première chose qu'il va faire est de créer un socket
maître.
Ce socket maître est créé à l'aide de l'appel système socket.
J'utilise maintenant le mot "maître".
C'est vrai.
Cela signifie donc que cette prise a des privilèges particuliers.
Essayons maintenant de comprendre en quoi cette prise est spéciale et quels sont les privilèges qu'elle
possède.
Supposons donc que nous ayons un client C1 quelque part dans le réseau.
Let C1 envoie le message de demande d'établissement de connexion au serveur.
Cela signifie que le client C1 veut se connecter au serveur.
Notez maintenant que le message de demande d'établissement de la connexion est reçu par le serveur sur le socket principal.
Lorsque le serveur reçoit la demande d'initiation de connexion du client à l'aide
du socket principal, il crée un handle pour le client.
Il s'agit donc de la poignée qui est créée par le serveur pour le client.
C1.
Aujourd'hui.
Qu'est-ce qu'une poignée ?
Handle n'est rien, mais c'est un objet qui est créé par le serveur.
C'est à l'aide de cet objet que le serveur effectuera toutes les communications futures avec le client.
C1.
En résumé, le handle n'est rien, mais il représente une connexion du serveur avec le client.
C1.
Supposons maintenant qu'il y ait un autre client C deux.
Il envoie également une nouvelle demande d'établissement de connexion au serveur.
Le serveur transmet la demande d'établissement d'une nouvelle connexion au socket maître.
Après avoir reçu la nouvelle demande d'initiation de connexion à l'aide du socket maître, le serveur crée
un autre handle pour le client C two.
C'est vrai.
Ainsi, chaque fois que le serveur reçoit une nouvelle demande d'initiation de connexion à l'aide de la socket
principale, il crée un nouveau handle pour le client.
C'est pour cette raison que m, c'est-à-dire le socket principal, est la mère de tous les handles clients, c'est-à-dire le socket
principal, qui donne naissance à tous les handles clients.
Ainsi, si deux clients, C1 et C2, sont connectés au serveur, ce dernier disposera
de deux handles clients.
Le serveur doit donc maintenir les deux handles du client en même temps, car il communique désormais avec
les deux clients en même temps.
À ce stade, les clients C1 et C2 ont tous deux établi une connexion complète avec le serveur.
Les clients sont maintenant en mesure d'envoyer des messages de demande de service au serveur.
Supposons donc que le client C2 ait envoyé le message de demande de service au serveur.
Le système d'exploitation qui fonctionne sur le serveur transmet maintenant le message de demande de service directement
à la poignée du client.
Ainsi, le message de demande de service provenant du client C2 sera transmis à la poignée correspondant
au client C2 sur le serveur.
À l'aide de cet identifiant, le serveur traitera la demande du client et lui renverra
la réponse du service à l'aide de l'identifiant C2.
C'est vrai.
Vous pouvez donc voir que la poignée du client sur le serveur est utilisée pour traiter les messages de demande de service
provenant du client.
Après avoir traité le message, la même poignée est utilisée pour renvoyer la réponse du service
au même client.
Ainsi, toutes les communications futures avec le client connecté sont effectuées par la poignée du client, qui a été créée
par le socket maître sur le serveur.
Ainsi, une fois que les numéros de client sont créés pour chaque serveur client, la communication avec le client s'effectue
uniquement à l'aide du numéro de client.
Notez que la socket maître n'est pas impliquée dans le traitement des demandes de service des messages du client.
Les sockets maîtres ne sont pas utilisés pour le service de traitement.
Demander des messages au client.
Le serveur doit maintenir la base de données des clients connectés.
Comme vous pouvez le voir, deux clients sont connectés au serveur en même temps.
Par conséquent, le serveur doit gérer deux clients en même temps.
Ainsi, s'il y a n nombre de clients, le serveur doit maintenir n nombre de gestionnaires de clients afin
de pouvoir communiquer avec chacun d'entre eux de manière indépendante.
Le socket principal n'est utilisé que pour créer de nouveaux handles clients.
C'est vrai.
Vous pouvez voir que le socket maître est utilisé pour traiter uniquement les nouvelles connexions.
Les demandes d'initiation provenant du socket principal du client ne sont pas utilisées pour l'échange de données avec des clients déjà
connectés.
L'échange de données correspond aux messages de demande de service.
Venons-en maintenant à l'appel système accept accept est l'appel système utilisé par le serveur pour créer des
handles clients.
L'appel système accept est donc utilisé par le serveur pour créer de nouveaux handles clients et l'argument de l'appel
système accept est le socket maître.
C'est vrai ?
Dans la terminologie Linux, les handles sont appelés descripteurs de fichiers, qui ne sont rien d'autre que des nombres entiers.
C'est vrai.
Les gestionnaires de clients sont appelés descripteurs de fichiers de communication parce qu'ils sont utilisés pour établir une véritable
communication avec le client.
Il s'agit d'un échange de données, tandis que M est appelé descripteur de fichier de la socket principale.
Ainsi, ce socket M est un maître dans le sens où il est la mère des handles clients.
Pour prendre un exemple, la demande de service pourrait être les deux nombres envoyés par le client
au serveur et le client demande au serveur d'additionner deux nombres.
C'est vrai ?
Lorsque le serveur reçoit ce message du client, il peut additionner les deux nombres et envoyer le résultat.
Retour au client, donc.
Il renverra la somme de A et B au client.
C'est ce qu'on appelle la réponse du service.
C'est ainsi que Linux maintient la communication client-serveur.
L'ensemble de ce tableau décrit donc le cycle de vie d'une communication client-serveur sous Linux.