Bienvenue à tous.
Nous allons maintenant aborder les étapes de la mise en œuvre d'un client TCP.
Vous pouvez donc voir que vous devez mettre en œuvre les huit étapes suivantes afin d'implémenter un programme client
TCP.
La mise en œuvre d'un client TCP est donc beaucoup plus simple que celle d'un serveur TCP.
Nous ferons une promenade dans le code et nous couvrirons toutes les étapes de l'implémentation d'un client TCP.
Les huit étapes suivantes comprennent donc l'initialisation des variables.
Indiquez ensuite les informations d'identification du serveur.
En d'autres termes, le programme client doit connaître l'adresse IP et le numéro de port du serveur afin de se
connecter au processus serveur, car l'adresse IP identifie de manière unique la machine serveur, qui peut se trouver n'importe
où sur le réseau, et le numéro de port TCP permet d'identifier de manière unique un processus serveur s'exécutant sur cette machine.
C'est vrai.
Ainsi, une fois que le client TCP sait quelle machine serveur il doit connecter avec le client TCP, il crée
un socket de communication.
C'est à l'aide de ce socket que la machine cliente effectue tous les échanges de données avec le serveur.
Lors de la quatrième étape, le client, après avoir créé un socket, envoie la demande d'établissement de la connexion
au serveur.
C'est vrai.
Ainsi, après la quatrième étape, la connexion entre le client et le serveur est entièrement établie.
Ensuite, dans les cinquième et sixième étapes, le client TCP peut échanger ses données avec le serveur TCP et, une fois que le
client a terminé toutes sortes d'échanges de données avec le serveur, le client TCP peut choisir de fermer la
connexion et, dans le cas contraire, le client TCP veut communiquer avec le serveur et souhaite échanger
davantage de données avec le serveur TCP.
Ensuite, à partir de l'étape huit, le client TCP peut passer directement à l'étape cinq.
C'est vrai.
Il s'agit donc d'une machine à états très simple pour un client TCP.
Nous allons parcourir le code et voir comment ces huit étapes sont mises en œuvre dans un programme client TCP.
Passons donc en revue ces étapes une à une.
La fonctionnalité du client TCP est donc mise en œuvre dans le fichier TCP client dot C.
Je vous communiquerai le chemin d'accès à ce fichier afin que vous puissiez le télécharger et l'exécuter sur votre machine.
Je vais donc partager ce code dans la section des ressources.
Passons donc en revue ce dossier.
Commençons donc par la fonction principale.
Ainsi, toute la fonctionnalité du client TCP est mise en œuvre dans la fonction de configuration de la communication TCP.
Entrons donc dans cette fonction et voyons ce que nous y avons implémenté.
Nous avons donc pris une variable locale dans cette fonction que nous utiliserons pour implémenter un programme
client TCP.
C'est vrai.
Nous discuterons donc de l'utilisation de ces variables lorsque nous les utiliserons réellement.
C'est vrai.
Ce LAN contient une valeur constante, qui n'est rien, mais qui correspond à la taille de la structure socket.
DDR Droit, Droit.
Nous n'avons donc rien à discuter dans la phase d'initialisation.
La deuxième étape consiste à spécifier les informations d'identification du serveur.
En d'autres termes, le client TCP doit savoir à quel serveur il souhaite se connecter.
Les informations d'identification comprennent donc l'adresse IP du serveur TCP et le numéro de port.
Vous pouvez donc voir que pour enregistrer l'adresse IP du serveur et le numéro de port, nous avons pris la variable
de type struct sockaddrin, qui est la structure C standard fournie par les API C, bien sûr.
C'est vrai.
À l'intérieur de cette structure, nous spécifierons les informations d'identification du serveur.
Nous devons donc remplir les trois membres de cette structure.
Le premier membre est la famille Syn.
C'est le type de famille d'adresses que nous utiliserons puisque nous mettons en œuvre les sockets IPv4.
Par conséquent, vous devez passer ici un inet f underscore.
C'est vrai ?
Si vous utilisez des sockets ipv6, vous auriez dû passer un f underscore inet six.
La prochaine chose que vous devez spécifier est le numéro de port du serveur.
Le port n'est donc rien, mais c'est le numéro de port du serveur.
Vous pouvez donc voir que le port de destination a été initialisé à la valeur 2000.
C'est vrai.
Nous avons donc spécifié le numéro de port du serveur et la prochaine chose que nous devons spécifier est l'adresse
IP du serveur.
Les deux lignes suivantes, c'est-à-dire les lignes 40 et 41, sont utilisées pour spécifier l'adresse
IP du serveur.
Donc l'adresse IP du serveur.
Dans ce cas, nous avons pris 127 . 0. 0. 1.
Il s'agit donc d'une adresse IP spéciale.
Il s'agit de l'adresse IP d'une machine actuelle.
sur lequel vous allez exécuter ce programme.
C'est vrai.
En fait, votre serveur fonctionnera sur la base d'une adresse IP.
127. 0. 0. 1 et votre programme client se connectera au serveur sur cette adresse IP.
En fait, les programmes du serveur et du client s'exécutent sur la même machine.
C'est vrai.
Vous pouvez exécuter les programmes client et serveur dans des terminaux distincts sur votre machine virtuelle.
Pour cela, vous devez faire fonctionner le serveur avec une adresse IP.
127 . 0. 0. 1.
C'est vrai.
Vous pouvez donc voir que nous avons spécifié le numéro de port du serveur ainsi que l'adresse IP du serveur.
Vous devez utiliser cette API pour obtenir le .
Pour spécifier l'adresse IP du serveur telle qu'elle est.
C'est vrai.
Ainsi, les décès dans l'ADR stockent finalement l'adresse IP du serveur dans un format entier.
L'étape suivante consiste à créer un socket de communication.
Notre client doit donc maintenant créer un socket de communication afin de pouvoir communiquer
avec le serveur.
Pour créer un descripteur de fichier de socket de communication, il faut donc utiliser un système de socket et appeler.
Le premier argument à transmettre est la famille d'adresses.
Et comme nous créons un client TCP, les deuxième et troisième arguments doivent être socket stream
et IP proto TCP.
Le deuxième argument identifie le type de socket que vous créez.
Vous créez donc une socket TCP.
Spécifiez donc le flux de socket et le protocole de couche de transport que vous essayez d'utiliser est le protocole
TCP.
L'identifiant du protocole TCP est donc IP, proto TCP.
Il s'agit donc de constantes fournies par les API du réseau.
Ensuite, dans la quatrième étape, vous devez vous connecter au serveur.
C'est vrai.
En effet, notre client TCP a créé un socket et peut maintenant envoyer une demande de connexion.
Il s'agit de la demande d'établissement de la connexion au serveur.
En effet, notre serveur connaît maintenant l'adresse IP et le numéro de port du serveur auquel il veut se
connecter.
L'étape suivante n'est donc rien d'autre que l'envoi par notre client TCP d'une demande d'établissement de connexion au serveur à
l'aide de l'appel système connect.
Vous pouvez voir que dans l'appel système connect, le premier argument est le descripteur de fichier de la socket,
qui a été créé à l'étape précédente.
Le deuxième argument contient les informations d'identification du serveur auquel le client veut se connecter.
Il s'agit de l'adresse IP et du numéro de port.
Le troisième argument est une constante qui représente la taille de la structure struct socket.
C'est vrai.
Ainsi, après l'invocation de l'appel système Connect, la connexion entre le client TCP et le serveur TCP
a été établie.
Notre client est maintenant en mesure d'échanger des données avec le serveur TCP.
Vous pouvez donc voir qu'à l'étape cinq, notre client TCP peut envoyer des données au serveur et à l'étape six.
Notre client TCP peut effectivement recevoir les données du serveur.
À l'étape suivante, le client TCP invite l'utilisateur à saisir les valeurs de A et de B. Ces valeurs
servent donc de données au client TCP, qui les envoie au serveur pour traitement.
C'est vrai.
Ainsi, une fois que l'utilisateur a saisi la valeur de A et B, le client TCP utilise l'appel système "send to" pour envoyer
les données au serveur en vue de leur traitement.
Vous pouvez donc voir cela dans l'appel au système "send to".
Le premier argument est le descripteur de fichier de communication, que le client TCP a créé à l'aide de l'appel
système socket.
Et le deuxième argument est la structure qui porte la valeur de A et B.
Le troisième argument est la taille des données que vous envoyez au serveur.
Le quatrième argument peut toujours être considéré comme nul.
Le cinquième argument est l'identifiant du serveur.
Il s'agit de l'identité du serveur auquel le client essaie d'envoyer les données.
C'est vrai.
Et le dernier argument n'est rien mais c'est la valeur constante qui est la taille de la structure socket.
Vous pouvez donc voir que le client TCP a envoyé les données au serveur TCP en utilisant l'appel système send to. La valeur
de retour de l'appel système send to est en fait le nombre d'octets que le client TCP a envoyé au
serveur.
En ce moment même.
Après avoir envoyé les données au serveur, le client TCP doit attendre la réponse du serveur.
Pour ce faire, le client TCP invoque l'appel système "Recevoir de" et se souvient que l'appel système "Recevoir de" est un appel
système bloquant, ce qui signifie que le programme client ne s'exécutera pas au-delà de ce point jusqu'à ce que les données arrivent sur
la socket en provenance du serveur.
Le client TCP se bloque donc ici et restera bloqué jusqu'à ce que les données du serveur TCP arrivent.
C'est-à-dire que la réponse du serveur TCP est reçue.
Vous pouvez donc voir dans la réception de l'appel système.
Le deuxième argument est la mémoire tampon dans laquelle la réponse reçue du serveur
sera copiée.
Et qui copiera cette réponse ?
La couche transport est chargée de copier la réponse du serveur dans ce tampon.
C'est vrai.
La valeur de retour de l'appel système receive from est donc à nouveau le nombre d'octets reçus
du serveur.
Et dans la dernière, nous imprimons simplement la valeur reçue du serveur.
Souvenez-vous donc que la fonction de notre serveur TCP était de recevoir la valeur de A et B du client.
Additionner ces deux valeurs et renvoyer la somme de ces deux valeurs au client.
Ici, nous imprimons simplement le résultat reçu du serveur Dhcp, qui est
l'addition des valeurs A et B, et après cela, notre client TCP veut continuer à communiquer avec le serveur TCP.
En d'autres termes, il souhaite envoyer deux autres valeurs de A et B au serveur.
Pour cela, notre client TCP entre dans la boucle en utilisant l'appel système "go to".
Vous êtes libre d'implémenter cette boucle en utilisant une boucle for ou while ou n'importe quelle autre méthode.
Ainsi, le client TCP demande à nouveau deux valeurs à l'utilisateur et, après avoir obtenu ces deux valeurs, le client
TCP utilise l'appel système "send to" et envoie à nouveau ces deux valeurs au serveur, qui les reçoit.
Ces deux valeurs calculent le résultat et le renvoient au client TCP.
Le client TCP reçoit la réponse à l'aide de l'appel système "receive from".
Le client TCP revient à la charge et demande à nouveau à l'utilisateur de fournir deux autres valeurs, et ainsi de suite.
Vous pouvez donc constater que les étapes de la mise en œuvre d'un client TCP sont relativement simples.
Dans le client TCP.
Vous remarquez que nous n'avons spécifié nulle part le numéro de port TCP à utiliser par le client TCP.
C'est donc le cas.
Il n'y a donc pas d'attribution de numéro de port par le programmeur.
Souvenez-vous, lorsque nous avons créé le serveur TCP, l'utilisateur qu'est le programmeur a dû spécifier explicitement
le numéro de port sur lequel le serveur TCP est censé écouter.
Mais ce n'est pas le cas pour le client TCP.
La raison en est que le client TCP, lorsqu'il envoie l'appel système correct au serveur, le système d'exploitation
attribue automatiquement un numéro de port TCP à notre client TCP.
Et cette valeur est choisie dynamiquement par le système d'exploitation.
Lorsque nous ferons une démonstration de ce programme, vous verrez que le système d'exploitation attribue
dynamiquement un numéro de port TCP au client TCP.
La deuxième chose à noter ici est qu'il n'y a pas de concept d'appel système bind du côté du client TCP, n'est-ce
pas ?
De plus, il n'est pas nécessaire de maintenir un jeu de lecture ou un jeu de descripteurs de fichiers du côté du client.
Vous remarquerez également que nous n'avons pas utilisé de descripteur de fichier dans ce bloc de code.
La raison en est que notre client TCP ne communique qu'avec un seul serveur TCP, n'est-ce pas ?
Si notre client TCP communiquait avec plusieurs serveurs TCP en même temps, il devrait maintenir plusieurs
descripteurs de fichiers de sockets, chacun d'entre eux étant utilisé pour communiquer
avec un serveur TCP.
C'est vrai.
Ce n'est donc pas comme si le client Dhcp n'avait pas besoin d'utiliser le jeu de descripteurs de fichiers.
En fait, toute machine, qu'il s'agisse d'un client ou d'un serveur, si elle communique avec
d'autres machines multiples, doit maintenir plus d'un descripteur de fichier de communication.
Pour ce faire, la machine doit utiliser le jeu de descripteurs de fichiers.
Vous pouvez également remarquer qu'il n'y a pas de concept d'acceptation d'appel système.
L'appel système accept est destiné uniquement aux serveurs TCP qui acceptent la demande d'initiation du client.
Alors les gars, faisons maintenant une démonstration de ce programme client Dhcp et serveur Dhcp dont nous avons parlé.