WEBVTT

00:06.890 --> 00:09.909
So going forward we will be going to discuss

00:12.139 --> 00:14.889
the accept system So we will be going

00:16.279 --> 00:18.279
to write two applications

00:20.610 --> 00:22.610
client dot C And server dot

00:24.070 --> 00:30.120
C Client dot C actually represents a client C and server dot Cactually represents

00:32.800 --> 00:38.790
a TCP server So in file client dot C we will going to implement the functionality

00:38.790 --> 00:42.209
of the client that is the client will going to

00:43.059 --> 00:53.820
initiate the request and In server dot C file will be going to implement the functionality of the TCP server that is receiving the client

00:54.490 --> 00:57.719
correction request receiving the client

00:58.270 --> 01:07.800
data Processing the data and replying back to the client We will go in to implement server functionality in server dot C and

01:12.520 --> 01:16.380
client functionality in client dot C now Let us discuss

01:17.170 --> 01:20.970
the accept system call First of all accept system

01:21.700 --> 01:33.090
call is used by the TCP server that accept system call is used on the server side and What is the purpose of accept system call the accept system call

01:34.060 --> 01:39.960
is used to accept the new client connection request by the server So you have

01:40.750 --> 01:51.719
a client C and you have a server s The

01:51.719 --> 01:51.719
dans

01:51.720 --> 01:56.999
la demande d'initiation de connexion Le client dit qu'il veut établir une connexion

01:57.729 --> 02:00.389
TCP avec vous Il communique cette information

02:04.540 --> 02:11.910
au serveur L'appel système d'acceptation du côté du serveur est utilisé pour accepter la nouvelle demande de connexion

02:13.480 --> 02:16.110
du client C'est le but de l'appel système

02:17.890 --> 02:22.140
d'acceptation Rappelez-vous que TCP est un protocole orienté connexion

02:23.560 --> 02:31.110
C'est-à-dire que le client et le serveur doivent d'abord établir une connexion dédiée avant de pouvoir participer

02:31.120 --> 02:42.480
à toute activité d'échange de données Droit.

02:42.480 --> 02:42.480
La

02:44.110 --> 02:46.260
première chose que le client

02:49.390 --> 02:53.010
et le serveur doivent faire est donc d'établir

02:53.470 --> 02:58.410
une connexion TCP bidirectionnelle Avant tout échange

02:58.930 --> 03:02.249
de données entre le client et le serveur

03:04.330 --> 03:09.779
Le client et le serveur doivent établir une connexion TCP

03:10.450 --> 03:17.939
bidirectionnelle entre eux L'initiation de cette connexion est effectuée par

03:19.630 --> 03:26.850
le client et le client le fait en envoyant une demande d'initiation de connexion

03:27.940 --> 03:32.460
au serveur L'appel système Accept du côté serveur

03:33.700 --> 03:42.300
est en fait utilisé pour traiter la demande d'initiation de connexion déclenchée par le client

03:42.760 --> 03:51.869
Disons, par exemple, que lorsque vous vous connectez à Facebook votre machine envoie des demandes

03:52.540 --> 04:11.040
de connexion aux serveurs Facebook Les serveurs Facebook acceptent votre demande de connexion en utilisant l'appel système Accept Maintenant vous pouvez envoyer des données aux serveurs Facebook

04:11.410 --> 04:20.910
et les serveurs Facebook peuvent mettre à jour votre page avec des notifications et des flux Le seul but

04:22.180 --> 04:31.890
de l'appel système Accept est donc d'établir la connexion entre les deux machines, c'est-à-dire la machine

04:33.040 --> 05:17.758
client et la machine serveur, et cela se fait en effectuant une poignée de main TCP à trois voies S

05:17.758 --> 05:17.758
Qu'est-ce que la poignée ? Le

05:18.430 --> 05:23.519
handle n'est rien, c'est juste une valeur entière, par exemple 6. 6 représente en fait une connexion

05:24.520 --> 05:26.520
dédiée entre le client et le serveur.

05:26.650 --> 05:28.650
En utilisant ce handle, le serveur effectue

05:29.199 --> 05:33.629
toutes les communications futures avec ce client. Ce handle est appelé descripteur

05:34.060 --> 05:40.649
de fichier de communication. C'est pourquoi on l'appelle descripteur de fichier de communication

05:40.840 --> 05:46.979
parce que la communication réelle entre le client et le serveur après l'établissement de la connexion se fait à l'aide

05:48.130 --> 05:50.130
de ce handle C'est pourquoi on l'appelle

