Les gars, nous en avons terminé jusqu'à l'appel du système de leçons.
L'étape suivante est l'initialisation et le remplissage de l'ensemble.
Vous pouvez donc voir que nous avons terminé l'appel système de la leçon. Le serveur entre maintenant dans la boucle infinie
pour servir le client.
Le serveur a la propriété d'être toujours en mesure de servir le client.
Le serveur doit donc être monté de 24 en 7 et c'est la raison pour laquelle la logique du serveur est généralement mise en œuvre à l'intérieur
d'une boucle infinie.
Il s'agit d'une boucle.
En ce moment même.
Rappelez-vous que nous avons fixé.
N'oubliez pas que Reed n'est rien, mais qu'il s'agit d'un ensemble de descripteurs de fichiers.
En utilisant la macro FD underscore zero, il s'agit de la macro standard fournie par.
Nous pouvons donc utiliser cette macro pour vider le jeu de lecture.
En d'autres termes, nous initialisons le jeu de descripteurs de fichiers.
Ensuite, nous n'ajoutons que le descripteur de fichier du socket maître à cet ensemble.
La macro à utiliser est donc fd underscore set.
Cette macro ajoutera le descripteur de fichier du socket maître à l'ensemble.
C'est vrai.
À la ligne 91, nous invoquons l'appel système select.
C'est vrai.
Ainsi, au moment où nous atteignons la ligne 91, le jeu de lecture ne contient qu'un seul descripteur de fichier, à savoir le descripteur de
fichier de la socket principale.
En ce moment même.
Examinons le synopsis de l'appel système Select.
Le synopsis de l'appel système Select indique que le premier argument de l'appel système
Select doit être un plus X.
Un plus x, où x est la valeur maximale présente dans l'ensemble des données lues.
C'est vrai.
Il s'agit donc du premier argument de l'appel système select.
Vous pouvez donc voir que dans le jeu de lecture, le seul descripteur de fichier présent est le descripteur de fichier de
la socket maître.
x est donc égal au descripteur de fichier du socket maître.
Le premier argument est donc le descripteur de fichier de la socket principale plus un.
Tel est le résumé de l'appel système de sélection.
C'est vrai.
Les trois arguments suivants de l'appel système select peuvent être passés comme null, null, null.
Il n'est pas nécessaire de discuter des trois autres arguments du système de sélection.
Appel dans ce cours.
Rappelez-vous donc que l'appel système Select est un appel système bloquant.
Au moment où l'appel système select est invoqué, ce processus ou l'exécution de ce programme s'arrête
à la ligne 91.
Vous pouvez constater que le système d'exploitation Linux bloque ce processus jusqu'à ce que les données arrivent sur l'un des descripteurs
de fichiers présents dans l'ensemble de données.
Dans cet exemple, le seul descripteur de fichier présent dans le jeu de lecture est le descripteur de fichier de
la socket maître.
Les descripteurs de fichiers du socket maître sont utilisés pour détecter les nouvelles demandes de connexion émanant de nouveaux clients.
Cela signifie donc que l'appel système select ne surveille que le descripteur de fichier de la socket principale et, comme seul
le descripteur de fichier de la socket principale est surveillé, cela signifie que l'appel système select
est bloqué jusqu'à ce que la nouvelle demande de connexion du client arrive sur ce serveur.
C'est vrai.
Notre serveur est donc bloqué à la ligne 91.
Supposons qu'à un moment donné, un nouveau client envoie une demande d'établissement de connexion
à notre serveur.
Lorsque cela se produit, le processus de notre serveur est débloqué à partir de la ligne 91 et l'exécution
de ce programme reprend.
Ainsi, à la ligne 94, nous vérifions que la macro FD underscore est activée.
Cette macro est donc utilisée pour tester quel descripteur de fichier présent dans le jeu de lecture est activé.
Dans cet exemple, le seul descripteur de fichier possible qui pourrait être activé est le descripteur de fichier
de la socket maître.
Par conséquent, cette condition sera toujours vraie.
Nous aborderons ensuite la mise en œuvre plus complexe du serveur Dhcp.
Dans l'exemple suivant, vous verrez que FD underscore is set est une macro utile et qu'il est nécessaire
de vérifier que l'appel système select est débloqué car quel descripteur de fichier est activé.
Nous devons donc trouver ce descripteur de fichier particulier qui est activé.
Dans cet exemple, il semble évident que nous vérifions le descripteur de fichier de la prise principale
et que nous vérifions si c'est le descripteur de fichier de la prise principale qui est activé.
Et cela semble évident parce que dans le jeu de lecture, le seul descripteur de fichier qui est présent est le descripteur de fichier de la
socket maître.
Quoi qu'il en soit, lorsque cette condition est vraie, cela signifie que notre serveur a reçu de nouvelles demandes de connexion de la part
du nouveau client.
A droite dans ce diagramme.
Nous sommes ici et nous vérifions que le descripteur de fichier de la socket principale est activé.
Donc, dans cet exemple, oui, le descripteur de fichier de la socket principale est activé.
La prochaine chose qu'un serveur doit faire est donc d'établir la connexion avec le client en appelant
l'appel système Accept.
C'est vrai.
Nous en sommes donc à la septième étape : notre serveur invoque l'appel système Accept et, une fois l'appel système Accept
invoqué, la connexion avec le client est censée être établie.
La valeur de retour de l'appel système accept est donc le descripteur de fichier de la socket de communication et c'est à l'aide
de ce descripteur de fichier de la socket de communication que notre serveur effectuera toutes les communications futures avec
le client.
Ce descripteur de fichier de communication représente donc la connexion avec ce client particulier qui
vient de se connecter à notre serveur.
Le deuxième argument de l'appel système accept est le.
Structure vide.
Nous en avons parlé lorsque nous avons abordé le synopsis de l'appel système XRP.
Dès que le client se connecte à notre serveur, cette structure se remplit avec l'adresse
IP et le numéro de port du client.
C'est vrai.
Ainsi, notre serveur sait maintenant avec qui il parle.
C'est vrai.
Notre serveur utilisera donc ces informations pour répondre au client car, en fin de compte, il a besoin
de l'adresse IP du client et du numéro de port pour renvoyer le paquet au client.
Le troisième argument est une constante, qui correspond à la taille de la structure sockaddr.
Ainsi, lorsque l'appel système "accepter" échoue pour une raison quelconque, il renvoie une valeur négative.
Nous vérifions donc simplement que si l'appel système d'acceptation échoue, le processus du serveur
s'arrête.
C'est vrai.
Nous sommes donc ici.
C'est à ce moment-là que le lien avec le client est établi.
Notre processus serveur se contente donc d'imprimer l'identité du client.
Il imprime donc l'adresse IP du client ainsi que le numéro de port du client.
Les API C nous fournissent donc ces fonctions intégrées, à savoir init et to a, qui sont utilisées pour
imprimer l'adresse IP au format dot b dot c dot d.
C'est vrai.
Et nous imprimons le numéro de port du client.
Vous pouvez donc constater que ces étapes sont terminées jusqu'à la septième étape.
En d'autres termes, nous avons invoqué l'appel système select et attendu la demande de connexion
du client, et le serveur a accepté la connexion du client.
La prochaine chose que notre serveur doit faire est d'attendre la demande de données du client, et lorsqu'il reçoit
la demande de données, il traite les données du client et en conséquence il répond
au client avec le résultat.
Voyons donc comment la huitième étape est mise en œuvre.
Le serveur entre à nouveau dans une boucle infinie parce qu'il va parler à ce client indéfiniment
jusqu'à ce que le client envoie des données spéciales au serveur.
En analysant ces données spatiales, notre serveur choisit alors de mettre fin à la connexion avec le client.
C'est vrai.
À ce moment-là, nous sortirons de cette boucle.
Voyons donc cela.
Comment ?
Serveur Échanger les données avec le client.
La première chose que fait le serveur est donc de préparer une mémoire.
Le serveur peut stocker les données envoyées par le client.
C'est vrai.
Une fois que le tampon de données est prêt à se remplir avec les données reçues du serveur, ce dernier
invoque l'appel système "Recevoir de".
La réception de l'appel système est à nouveau un appel système bloquant.
Si vous examinez le synopsis de l'appel système received from, le premier argument de l'appel système receive
from est le descripteur de fichier de communication.
Rappelez-vous donc que toutes les données échangées entre le serveur et le client se produisent sur le descripteur
de fichier de communication et non sur le descripteur de fichier de socket principal.
Le deuxième argument de l'appel système receive from est le.
Tampon de données dans lequel le serveur va stocker les données envoyées par le client.
Le troisième argument est la taille de ce tampon de données.
En d'autres termes, de combien d'octets est constitué ce tampon de données ?
L'argument suivant peut toujours être considéré comme nul.
Nous n'avons pas besoin de discuter de cet argument et.
Le cinquième argument est en fait l'information sur le client que l'appel au système d'acceptation a rempli avec l'information
sur le client.
Le dernier argument est à nouveau la taille de la structure.
Ainsi, lorsque le serveur invoque l'appel système receive from, cela signifie qu'il attend maintenant
la demande de données du client spécifié dans cet argument.
C'est vrai.
Et à moins que le serveur ne reçoive des données de ce client, le serveur restera bloqué sur la réception de l'appel
système.
Il s'agit donc pour l'instant de la ligne 125.
Notre serveur attend maintenant que des données arrivent de ce client.
En ce moment même.
Supposons que le client ait effectivement envoyé des données à notre serveur.
Ainsi, lorsque notre serveur recevra les données de ce client, il sera débloqué de l'appel
système "receive from".
La valeur de retour de l'appel système receive from est le nombre d'octets envoyés par le client.
Ici, nous imprimons simplement le nombre d'octets reçus du client, ainsi que
l'adresse IP du client et le numéro de port.
Ici, nous avons pris comme condition spéciale que si le client nous envoie le nombre zéro d'octets, alors
le serveur considérera que c'est une condition de terminaison.
En d'autres termes, le serveur conclura que le client ne souhaite plus communiquer avec lui.
Le serveur ferme donc la connexion avec ce client particulier et sort de la boucle while
interne.
Mais dans ce cas, supposons que le client ait réellement envoyé des données au serveur.
Les données envoyées au serveur sont donc stockées dans la mémoire tampon.
En ce moment même.