WEBVTT 00:04.950 --> 00:12.660 So guys, in this slide, we will going to study the state machine for socket based client server communication. 00:15.180 --> 00:22.770 Now understanding the state machine is important because once you understand the state machine, you 00:22.770 --> 00:31.320 will be able to easily understand the code to implement socket based communication between the client 00:31.320 --> 00:32.790 and the server process. 00:33.450 --> 00:42.210 Second thing is that you will be able to picturise the implementation of client server design in your 00:42.210 --> 00:42.990 mind. 00:43.260 --> 00:49.980 So you can see in this diagram here you have a server process and the blank server process actually 00:49.980 --> 00:50.940 represents that. 00:50.940 --> 00:55.560 The server process is not aware that how to do socket programming. 00:57.950 --> 01:04.460 So let us try to understand that, how actually the server process state machine is designed. 01:05.390 --> 01:11.390 So you can see that the very first thing your server does that is when the server boots up. 01:11.630 --> 01:17.000 That is, as soon as you run the server process, the very first thing the server is supposed to do 01:17.000 --> 01:20.150 is to create a connection socket. 01:21.390 --> 01:26.490 Now connection socket is also called as master socket file descriptor. 01:26.580 --> 01:32.820 And this master socket file descriptor is created using socket system call. 01:34.690 --> 01:40.570 So you can see that the first thing your server does is to create a master socket file descriptor. 01:41.200 --> 01:46.540 And this master socket file descriptor is created using socket system call. 01:46.930 --> 01:50.290 So now you know what is the use of socket system call? 01:52.350 --> 01:56.730 The socket system call is used to create a master socket file descriptor. 01:56.760 --> 01:57.730 Now why? 01:57.750 --> 02:00.630 Actually, it is called master socket file descriptor. 02:00.900 --> 02:06.420 Is it blessed with some special privileges as compared to other socket? 02:06.450 --> 02:09.120 Let us try to understand this point. 02:09.480 --> 02:11.910 Now suppose there is a client C1. 02:12.210 --> 02:12.750 A client? 02:12.780 --> 02:19.620 C1 could be a process that is running on the same machine, or it could be running somewhere else on 02:19.620 --> 02:21.540 other machine in the network. 02:21.780 --> 02:24.810 So you can see that as soon as you have a client. 02:24.840 --> 02:31.500 C1 And client C1 wants to set up a communication with the server, the very first thing the client C1 02:31.500 --> 02:36.690 does is to send a new connection initiation request to the server. 02:37.560 --> 02:38.010 Right. 02:38.010 --> 02:45.600 And you can see that as soon as the new connection initiation request is received by the server, the 02:45.600 --> 02:51.690 operating system diverts such request to the master socket file descriptor, which is created by the 02:51.690 --> 02:52.320 server. 02:53.490 --> 02:59.820 So remember master socket file descriptor always receives the new connection initiation request from 02:59.820 --> 03:00.870 the new client. 03:01.350 --> 03:08.910 So in the next step, as soon as the server receives the new connection initiation request from the 03:08.910 --> 03:17.760 new client, the next thing that the server does is to create a client handle so you can see that server 03:17.760 --> 03:19.470 has created a handle. 03:19.470 --> 03:20.880 C1 For the client. 03:20.910 --> 03:21.630 C1. 03:21.960 --> 03:29.610 Now what exactly handle is handle is nothing, but it is a connection identifier of the client. 03:29.640 --> 03:36.720 C1 That is, the server knows that in order to carry out data exchange with the client. 03:36.750 --> 03:39.010 C1 it has to use the handle. 03:39.040 --> 03:39.670 C1. 03:40.240 --> 03:45.250 So handle is nothing, but it is just a representation of a connection with the client. 03:48.240 --> 03:49.350 Going forward. 03:49.380 --> 03:57.780 Suppose there is another client, C2, that pops up from somewhere and this client, C2, also send 03:57.780 --> 04:00.840 a new connection initiation request to the server. 04:01.260 --> 04:07.620 The operating system that is running on the server diverts the new connection initiation request always 04:07.620 --> 04:09.540 to the master socket file descriptor. 04:10.080 --> 04:11.790 The master socket file descriptor. 04:11.790 --> 04:14.670 Then create a new handle for the client C2. 04:15.720 --> 04:16.350 Right. 04:16.470 --> 04:24.060 So you can see that there will be as many handles, as many clients are there, and server has to maintain 04:24.060 --> 04:29.190 a database of such handles which corresponds to the connected clients. 04:31.050 --> 04:38.220 So you can conclude from here that M that is the master socket is actually the mother of all client 04:38.250 --> 04:44.280 handles because it is the master socket which gives birth to the client handles. 04:46.620 --> 04:50.250 Client handles are also called as data sockets. 04:51.130 --> 04:53.770 So these are data sockets. 04:57.530 --> 04:58.160 Right. 04:59.040 --> 05:00.750 Now going forward. 05:02.010 --> 05:06.240 Now, at this point of time, both the client C1 and C2. 05:07.200 --> 05:12.090 Has successfully established a connection with the server. 05:13.170 --> 05:19.020 Now they are in the position to send a second type of message called service request message to the 05:19.020 --> 05:19.680 server. 05:20.070 --> 05:26.400 So you can see that the client C2, has actually sent a service request message to the server. 05:27.180 --> 05:35.370 When the server operating system receives the service request message from the connected client, the 05:35.370 --> 05:38.790 operating system diverts service request message. 05:39.820 --> 05:43.930 Always to the handle which corresponds to that client. 05:44.680 --> 05:51.400 So you can see that the service request message from the client, C2, is actually diverted or received 05:51.400 --> 05:55.060 by the handle corresponding to the client C2 only. 05:55.750 --> 06:02.590 And once the server receives the service request message, it can now process the service request message 06:02.590 --> 06:06.280 and response back to the client. 06:06.850 --> 06:09.910 This response is called Service response. 06:11.070 --> 06:18.420 Right, because at the end of the day, the server has to fulfill the request of the client and that 06:18.420 --> 06:22.710 is what the goals of servers are to provide services to the clients. 06:24.230 --> 06:31.250 So you can see that once the client handles are created for each client server carries out communication. 06:31.250 --> 06:35.660 That is actual data exchange with the client using client handle. 06:36.020 --> 06:43.850 So note that here the purpose of master socket file descriptor was to create only client handles. 06:44.390 --> 06:52.070 Master socket file descriptor is not used to process service request messages received from the client. 06:52.190 --> 06:57.530 That is a job of the corresponding client handles or data sockets. 06:59.270 --> 06:59.840 Right. 06:59.840 --> 07:04.160 And here you can see that because there are two clients which are connected to our server. 07:04.190 --> 07:08.110 Therefore, our server had to create two client handles. 07:08.150 --> 07:13.220 So basically our server has to maintain a database of active client handles. 07:14.270 --> 07:15.050 Right? 07:15.230 --> 07:22.070 So going forward, that is the master socket file descriptor is only used to create new client handles. 07:22.400 --> 07:28.640 M is not used for any normal data exchange with already connected clients. 07:28.790 --> 07:34.460 So note that this point, this is the speciality of the master socket file descriptor that they are 07:34.460 --> 07:42.980 not used for data exchange with the client master socket file descriptors are used only to establish 07:42.980 --> 07:45.110 new connection with the new clients. 07:47.160 --> 07:48.720 Right now. 07:49.140 --> 07:55.520 Now, next step is that except system call is used on the server side to create client handles. 07:55.530 --> 08:02.640 So how actually the server creates the client handles server, creates a client handles using accept 08:02.640 --> 08:03.600 system call. 08:06.080 --> 08:11.900 And the argument to this accept system call is the master socket file descriptor. 08:13.890 --> 08:14.490 Right. 08:14.490 --> 08:17.880 So the end goal of except system call is to. 08:19.000 --> 08:25.030 Complete the process of connection establishment between the server and the client. 08:25.630 --> 08:32.710 So the first goal of accept system call is to complete the connection establishment process between 08:32.710 --> 08:36.010 the server process and the client process. 08:36.280 --> 08:43.780 And the second goal of Accept system call is to create a client handle using which the server can carry 08:43.780 --> 08:46.570 out future data exchange with the client. 08:47.480 --> 08:53.720 So in Linux terminology, you can see that handles are actually called file descriptors, which are 08:53.720 --> 08:55.610 just positive integer numbers. 08:56.240 --> 08:56.810 Right. 08:56.810 --> 09:03.980 So when I talk about client handles, one client handles C2, they will be actually positive integer 09:03.980 --> 09:04.840 numbers. 09:04.850 --> 09:08.290 For example, it could be six, it could be seven. 09:08.300 --> 09:12.770 In fact, master socket file descriptor could be nine and so on. 09:12.920 --> 09:17.000 So end of the day, the file descriptors are nothing but integer numbers. 09:19.510 --> 09:26.770 Client handles are called communication file descriptors or data sockets, and M is called master socket 09:26.770 --> 09:30.880 file descriptors or, or connection sockets. 09:31.300 --> 09:38.140 So now you have an understanding that how actually socket based communication between server and several 09:38.140 --> 09:39.700 clients takes place. 09:42.140 --> 09:44.420 Right for each particular client. 09:44.420 --> 09:50.420 The server creates a temporary handle and it puts that handle in its database. 09:52.050 --> 09:59.490 Here database could be any data structure which could store multiple client handles and let it be array, 09:59.520 --> 10:02.310 link list, tree or anything. 10:03.120 --> 10:08.280 Another thing to note here is that here operating system is doing one important task. 10:08.520 --> 10:12.630 That is it is doing the task of diversion. 10:13.260 --> 10:19.770 Diversion means when connection initiation request arrives from the client, the operating system diverts 10:19.770 --> 10:22.470 that request to the master socket file descriptor. 10:22.470 --> 10:29.730 And if service request message arrives from the already connected client, then the operating system 10:29.730 --> 10:33.570 diverts those requests to the corresponding client handles. 10:34.080 --> 10:41.370 So you will understand all these concepts better when you will be actually writing a socket based communication, 10:41.370 --> 10:45.360 which will definitely cover as a part of this module.