WEBVTT 00:05.180 --> 00:12.710 So guys, after having understanding the concept of select system call set data structure and the concept 00:12.710 --> 00:20.960 of accept system call, now we are in a position to actually understand how the select and accept system 00:20.960 --> 00:26.660 call actually works together in order to implement the concept of multiplexing. 00:27.320 --> 00:36.680 So let us try to understand how select and accept system call collaboratively works together to implement 00:36.680 --> 00:38.120 a multiplex server. 00:39.050 --> 00:45.620 So multiplex server means a server which has the capability to handle multiple client connections at 00:45.620 --> 00:46.580 the same time. 00:46.880 --> 00:52.520 So in this diagram you can see that we have a client C1 and we have a client, C2 and we have a server 00:52.520 --> 00:54.380 process which has started. 00:54.380 --> 01:00.650 And as we know that as soon as the server process starts, the very first thing our server process does 01:00.650 --> 01:08.130 is to create a master socket file descriptor and place that master socket file descriptor in a set data 01:08.130 --> 01:08.900 structure. 01:08.910 --> 01:15.300 And as our process has now invoked the select system call on set data structure. 01:16.650 --> 01:20.100 So at this point of time, our server has done three things. 01:20.100 --> 01:25.020 That is, our server process has booted up and created a master socket file descriptor. 01:25.140 --> 01:30.900 Second thing, our server has placed that master socket file descriptor in a data structure. 01:30.900 --> 01:36.810 And the third thing our server has invoked the select system call on set data structure. 01:37.790 --> 01:44.630 Right now since the set data structure at this point of time contains only one file descriptor and that 01:44.630 --> 01:52.460 is master socket file descriptor and the purpose of master socket file descriptor is to detect new connection 01:52.460 --> 01:55.160 initiation requests from new client. 01:55.840 --> 01:58.870 Since the select system call is a blocking system call. 01:58.900 --> 02:06.340 Therefore, our server process is now waiting for new connection initiation requests from new client. 02:07.360 --> 02:12.550 So this is exactly the state our server process is currently in. 02:15.610 --> 02:19.780 So here you can see that this represent set data structure. 02:20.750 --> 02:27.290 And at this point of time, this data structure has only one file descriptor as its member, and that 02:27.290 --> 02:29.180 is master socket file descriptor. 02:30.360 --> 02:35.110 Now suppose the client C1 wants to carry out communication with our server. 02:35.130 --> 02:41.730 So the client C1 sends the connection initiation request to our server by invoking the connect system 02:41.730 --> 02:42.270 call. 02:42.600 --> 02:48.570 As soon as the server detects that it has received connect system call the select system call of the 02:48.570 --> 02:50.490 server will get unblocked. 02:51.850 --> 02:58.000 Now since the server is unblocked because it has received the connection initiation request from new 02:58.000 --> 02:58.780 client. 02:58.810 --> 03:03.880 The second step that the server will do is to invoke the accept system call. 03:04.210 --> 03:10.540 And by invoking the accept system call the server will generate a communication file descriptor for 03:10.540 --> 03:14.410 client C1 using this communication file descriptor. 03:14.440 --> 03:18.910 Our server will carry out actual data exchange with the client C1. 03:19.580 --> 03:22.580 For the rest of the lifetime of this connection. 03:25.600 --> 03:31.510 In addition, when the server has generated this communication file descriptor for client one, the 03:31.510 --> 03:38.820 server will save this communication file descriptor in set data structure so you can see that in set 03:38.830 --> 03:42.130 data structure along with the master socket file descriptor. 03:42.160 --> 03:45.400 A new communication file descriptor is also added. 03:47.990 --> 03:54.260 So you can see in this diagram that when the server booted up, it created a master socket file descriptor 03:54.260 --> 03:58.970 and it placed this master socket file descriptor in set data structure. 03:59.000 --> 04:03.920 Now here the set data structure is denoted by read variable. 04:05.780 --> 04:07.310 So Reid is nothing. 04:07.310 --> 04:13.310 But it is set data structure and the server invoked the select system call. 04:13.580 --> 04:14.330 Right. 04:15.110 --> 04:22.130 And after that, when the server received the new connection initiation request, then the server will 04:22.130 --> 04:24.590 get unblocked from the select system call. 04:24.770 --> 04:30.860 And here the server will check that whether it is master socket file descriptor which is activated. 04:31.250 --> 04:32.030 Yes. 04:32.030 --> 04:37.850 If the master socket file descriptor is activated, it means that the server has received new connection 04:37.850 --> 04:39.860 initiation request from new client. 04:39.950 --> 04:45.380 So the next thing that the server does is to invoke the accept system, call and create a communication 04:45.380 --> 04:50.120 file descriptor for that new client which has just connected to our server. 04:50.390 --> 04:57.080 And the next thing our server does is to add this communication file descriptor to the set data structure. 04:59.250 --> 04:59.850 Right. 04:59.850 --> 05:02.760 And then the server goes back again and again. 05:02.760 --> 05:06.600 It invokes the select system call on set data structure. 05:08.210 --> 05:14.540 Right now at this point of time, our feed data structure contains two file descriptors that is master 05:14.540 --> 05:20.360 socket file descriptor and the communication file descriptor which has which it has just created for 05:20.360 --> 05:21.470 this new client. 05:22.760 --> 05:30.140 So coming back to this diagram, after adding this communication file descriptor to the set data structure, 05:30.140 --> 05:36.060 our server process again invokes the select system call on the updated set data structure. 05:36.080 --> 05:41.360 Now, at this point of time, this set data structure contains two file descriptors. 05:41.360 --> 05:45.860 One is master socket file descriptor and the other is communication file descriptor. 05:45.890 --> 05:54.560 Now monitoring the two file descriptors at the same time means that if the new client sends new connection 05:54.560 --> 06:02.900 initiation request to our server, our select system call will get unblocked because master socket file 06:02.900 --> 06:04.640 descriptor will be activated. 06:05.030 --> 06:13.010 In other case, if the client see one which is already connected to our server sends data request to 06:13.010 --> 06:17.930 our server, then it will be communication file descriptor which will be activated. 06:19.360 --> 06:24.130 So you can see because Select System Call is now monitoring two file descriptors. 06:24.190 --> 06:26.800 Which file descriptor will be activated? 06:26.800 --> 06:32.110 Depends whether client C one sends data request to our server or. 06:32.910 --> 06:36.960 New client sends new connection initiation request to our server. 06:37.080 --> 06:42.720 In the first case it is communication file descriptor which will be activated and in the second case 06:42.720 --> 06:46.020 it will be master socket file descriptor which will be activated. 06:49.010 --> 06:55.580 So you can see in this diagram that when the client C2 sends connection initiation requests to our server, 06:55.610 --> 07:01.610 our server will invoke the accept system call because our server will get unblocked from the select 07:01.610 --> 07:02.480 system call. 07:02.480 --> 07:06.620 And the reason being that master socket file descriptor is activated. 07:07.160 --> 07:13.100 So the return value of accept system call is again a communication file descriptor and this communication 07:13.100 --> 07:18.440 file descriptor will be used by our server process to carry out future communication with the client. 07:18.440 --> 07:19.100 C2. 07:19.880 --> 07:26.480 And in addition to this, our server process will add this communication file descriptor to set data 07:26.480 --> 07:27.230 structure. 07:29.510 --> 07:36.990 And again, our server process goes back and invoke the select system, call on updated set data structure. 07:37.010 --> 07:43.010 Now at this point of time, our server process is now monitoring three file descriptors, the master 07:43.010 --> 07:46.790 socket file descriptor and the two communication file descriptors. 07:47.180 --> 07:54.650 It means that our server process is in a state where it can process new connection initiation requests 07:54.650 --> 08:03.830 from new client as well as it can also process data requests that can come from either client C1 or 08:03.830 --> 08:04.940 client C2. 08:06.030 --> 08:07.920 In any sequence. 08:09.090 --> 08:14.550 So now you understand that select system call is actually monitor all the file descriptors which are 08:14.550 --> 08:22.860 present in set data structure and depending on the type of event that takes place, that is whether 08:22.860 --> 08:29.340 server receives new connection initiation request or whether server receives data request from already 08:29.340 --> 08:30.600 connected client. 08:32.050 --> 08:37.600 Appropriate file descriptors will be activated and the server gets unblocked from the select system 08:37.600 --> 08:41.020 call to process that particular type of request. 08:41.110 --> 08:44.890 So again, discussing the same thing with the help of a flowchart. 08:44.920 --> 08:50.020 When the server receives the data request from the connected client, the server will get unblocked 08:50.020 --> 08:56.320 from the select system call and now the server will check whether is it the master socket file descriptor 08:56.320 --> 08:57.400 which is activated. 08:57.430 --> 09:01.570 Of course it will be the communication file descriptor which will be activated. 09:02.430 --> 09:09.030 So the next thing that our server needs to do is to actually identify the correct client, which has 09:09.030 --> 09:15.270 actually sent data to our server process because there could be many clients to which our server process 09:15.270 --> 09:16.320 is connected. 09:16.620 --> 09:17.310 Right. 09:17.310 --> 09:22.590 So out of those many clients, which client has actually sent the data to our server? 09:22.590 --> 09:28.920 So the next step is to identify exactly that client which has sent data to our server. 09:28.920 --> 09:36.000 And once our server finds that particular client, our server process then service the data request 09:36.000 --> 09:36.990 to that client. 09:37.020 --> 09:43.440 That is our server process, prepare the response and send the response back to that particular client. 09:44.690 --> 09:51.500 And if the condition arises that our server process choose to close the connection with that particular 09:51.500 --> 09:57.740 client, then in that case our server process has to remove that communication file descriptor from 09:57.740 --> 09:59.540 the fdset data structure. 10:00.260 --> 10:07.190 Because our server is not in a mood to carry out any future communication with that particular client. 10:07.190 --> 10:14.330 So there is no need to maintain the communication file descriptor with that client in that data structure. 10:14.450 --> 10:21.020 So again, the set data structure is updated and the server process goes back and again, invoke the 10:21.020 --> 10:25.280 select system, call on an updated fdset data structure. 10:26.050 --> 10:34.150 So the previous diagram and this flow chart together makes it very clear regarding how a multiplex server 10:34.150 --> 10:35.500 actually works. 10:36.010 --> 10:44.350 So we are in a position to discuss a code which implement a server process with multiplexing capabilities. 10:44.380 --> 10:46.390 So let's have a code walkthrough.