WEBVTT 00:05.060 --> 00:11.200 So, guys, next we will going to discuss the implementation of Unix domain sockets on the client side. 00:11.210 --> 00:15.890 So you can see in this diagram that the client state machine is pretty much very simple. 00:16.070 --> 00:23.150 As soon as the client process starts up, the first thing that the client process do is to create a 00:23.450 --> 00:25.130 socket file descriptor. 00:25.670 --> 00:31.970 Right now, there is no concept of master socket file descriptor using socket system call only. 00:31.970 --> 00:38.240 The client creates a communication file descriptor and using this communication file descriptor, the 00:38.240 --> 00:43.130 client carries out all the data exchange with the server and the second step. 00:43.130 --> 00:50.480 Once the client has created a socket, the client simply sends connection initiation request to the 00:50.480 --> 00:54.440 server and this is done using connect system call. 00:55.040 --> 01:02.750 So once the connect system call succeeds, the client can now carry out actual data exchange with the 01:02.750 --> 01:04.740 server right? 01:04.740 --> 01:09.200 So you can see that the client steps are pretty much simple and straightforward. 01:09.210 --> 01:12.750 So let's have a code walk for the client implementation. 01:13.920 --> 01:21.060 So guys, we have opened a file client dot C, so client dot c file is the file that implements the 01:21.060 --> 01:22.320 client functionality. 01:24.490 --> 01:28.560 So in line number nine, you can see that we have defined a socket name. 01:28.570 --> 01:34.780 So you can see that this socket name is same as the socket name, which we have used while creating 01:34.780 --> 01:36.100 a server process. 01:36.280 --> 01:41.170 So the client process will use this socket name to send data to this socket. 01:41.530 --> 01:42.340 Right. 01:42.640 --> 01:49.030 And of course the client needs a memory buffer size in order to send the data to the server process 01:49.030 --> 01:52.090 as well as receiving the result from the server process. 01:53.140 --> 01:55.930 So you can see that in line number 123. 01:55.960 --> 02:02.560 The first thing that the client processes do is to create a Unix domain sockets so you can see that 02:02.560 --> 02:06.940 a client has created a Unix domain socket in the same way the server does. 02:08.900 --> 02:09.480 Right. 02:09.800 --> 02:18.290 The difference here is that on the client side, the socket file descriptor that is that is returned 02:18.290 --> 02:23.420 by the socket system call is actually a data socket and not connection socket. 02:23.840 --> 02:28.610 So data socket is a socket file descriptor which is used for actual data exchange. 02:29.210 --> 02:34.280 So there is no concept of master socket file descriptors on the client side. 02:35.030 --> 02:41.030 So the socket file descriptor that is returned by the socket system call itself is a communication file 02:41.030 --> 02:46.550 descriptor and the client uses this data socket for carry out actual data exchange with the server. 02:47.920 --> 02:48.430 Right. 02:48.430 --> 02:54.070 So in line number 23, the client process has created a socket for communication. 02:55.600 --> 02:59.920 Right now in the next step that is in line number 36. 02:59.950 --> 03:08.590 You can see that the server is actually populating the structure called struct sock underscore UN. 03:08.740 --> 03:13.330 And you can see that a client process is doing the same thing. 03:13.330 --> 03:19.540 Which server did the client process is actually specifying the. 03:20.600 --> 03:27.050 Identity of the Unix domain socket to which it wants to carry out communication. 03:27.860 --> 03:33.710 So the first argument is the Unix domain socket family, which is AF underscore. 03:33.740 --> 03:34.520 Unix. 03:34.640 --> 03:40.940 And the second argument is actually the socket name using which the client will send the data to the 03:40.940 --> 03:41.690 server. 03:41.930 --> 03:49.400 So in line number 40 and 41, the client process knows that which server it wants to communicate with. 03:50.480 --> 03:51.320 Right. 03:53.140 --> 03:59.800 Now, in the next step, the client has to send the connection initiation request to the server. 04:01.090 --> 04:01.780 Right. 04:01.780 --> 04:05.200 So Linux provide a system called called connect. 04:05.230 --> 04:07.240 Using connect system call. 04:07.240 --> 04:11.020 The client sends the connection initiation request to the server. 04:11.350 --> 04:14.980 Now the first argument to the connect system call is the data socket. 04:15.610 --> 04:16.360 Right. 04:16.360 --> 04:19.090 Which is returned by the socket system call. 04:19.210 --> 04:26.410 The second argument is again the pointer to the structure which stores the information of the server 04:26.410 --> 04:29.890 socket to which the client wants to send data. 04:30.430 --> 04:35.920 And the third argument is a constant value, which is the size of this structure type. 04:37.120 --> 04:40.530 So Connect system Call is not a blocking system call. 04:40.540 --> 04:48.310 If there exists no server running, then the connect system call will actually return minus one immediately. 04:49.300 --> 04:49.840 Right. 04:51.260 --> 04:54.260 So Connect System call is not a blocking system call. 04:54.890 --> 05:02.540 Now, remember, the functionality of our client process was that it continued to send the integer value 05:02.540 --> 05:03.440 to the server. 05:04.780 --> 05:11.830 So here we are entering into the loop, and in this loop, the client process will prompt the user to 05:11.830 --> 05:13.300 enter the integer value. 05:13.630 --> 05:21.160 And as soon as the user enters the integer value, our client process will send that value to our server. 05:23.690 --> 05:28.460 So using a write system call again, our client process will send value to our server. 05:28.970 --> 05:33.980 So to send a value to the server, our client process invokes the write system call. 05:34.010 --> 05:37.610 The first argument to the right system call is the data socket file descriptor. 05:37.640 --> 05:42.860 The second argument is a pointer to the buffer, which actually stores the data to be sent to the server. 05:42.980 --> 05:49.710 So in this case, the our client process has to send only a single integer value to the server. 05:49.730 --> 05:56.000 So you can directly pass the address of the memory location which actually stores the integer value. 05:56.480 --> 06:02.300 And the third argument is the size of the data that the client process is sending to the server. 06:02.780 --> 06:10.220 So you can see that when the user enters the value zero, the client process sends that value to the 06:10.220 --> 06:11.440 server process. 06:11.450 --> 06:16.220 And this while loop then terminates because the value of I is zero. 06:18.500 --> 06:25.280 So it means that our client process will continue to send the value to the server until the user enters 06:25.310 --> 06:26.150 zero. 06:26.390 --> 06:32.570 Now our client process will execute line number 65 only when the user has entered the value zero as 06:32.570 --> 06:33.380 an input. 06:33.560 --> 06:38.840 So it is time for the client process now to receive the result from the server. 06:39.170 --> 06:44.450 So it is for this reason that our client process has invoked the read system call. 06:44.750 --> 06:46.970 Read system call is a blocking system call. 06:46.970 --> 06:52.250 It means that the client process will get blocked on line number 66. 06:53.380 --> 06:59.020 And it will stay blocked until it receives a reply from the server. 07:00.670 --> 07:01.210 Right. 07:01.210 --> 07:05.770 So let us assume that the client process has received the data from the server. 07:05.770 --> 07:12.250 So in line number 72, the client process is simply printing the result or the message that is received 07:12.250 --> 07:13.240 from the server. 07:13.540 --> 07:21.100 So you can see that our client process is printing the result as it is, and after that our client process 07:21.100 --> 07:24.970 simply closes the connection with the server and exit. 07:25.180 --> 07:29.950 So you can see that the state machine of the client process is pretty much very straightforward and 07:29.950 --> 07:30.640 simple. 07:31.540 --> 07:33.850 So the client specific system calls. 07:33.850 --> 07:36.130 Here is Connect system call. 07:36.550 --> 07:43.150 It is invoked only on the client side and this connect system call is used to send the connection initiation 07:43.150 --> 07:45.040 request message to the server. 07:45.820 --> 07:52.720 And another thing to note here is that the client should know the identity of the server with which 07:52.750 --> 07:54.340 it wants to communicate with. 07:54.370 --> 08:01.780 So in line number 41, you can see that a client process knows the name of the socket, which actually 08:01.780 --> 08:05.380 is the identity of the server Unix domain socket. 08:06.040 --> 08:13.600 So our client process knows that which server it wants to communicate with because in the connect system, 08:13.600 --> 08:21.010 call the second argument that you passes is actually the name of the Unix domain socket created by the 08:21.010 --> 08:29.200 server, and the client should know the name of this Unix domain socket in order to establish the communication 08:29.200 --> 08:30.700 with the server process. 08:31.340 --> 08:34.790 So next, let us see the demonstration. 08:34.970 --> 08:41.480 That is, we will execute the server and the client process and see how they communicate with each other.