WEBVTT 00:05.700 --> 00:14.250 So guys, we have just taken a look regarding how server and client process can communicate with each 00:14.250 --> 00:16.380 other using Unix domain sockets. 00:17.340 --> 00:25.320 So let us discuss the set of APIs that we have used in our client server socket programming discussion 00:25.320 --> 00:26.650 that we just had. 00:26.670 --> 00:34.110 So you can see that on the client side, the API that we discussed is the connect system call and the 00:34.110 --> 00:40.710 connect system call is used by the client to send the connection initiation request message to the server. 00:41.430 --> 00:42.030 Right. 00:42.030 --> 00:48.390 And the corresponding API to process the connection initiation request is the accept system call. 00:49.050 --> 00:54.420 So Connect system call is not a blocking system call, but the accept system call is a blocking system 00:54.420 --> 00:54.960 call. 00:55.530 --> 00:56.280 Right. 00:57.330 --> 01:04.590 So you can see that connect system call and accept system call are actually complementary to each other. 01:04.860 --> 01:11.100 The connection initiation request that is generated by the client process using connect system call 01:11.100 --> 01:14.910 is processed on the server side by accept system call. 01:15.750 --> 01:21.750 Then once the connection between the client and the server is fully established, the client sends the 01:21.750 --> 01:23.610 service request messages. 01:24.330 --> 01:29.700 That is the actual data to the server using the following APIs. 01:29.940 --> 01:36.060 In our example we have used the write system call, but there are other equivalent system calls that 01:36.060 --> 01:41.970 is provided by the Linux operating system environment that is, send message and send to system calls. 01:42.420 --> 01:49.230 These system calls are also used to send message from client process to server process or vice versa. 01:49.920 --> 01:55.200 So note that here if you are using write system, call then to read a corresponding message. 01:55.200 --> 01:59.760 On the other side, the corresponding system call is read system call. 01:59.850 --> 02:04.500 And for send to system call the corresponding system call is received from system Call. 02:04.650 --> 02:10.500 And if you use send message system call to send a message, then the corresponding API on the other 02:10.500 --> 02:14.130 side to be used is the receive message system call. 02:14.610 --> 02:19.840 So you can see that there is a 1 to 1 mapping between these system calls. 02:20.530 --> 02:23.000 If you use write, you should use read. 02:23.020 --> 02:26.560 If you are using send to, then you should use receive from. 02:26.560 --> 02:31.180 And if you are using send message, then you should use receive message system call. 02:32.520 --> 02:38.070 Also note that the receive message or receive from or read system calls. 02:38.160 --> 02:44.940 That is all the system calls which are intended to receive a message from the other side that is from 02:44.940 --> 02:48.600 the other process are actually blocking system calls. 02:49.940 --> 02:58.040 So guys, let's discuss some observations or some points to be noted from the client server design and 02:58.040 --> 02:59.870 discussion that we have so far. 03:00.260 --> 03:07.040 So we have seen in our demonstration that when server is servicing the current client, it cannot entertain 03:07.040 --> 03:08.300 any new client. 03:08.660 --> 03:16.280 So this is a drawback of the server design that we have discussed and we need to alleviate this limitation. 03:16.790 --> 03:24.650 A server can be redesigned to serve multiple clients at the same time using the concept of multiplexing. 03:25.160 --> 03:28.190 So this will be the topic of our next discussion. 03:28.190 --> 03:30.650 That is the concept of multiplexing. 03:30.650 --> 03:37.100 Using multiplexing, we can redesign a server to actually handle multiple clients connections at the 03:37.100 --> 03:38.000 same time.