WEBVTT 00:05.940 --> 00:11.430 So guys, in this lecture we will going to study the concept of multiplexing. 00:11.730 --> 00:14.490 So what exactly multiplexing is? 00:14.970 --> 00:22.080 Multiplexing is a mechanism through which the server process can monitor multiple clients at the same 00:22.080 --> 00:22.680 time. 00:23.310 --> 00:30.810 So without multiplexing, server process can entertain only one client at a time and cannot entertain 00:30.810 --> 00:35.550 other clients request until it finishes with the current client. 00:35.580 --> 00:42.720 So we have already seen this problem in our previous demonstration of server client communication that 00:42.720 --> 00:50.820 when the server was entertaining or processing the request of one client, it do not respond to the 00:50.820 --> 00:54.870 connection initiation request sent by another client. 00:55.320 --> 00:56.160 Right. 00:56.190 --> 01:01.200 So basically our server was responsible to entertain only one client at a time. 01:01.200 --> 01:05.820 And this is a huge drawback for being a server process. 01:05.820 --> 01:10.780 Server process should have a capability to handle multiple clients at the same time. 01:10.800 --> 01:17.010 And therefore we have a concept called multiplexing using which server can entertain multiple connected 01:17.010 --> 01:19.110 client simultaneously. 01:19.830 --> 01:26.880 So the following pictures demonstrate the concept of multiplexing and what happens when you don't have 01:26.880 --> 01:33.870 a multiplexing on the left hand side, You can see a long queue and you can see that while the person 01:33.870 --> 01:39.810 which is at the front of the queue receives the service, all other persons standing behind him have 01:39.810 --> 01:41.330 to wait for their turns. 01:41.340 --> 01:49.200 And once the person who is at the front of the queue receives the service, then if he wishes to receive 01:49.200 --> 01:53.250 the same service again, he has to join the queue right from the back. 01:54.100 --> 02:01.210 So this situation is equivalent to the situation where once the current client is serviced by the server, 02:01.240 --> 02:06.340 client has to join the queue right from the last that is, he will rejoin the queue. 02:06.340 --> 02:12.880 But from the last it means that the client has to send the fresh connection initiation request to the 02:12.880 --> 02:16.210 server to get another service from the server. 02:17.780 --> 02:23.610 Whereas the picture on the right hand side depicts a person which has multiplexing capabilities. 02:23.630 --> 02:30.440 He can do multiple tasks at the same time, so server can service multiple clients at the same time 02:30.440 --> 02:32.660 using the concept of multiplexing. 02:34.770 --> 02:42.870 So Linux provide a special system call which enable the developer to implement multiplex based communication. 02:42.960 --> 02:46.260 And that system call is a select system call. 02:46.650 --> 02:52.700 So select system call help us to monitor all clients activity at the same time. 02:52.710 --> 02:57.660 So these are those clients which are connected to our server and using select system call. 02:57.690 --> 03:01.620 Our server can monitor all those clients at the same time. 03:01.620 --> 03:07.290 That is, which client has sent the data and which client has not sent the data and which client has 03:07.290 --> 03:09.740 sent the new connection initiation request. 03:09.750 --> 03:16.650 So using this system call our server can actually monitor the state of all connected clients at the 03:16.650 --> 03:17.520 same time. 03:18.380 --> 03:21.140 So let us discuss select system call now. 03:21.980 --> 03:24.920 Server process has to maintain client handles. 03:25.010 --> 03:29.600 So remember, client handles are also called communication file descriptors. 03:29.690 --> 03:36.650 So server maintain multiple communication file descriptors to carry out communication with connected 03:36.650 --> 03:37.490 clients. 03:37.790 --> 03:43.430 So you can see in the diagram on the right hand side, at this point of time, our server is maintaining 03:43.430 --> 03:44.770 three file descriptors. 03:44.780 --> 03:50.750 One is the master socket file descriptor, and at this point of time two clients are connected to our 03:50.750 --> 03:54.110 server and corresponding to those two connected clients. 03:54.140 --> 03:59.240 Our server is maintaining two communication file descriptors, which is C one and C two. 04:01.100 --> 04:06.680 So in addition, several process has to maintain connection socket or master socket file descriptor 04:06.680 --> 04:08.210 as well, which is M. 04:08.210 --> 04:14.840 So this is master socket file descriptor and the purpose of master socket file descriptor is to process 04:14.840 --> 04:18.080 new connection initiation requests from new clients. 04:19.590 --> 04:25.400 So Linux provides an inbuilt data structure to maintain the set of socket file descriptors. 04:25.410 --> 04:31.440 So you can see at this point of time in this diagram, our server is actually maintaining three file 04:31.440 --> 04:37.440 descriptors, that is master socket file descriptors and two communication file descriptors. 04:37.470 --> 04:43.640 Now of course you need some data structure in order to maintain these file descriptors. 04:43.650 --> 04:50.160 So Linux provides an inbuilt data structure which makes the maintenance of socket file descriptors easy. 04:51.210 --> 04:57.440 That data structure is called Ft set data structure that is file descriptor set. 04:57.450 --> 05:01.200 So this is a standard data structure that is provided our API. 05:02.760 --> 05:08.550 So you can see that FD underscore set is actually a set of file descriptors which are maintained by 05:08.550 --> 05:10.380 the server at any point of time. 05:11.350 --> 05:18.130 So select system call monitor all socket file descriptors which are present in the set data structure. 05:18.400 --> 05:25.450 So you can see we have a select system call and this select system call operate on FD set data structure. 05:25.570 --> 05:31.840 In other words, our select system call operate on a set of file descriptors which are maintained by 05:31.840 --> 05:32.590 a server. 05:33.490 --> 05:36.940 So the argument to the select system call is definitely. 05:38.750 --> 05:43.130 PhD set data structure, which contains some set of file descriptors. 05:43.370 --> 05:46.460 So this is a high level overview. 05:47.190 --> 05:53.340 Regarding how select system call works and what is the relationship between select system call and set 05:53.340 --> 05:54.390 data structure? 05:54.600 --> 05:58.440 Now, next, let us have a detailed discussion on select system call. 05:58.440 --> 06:01.380 That is how exactly select system call works. 06:01.380 --> 06:09.150 And once you understand the mechanism of select system call it is it will be very easy for you to implement 06:09.180 --> 06:12.900 a server which has multiplexing capabilities.