Cette diapositive montre le diagramme de la machine à états d'un serveur TCP.
Nous allons donc examiner toutes les étapes de la mise en œuvre d'un serveur TCP typique.
Les étapes que nous allons aborder seront entièrement conformes à ce schéma d'état.
Nous avons déjà discuté de ce diagramme d'état.
Voyons donc le code et les différentes étapes de la mise en œuvre d'un serveur TCP.
Vous pouvez donc voir que vous devez suivre ces dix étapes pour mettre en œuvre un serveur TCP typique.
Nous allons passer en revue ces étapes une à une et voir comment elles sont mises en œuvre dans la programmation des sockets.
Alors les gars, faisons un tour de code.
J'ai écrit un fichier appelé TCP Server dot C. Vous pouvez voir ici un fichier, TCP server dot C, et dans ce fichier j'ai implémenté
la fonctionnalité d'un serveur TCP.
Je partagerai ce code avec vous dans la section des ressources.
Ouvrons donc ce fichier et voyons comment le serveur TCP est mis en œuvre.
Commençons donc par la grande ligne droite.
C'est vrai.
Commençons donc par la fonction principale.
Dans la fonction principale, vous voyez que je ne fais rien, mais je n'appelle qu'une seule fonction qui est la configuration de la communication
serveur TCP.
Dans cette fonction, j'implémente donc l'ensemble des fonctionnalités d'un serveur TCP.
Discutons donc de cette fonction.
Voici donc le début de cette fonction.
La première étape est donc la phase d'initialisation.
Comme vous pouvez le constater, la première étape consiste uniquement à initialiser les variables.
Ainsi, dans la première étape, nous avons pris toutes les variables requises dont nous aurons besoin pour mettre en œuvre
un serveur Dhcp.
Comme nous l'avons déjà vu, lorsque le serveur démarre, il est possible d'obtenir des informations sur l'état d'avancement de l'installation.
Comme nous l'avons déjà vu, lorsque le serveur démarre, il crée un descripteur de fichier de socket principal
et place ce descripteur de fichier de socket principal dans un ensemble.
Nous avons donc pris une variable de descripteur de fichier de la socket principale qui est à nouveau une valeur entière, n'est-ce pas ?
Pour le reste des variables, nous discuterons du moment où nous les utiliserons.
Nous avons pris un jeu de lecture qui est de type FD, jeu de soulignement.
Il s'agit donc d'un ensemble et comme notre serveur TCP continue à créer des descripteurs de fichiers, notre serveur va ajouter ces descripteurs
de fichiers à cet ensemble.
C'est vrai.
Nous avons pris des variables de type struct soc addr qui sont l'adresse du serveur et l'adresse du client.
Ce type de données, struct sockaddrin, est donc utilisé pour stocker l'identité de la machine.
Il s'agit de l'adresse IP et du numéro de port de notre serveur et du client.
Nous allons donc voir comment utiliser ces variables.
C'est vrai.
Vous pouvez donc voir que dans la première étape, nous devons créer un descripteur de fichier de socket maître et le placer dans le jeu
de lecture.
Vous pouvez voir que dans la deuxième étape, nous devons créer un descripteur de fichier de socket maître.
C'est vrai.
Passons donc à l'étape 2 et vous pouvez voir que nous avons tout de suite créé un descripteur de fichier de
socket maître.
Le descripteur de fichier de la socket principale est donc créé à l'aide de l'appel système de la socket L'appel système de la socket accepte
trois arguments.
La première est la famille d'adresses, car nous avons affaire à des adresses IPv4 et nous devons donc créer
des sockets IPV quatre.
Le premier argument définit donc cela.
Quelle est la famille d'adresses que vous utilisez ?
Ainsi, pour IPV, quatre réseaux passent toujours AF underscore Inet.
Si c'est le cas, si vous travaillez avec six adresses IPV, alors...
Vous auriez dû passer af underscore inet six.
Le deuxième argument que vous devez passer est donc le flux de la socket.
Si vous souhaitez créer une socket TCP.
Le deuxième argument doit être un flux de socket pour les sockets UDP.
Cette valeur doit être soc d gram.
C'est vrai.
Et...
Le troisième argument définit le protocole que vous souhaitez exécuter au sommet de la couche réseau.
Ainsi, au sommet de la couche réseau, nous essayons d'exécuter le protocole TCP.
Le protocole TCP est donc identifié à l'aide de cette constante IP, proto TCP.
Il s'agit donc de socket stream et de proto TCP, tous deux combinés ensemble pour identifier le protocole
TCP.
Pour créer une socket TCP, il faut donc passer le deuxième argument au système de socket, appelé
socket stream.
Et le troisième argument doit être IP proto TCP.
C'est vrai.
Et si vous vouliez créer un socket UDP au lieu de.
Socket TCP.
Le deuxième argument aurait alors été sock underscore d gram.
Et le troisième argument aurait été IP, proto UDP.
C'est vrai.
Ainsi, après la deuxième étape, vous obtiendrez le descripteur de fichier de la socket maître.
Ainsi, après la deuxième étape, la création du descripteur de fichier du socket maître est terminée.
La troisième étape est l'appel système bind.
L'appel au système de liaison est donc ici.
Il s'agit de l'étape trois de l'appel au système de liaison, ce qui signifie que.
Votre processus de serveur.
En d'autres termes, ce serveur Dhcp transmet les critères au système d'exploitation sous-jacent.
du paquet que le serveur veut recevoir.
C'est vrai.
Vous pouvez donc voir que le premier argument de l'appel système bind est le descripteur de fichier de la socket
maître que vous avez créé à l'étape 2.
Le deuxième argument de l'appel système bind est en fait l'identité du serveur, c'est-à-dire l'adresse IP et le numéro
de port du serveur.
Vous pouvez donc voir ici que le serveur a rempli cette variable qui est server underscore addr.
Avec quelques informations.
Voyons donc.
Quelle est cette information ?
La première information renseignée dans cette structure est la famille SIM.
Comme je l'ai dit, pour IPV quatre réseaux vous devez passer un f underscore inet.
C'est vrai.
Notre serveur est donc en fait notre serveur TCP et il doit donc fonctionner sur un numéro de port.
Nous avons donc indiqué le numéro de port du serveur dans server underscore addr dot sin port member, en attribuant simplement la valeur
du numéro de port d'un serveur.
Le numéro de port du serveur est donc en fait une constante définie par hachage et sa valeur est 2000.
Vous pouvez voir qu'il s'agit d'une constante et que sa valeur est 2000.
C'est vrai.
Le troisième élément à remplir dans cette structure est l'adresse IP du serveur.
Aujourd'hui.
Ici, vous pouvez transmettre une adresse IP particulière sous forme d'un nombre entier.
Par exemple, si votre serveur souhaite recevoir un paquet dans lequel l'adresse IP de destination spécifiée est l'adresse IP
du serveur et que cette adresse IP est 192. 168. 56. 101.
Cela signifie qu'il s'agit de l'adresse IP d'un serveur.
L'équivalent en nombres entiers de cette adresse IP est donc cette valeur.
Vous devez donc transmettre cette valeur particulière à ce membre.
Mais ici, vous pouvez voir que j'ai passé quelque chose d'autre qui s'appelle n underscore n.
Qu'est-ce que cela signifie ?
En d'autres termes, supposons que vous disposiez d'un serveur.
Et votre machine serveur peut avoir des interfaces, des interfaces multiples, n'est-ce pas ?
Chaque interface peut avoir une adresse IP comme 2. 1. 1 barre oblique 24.
2. 1. 2. 1 entaille 24.
et 2. 1. 3. 1 entaille 24.
C'est vrai.
Par conséquent, n'importe quelle adresse IP peut appartenir à n'importe quelle interface locale de ce serveur.
Ainsi, chaque fois que le serveur reçoit un paquet dont l'adresse IP de destination est égale à .
adresse IP de n'importe quelle interface locale de ce serveur, alors ce serveur va traiter ce paquet.
C'est vrai.
Et au lieu de dans n'importe quel, avez-vous transmis l'équivalent entier de l'adresse IP ?
2. 1. 2. 1 qui correspond à cette adresse IP.
Ensuite, seul le paquet avec l'adresse IP de destination est pris en compte.
2. 1. 2. 1.
Ensuite, seuls les paquets avec l'adresse IP de destination sont pris en compte.
2. 1. 2. 1 aurait été transmis à votre processus serveur fonctionnant dans la couche application par la
couche socket.
En fait, l'ADR de soulignement du serveur est une structure qui est remplie avec l'identité de la machine serveur.
Il s'agit de l'adresse IP.
Et le numéro de port et parce que votre machine serveur peut avoir plusieurs adresses IP.
Qui est l'adresse de chaque interface du serveur.
C'est donc le serveur qui choisit l'adresse IP avec laquelle il veut recevoir le paquet.
Ainsi, si vous indiquez addr underscore any, cela signifie que le serveur souhaite recevoir le paquet dont l'adresse
IP de destination est égale à l'adresse IP de n'importe quelle interface locale du serveur.
Ainsi, tant que l'adresse IP du paquet est égale à l'adresse IP d'une interface locale de ce serveur, la couche
"socket" de la pile TCP IP se chargera de transmettre le paquet au processus du serveur qui s'exécute dans la couche
"application".
C'est vrai.
C'est donc quelque chose qu'il faut comprendre.
Il faut alors une constante comme underscore Len qui est égale à la taille de la structure socket ADR.
Nous allons donc voir comment cette constante est utilisée.
Nous voici donc à la troisième étape, où l'appel système bind est lancé.
Le premier argument de l'appel système bind, comme je l'ai dit, est le descripteur de fichier de la socket principale.
Le deuxième argument de l'appel système bind est l'information sur le serveur.
En d'autres termes, le serveur transmet au système d'exploitation l'information qu'il est un serveur et qu'il souhaite
recevoir le paquet avec l'adresse IP.
2. 1. 2. 1 par exemple.
C'est vrai.
Et vous pouvez voir que nous avons rempli cette structure avec le numéro de port également.
Le serveur indique donc également au système d'exploitation que je souhaite recevoir un paquet dans
lequel le numéro de port TCP spécifié dans l'en-tête de transport est 2000.
C'est vrai.
Ainsi, avec l'appel système bind, le serveur transmet au système d'exploitation.
N'oubliez pas que le serveur s'exécute dans la couche d'application et que le système d'exploitation s'exécute sous la couche
d'application.
Le serveur transmet donc au système d'exploitation l'information selon laquelle je suis un serveur avec une adresse IP,
bla bla bla.
Et si vous recevez un paquet avec l'adresse IP, bla bla bla et le numéro de port x, y, z alors s'il vous plaît
livrez ces paquets à moi.
C'est donc le concept de l'appel système bind.
L'étape suivante est l'appel au système d'écoute.
Par l'intermédiaire de l'appel système listen, le processus serveur demande au système d'exploitation de maintenir une file d'attente de longueur
maximale.
Cinq parce que nous avons passé cinq comme deuxième argument à l'appel système de la leçon et avec l'appel système de la leçon
le processus du serveur.
Le processus serveur demande au système d'exploitation sous-jacent de maintenir une file d'attente de longueur cinq.
Qu'est-ce qui fait que c'est possible ?
Le serveur peut recevoir des demandes de connexion ou des demandes de données de la part du client C1.
Client C2.
Le client C3 et le client disent C9.
Vous voyez donc que le serveur peut recevoir une demande de connexion ou de données de la part d'un nombre quelconque de clients
en même temps.
Ainsi, lorsque les demandes arrivent en même temps, le système d'exploitation maintient une file d'attente de longueur
cinq et, parce que les neuf demandes arrivent en même temps, le système d'exploitation ne met en file
d'attente que cinq d'entre elles et abandonne les autres.
Oui, parce que vous ne voulez pas que le système sur lequel tourne le processus serveur soit submergé
ou surchargé par un grand nombre de demandes simultanées émanant d'un grand nombre de clients.
C'est donc l'objectif de l'appel de système d'écoute.