05:50.289 --> 05:53.609
descripteur fin de communication Ainsi, vous pouvez voir le diagramme

05:55.930 --> 05:58.530
: vous avez un client et le serveur TCP s'exécute quelque

05:59.620 --> 06:05.070
part dans le réseau. La première chose que fait le client

06:05.590 --> 06:10.079
est d'envoyer une demande d'établissement de connexion

06:10.389 --> 06:16.198
au serveur TCP. Le client envoie la demande d'initiation de connexion en utilisant

06:16.930 --> 06:20.099
l'appel système connect Par conséquent, l'appel système connect

06:21.039 --> 06:26.489
n'est utilisé que du côté client Lorsque le serveur reçoit la demande d'initiation de connexion du client, la deuxième

06:28.000 --> 06:31.440
chose La première chose que fait le serveur est d'accepter la demande de

06:32.289 --> 06:35.339
connexion du client en utilisant l'appel système accept Dès que

06:35.650 --> 06:42.090
l'appel système accept est invoqué, L'appel système accept renvoie le descripteur de fichier de communication Qui n'est rien d'autre

06:43.030 --> 06:45.209
qu'une valeur entière en utilisant ce descripteur

06:46.180 --> 06:52.079
de fichier de communication, le serveur effectue tous les échanges de données avec le client Ainsi, discutons du synopsis

06:59.159 --> 07:02.929
de cet appel système accept ici Vous pouvez voir qu'il s'agit du synopsis de l'appel

07:02.930 --> 07:08.780
système accept. L'appel système accept accepte trois arguments Le

07:09.240 --> 07:12.620
premier argument est la valeur entière qui est le descripteur

07:12.900 --> 07:17.900
de fichier TCP de la socket principale. le deuxième argument de l'appel système

07:18.599 --> 07:20.219
accept est en fait le pointeur

07:20.219 --> 07:27.379
sur la structure de type structs sockaddr star. Il s'agit du type de structure standard fourni par les

07:28.620 --> 07:30.620
API C. Cette structure que vous

07:31.680 --> 07:35.419
passez ici est en fait une structure vide, c'est-à-dire

07:35.969 --> 07:38.389
qu'elle ne contient aucune donnée.

07:38.729 --> 07:42.799
Lorsque le client envoie une demande de connexion au serveur,

07:43.080 --> 07:49.609
il dispose d'une adresse IP et du numéro de port sur lequel il écoute. Ces informations sont stockées

07:50.669 --> 07:52.669
dans la structure d'adresse

07:54.389 --> 08:01.579
du client du côté du serveur. Ainsi, sur le serveur, les informations

08:02.610 --> 08:05.779
du client, à savoir l'adresse IP

08:05.879 --> 08:10.369
et le numéro de port, sont stockées dans cette

08:10.680 --> 08:14.000
structure lorsque la demande de connexion

08:14.789 --> 08:19.968
du client arrive sur le serveur De cette façon, le serveur

08:21.029 --> 08:31.039
est capable de stocker l'identité du client afin que le serveur puisse ensuite répondre au client Le troisième

08:31.560 --> 08:36.919
argument de l'appel système accept est l'adresse len qui

08:38.699 --> 08:48.800
n'est rien d'autre que la taille de cette structure qui est la taille de la structure sockaddr de Struts

08:49.529 --> 08:53.869
et donc le troisième argument est en fait une

08:54.990 --> 09:03.219
constante Le descripteur de fichier master socket est le descripteur de fichier du

09:03.860 --> 09:08.829
socket que le serveur a ouvert pour écouter la nouvelle

09:08.960 --> 09:27.009
demande de connexion du client à l'aide de l'appel système socket Nous allons donc développer davantage ce descripteur de fichier master socket est créé à l'aide de l'appel système socket

09:28.820 --> 09:42.819
et le descripteur de fichier master socket est utilisé par le serveur pour détecter les nouvelles demandes de connexion du client Il est donc utilisé

09:43.430 --> 09:59.170
pour détecter la nouvelle demande de connexion du client à l'aide de l'appel système accept Rappelez-vous que le premier argument de l'appel système accept est

10:00.650 --> 10:17.170
que le descripteur de fichier master socket est le descripteur de fichier master socket qui est utilisé par le serveur pour détecter les nouvelles demandes de connexion

10:17.690 --> 10:30.939
du client

10:30.939 --> 10:30.939
Lorsque

10:33.050 --> 10:40.599
nous ferons un tour de code, nous discuterons de ce type d'appels système. Nous ferons donc un tour de code et vous comprendrez mieux comment différentes choses s'assemblent et fonctionnent ensemble.