WEBVTT 00:05.230 --> 00:16.930 So if you see that in this step, we have filled the data structures sock adr underscore u n with the 00:16.930 --> 00:19.330 identity of the Unix domain socket. 00:19.510 --> 00:25.390 The Unix domain socket is identified with the address family, which is a of underscore Unix and the 00:25.390 --> 00:26.530 name of the socket. 00:27.190 --> 00:27.760 Right? 00:27.760 --> 00:35.980 So in line number 52 and 53, we have actually filled this structure with the identity of the Unix domain 00:35.980 --> 00:36.550 socket. 00:36.580 --> 00:39.610 Now the next step is to call the bind system. 00:39.610 --> 00:40.060 Call. 00:40.300 --> 00:43.180 Now what does actually bind system call do? 00:44.950 --> 00:52.630 The purpose of the bind system call is that the application that is this server process is dictating 00:52.630 --> 00:54.400 the underlying operating system. 00:54.400 --> 00:59.770 That is, this application is running over the operating system and using bind system call. 00:59.770 --> 01:05.630 This application is actually telling the operating system the criteria of receiving the data. 01:05.960 --> 01:07.550 Now what does that mean? 01:07.970 --> 01:14.450 See, your server process will going to receive the data which was sent by the client and that client 01:14.450 --> 01:16.370 is also running on the same machine. 01:16.580 --> 01:25.490 So here, Bind System Call is telling the operating system that if a sender process so sender process 01:25.490 --> 01:28.970 is a client process which will run on the same machine. 01:29.540 --> 01:37.040 So the bind system call is being used by this server process to tell the operating system that if sender 01:37.040 --> 01:45.290 process sends the data which is destined to the socket with the name, the following that is demo socket. 01:45.290 --> 01:50.000 Remember the name of our Unix domain socket is demo socket. 01:52.040 --> 01:52.640 Right. 01:52.640 --> 01:58.070 So if send a process that is the client process sends the data which is destined, which is destined 01:58.070 --> 02:07.460 to the socket which has this name, then such data needs to be delivered to this server process, right? 02:08.030 --> 02:14.840 So here actually the server process is dictating the operating system, the criteria of the data that 02:14.840 --> 02:16.220 it wants to receive. 02:17.150 --> 02:21.290 So let me elaborate a little bit more on it. 02:22.100 --> 02:29.180 So here you have the application layer and on the application layer you have a server process running 02:29.190 --> 02:35.390 as and on the same machine you have a client process C, which is also running. 02:35.510 --> 02:42.560 And because and you know that the application layer runs on the top of the operating system, right? 02:43.970 --> 02:50.330 So using bind system call, the server process is telling the operating system that I'm interested in 02:50.330 --> 02:56.600 receiving the packet which is assigned to the socket name demo socket. 02:57.590 --> 03:02.000 So let me just write DS that stands for demo socket. 03:02.300 --> 03:11.690 Now, if the client C sends the data to the server and in order to send the data, the client C uses 03:11.690 --> 03:21.950 the name of the socket as demo socket that is DS, Then operating system will take the client data and 03:21.950 --> 03:26.060 it will redirect that data to the server process. 03:26.210 --> 03:29.910 S why it is redirecting that data to the server process. 03:29.940 --> 03:37.220 S Because the server process s has told the operating system using bind system call that it is actually 03:37.220 --> 03:41.300 interested in receiving the data which is sent by the client process. 03:41.300 --> 03:48.180 C And the client process C has sent the data destined to the socket. 03:48.780 --> 03:50.010 Demo socket. 03:50.220 --> 03:56.790 So remember when the client C sends the data to the Unix domain socket, the client C has to specify 03:56.790 --> 04:00.240 the name of the Unix domain socket in order to send the data. 04:00.960 --> 04:03.720 So this is the functionality of bind system call. 04:04.350 --> 04:06.910 So you can see the synopsis of the bind system call. 04:06.930 --> 04:11.850 The first argument to the bind system call is actually the master socket file descriptor which we have 04:11.850 --> 04:14.010 already created as in the first step. 04:14.750 --> 04:21.110 The second argument to the bind system call is actually the pointer to the structure which we have already 04:21.110 --> 04:24.920 filled with the credentials or identity of the Unix domain socket. 04:25.040 --> 04:29.780 So you can see that in the second argument of the bind system call, we are actually. 04:30.670 --> 04:37.120 We are actually supplying the identity of the Unix domain socket that is the name of the Unix domain 04:37.120 --> 04:37.870 socket. 04:37.870 --> 04:43.990 And the third argument, you just have to pass the constant value, which is nothing but the size of 04:44.200 --> 04:45.550 this structure. 04:48.250 --> 04:53.650 So it is actually the size of the second argument that you have passed to the bind system call. 04:54.310 --> 04:57.850 So this is the entire purpose of bind system call. 04:58.900 --> 05:04.420 So going forward, if the bind system call returns minus one, it means that for some reason the bind 05:04.420 --> 05:05.800 system call has failed. 05:06.610 --> 05:07.360 Right. 05:07.360 --> 05:11.410 So by line number 68, the bind system call is succeeded. 05:11.620 --> 05:13.780 Now let us discuss what is the next step. 05:13.780 --> 05:15.970 The next step is the listen system call. 05:16.000 --> 05:17.890 Now, what does listen system call do? 05:17.890 --> 05:19.690 Let us try to understand that. 05:20.590 --> 05:26.890 So you can see that the server process in the next step has made a call to the listen system call. 05:26.920 --> 05:31.360 The first argument to the listen system call is the master socket file descriptor, which you have already 05:31.360 --> 05:32.020 created. 05:32.020 --> 05:35.770 And in the second argument you need to pass some numeric value. 05:35.800 --> 05:38.290 Now what is this numeric value? 05:38.620 --> 05:47.110 This numeric value means that if 20 client sends the data to this server process at the same time, 05:47.110 --> 05:55.970 the operating system will queue the request or data of those 20 clients and deliver those requests to 05:55.970 --> 05:58.640 our server process one by one for processing. 06:00.150 --> 06:07.260 If more than 20 clients requests or data arrives to this server process, the operating system will 06:07.260 --> 06:11.370 going to drop those requests or data from extra clients. 06:11.700 --> 06:16.610 So this is what lesson system call does using lesson system call. 06:16.620 --> 06:23.820 Our server process is telling the operating system to maintain a queue of maximum size 20. 06:25.180 --> 06:29.140 And again, if listen, system call fails, then it returns minus one. 06:29.140 --> 06:32.470 And in case of failure, then we just exit. 06:33.740 --> 06:39.350 Now, in the next step, you can see that the server process is making a call to the accept system call. 06:40.450 --> 06:40.980 Right. 06:41.940 --> 06:49.170 So before making a call to the accept system call, the server has to enter into the infinite loop because 06:49.170 --> 06:52.140 all server process usually runs 24 into seven. 06:52.140 --> 06:59.160 So it is a property of a server process that good servers are those which are always usually up 24 into 06:59.160 --> 06:59.790 seven. 06:59.940 --> 07:04.290 So good servers should always up and running and should never go down. 07:04.440 --> 07:11.340 Have you ever seen Facebook or Google page fail to load because of their respective servers are down? 07:11.370 --> 07:11.850 No. 07:11.850 --> 07:12.510 Right. 07:12.510 --> 07:14.520 So it is a common practice. 07:14.520 --> 07:23.190 That server process is that server logic is always encapsulated inside an infinite loop, right? 07:23.190 --> 07:29.280 So once we enter into the infinite loop, you can see that our server process will print that. 07:29.280 --> 07:31.380 It is waiting for the accept system call. 07:32.910 --> 07:39.060 So the synopsis of the system call is simple that in the first argument you just have to pass the master 07:39.060 --> 07:43.110 socket file descriptor, which is also called as connection socket. 07:43.110 --> 07:48.240 And the second and third argument for Unix domain socket, you can simply pass as null null. 07:48.270 --> 07:51.480 Their discussion is not worth for this course. 07:52.410 --> 07:58.620 So remember the return value of accept system call is actually a communication file descriptor or data 07:58.620 --> 08:02.850 socket using this data socket or communication file descriptor. 08:02.880 --> 08:09.600 This server will going to exchange the data with the client for the rest of the lifetime of the connection. 08:10.290 --> 08:14.550 So remember the accept system call is first of all a blocking system call. 08:15.320 --> 08:16.880 Now, what does that mean? 08:17.090 --> 08:25.670 It means that the moment your server process invokes the accept system call the server process execution 08:25.670 --> 08:26.830 will get blocked. 08:26.840 --> 08:29.840 That is, it will not execute line number 92. 08:31.110 --> 08:37.350 And it will stay blocked until the server process receives the connection initiation request from the 08:37.350 --> 08:38.040 client. 08:38.700 --> 08:46.890 It means that by invoking the accept system call, our server process is now waiting for some client 08:46.980 --> 08:50.250 to get connected with server process. 08:51.730 --> 08:55.630 So therefore accept system call is actually a blocking system call. 08:55.660 --> 09:01.510 Blocking system calls are those system calls which, when executed, gets blocked until certain events 09:01.510 --> 09:02.170 occur. 09:02.200 --> 09:09.310 So in this case the accept system call will stay blocked until some client sends connection initiation 09:09.310 --> 09:11.350 request to our server process. 09:11.530 --> 09:19.270 So let us suppose that there exists some client on the same machine and that particular client has sent 09:19.270 --> 09:21.970 the connection initiation request to our server. 09:22.240 --> 09:27.730 So the moment our server will receive the connection initiation request, this accept system call will 09:27.730 --> 09:35.980 return and it will return us the data socket that will be used to carry out communication with the client, 09:35.980 --> 09:38.530 which is just connected to the server. 09:39.640 --> 09:42.520 So the code execution will now proceed. 09:43.520 --> 09:50.450 So the moment the client gets connected to our server successfully in line number 97, our server will 09:50.450 --> 09:50.870 print. 09:50.870 --> 09:53.870 That connection has been accepted from the client. 09:54.680 --> 10:02.210 So remember the functionality of a server that it will keep on doing the summation of the values of 10:02.210 --> 10:06.770 the non-zero values that are sent by the client which is connected to the server. 10:07.280 --> 10:10.580 Now the server is again entering into the infinite loop. 10:11.570 --> 10:12.290 Right. 10:14.900 --> 10:21.260 It is entering into this infinite loop because our server will going to accept all the integer values 10:21.260 --> 10:29.300 that is being sent by the client and it will going to process all those values and keep calculating 10:29.300 --> 10:34.160 the summation of those values unless until the client sends zero. 10:34.550 --> 10:40.100 So it is for this reason that our server is now entering into the infinite loop again. 10:40.580 --> 10:48.170 Now remember, our server has to accept some data from the client and to accept that data our server 10:48.170 --> 10:49.790 process need a memory. 10:50.090 --> 10:56.360 So buffer is the memory pointer and using mem set a server process is actually. 10:58.210 --> 11:03.940 Removing any garbage value that was left in this buffer for some reason. 11:05.060 --> 11:05.660 Right. 11:05.840 --> 11:11.480 So in the next step, you can see that our server process is now actually invoking the read system call. 11:11.900 --> 11:19.130 The synopsis of the read system call is that it Is that the first argument that is passed to the system 11:19.130 --> 11:21.650 call is actually the communication file descriptor. 11:21.800 --> 11:23.090 So remember. 11:24.690 --> 11:29.730 It is the data socket that is used for carrying out actual data exchange with the client. 11:32.600 --> 11:39.050 Therefore, the job of the master socket file descriptor was over at the accept system call because 11:39.050 --> 11:44.930 master socket file descriptors are used only to accept and create new connections with the new client, 11:44.960 --> 11:50.570 whereas actual data exchange happens on the data socket, which is actually the return value of the 11:50.570 --> 11:51.680 accept system call. 11:53.140 --> 11:59.740 So all this theory we have already covered in the basics of socket programming design and when we were 11:59.740 --> 12:03.130 discussing the design of socket programming. 12:03.370 --> 12:06.640 So read System Call is again a blocking system call. 12:06.790 --> 12:17.380 It means that the execution of this server program will halt at this line and it will stay halt or blocked 12:17.380 --> 12:25.990 at this line until the client that has just connected to our server has actually sent some data to our 12:25.990 --> 12:26.650 server. 12:27.010 --> 12:33.850 So the moment the connected client sends the data to our server, our server will read that data into 12:33.850 --> 12:37.570 this buffer which is passed as the second argument to the read system call. 12:39.530 --> 12:47.150 And and after receiving the data, the read system call will get unblocked and the execution of this 12:47.150 --> 12:48.860 program will proceed further. 12:50.990 --> 12:55.910 The third argument to the read system call is actually the size of the buffer, which is passed as the 12:55.910 --> 12:57.800 third argument to the read system call. 12:59.200 --> 12:59.740 Right. 13:01.310 --> 13:08.150 So the return value of read system call is the number of bytes that is read or received by the server. 13:08.390 --> 13:14.330 So if the return value of the read system call is negative, it means some error has taken place and 13:14.330 --> 13:19.340 our server process is just terminating in case of some error happens. 13:19.640 --> 13:27.590 Now remember that that our server process is actually expecting only the integer values from the client. 13:27.920 --> 13:37.310 So buffer is actually a memory and only integer values are expected to receive from the client. 13:37.340 --> 13:42.500 So it is for this reason that we are actually copying only four bytes of memory. 13:42.500 --> 13:44.840 That is size of int is four bytes. 13:46.570 --> 13:53.260 So we are copying only the integer value that is received in the buffer into the data type variable. 13:53.290 --> 13:57.010 Now this data type variable is actually an integer type variable. 13:58.780 --> 14:04.390 So basically we are copying the integer value that is received from the buffer into the integer type 14:04.390 --> 14:05.080 variable. 14:06.100 --> 14:11.060 And now we are checking that if data is zero, then we are just break. 14:11.080 --> 14:14.980 That is, our server process will come out of the inner loop. 14:16.210 --> 14:22.000 Otherwise, if the data value that is the integer value that is sent by the client is not zero, then 14:22.000 --> 14:27.340 remember that our server process will keep on doing the summation of the values that is sent by the 14:27.340 --> 14:28.030 client. 14:29.590 --> 14:30.040 Right. 14:30.040 --> 14:33.390 So let us suppose that the client has sent a non-zero value. 14:33.400 --> 14:37.240 It means that our server process will execute this line. 14:37.240 --> 14:46.270 That is, it will do summation and a server process will iterate once more inside the inner infinite 14:46.270 --> 14:46.750 loop. 14:46.750 --> 14:55.990 It will prepare the buffer again in order to receive the next data from the client and our server process 14:55.990 --> 14:58.720 will again get blocked on the read system call. 14:58.720 --> 15:04.420 That is, our server process is now waiting for the next data item from the client. 15:05.260 --> 15:12.670 So you can see that our server process is kind of an infinite loop and it will continue to wait for 15:12.670 --> 15:20.350 the next data item from the client until the client sends you, until the client sends zero. 15:21.170 --> 15:25.070 As the value to the server, right? 15:25.070 --> 15:32.390 And therefore you can see that a server process checks that if the client has sent the value zero to 15:32.390 --> 15:34.580 our server, then we will break. 15:36.840 --> 15:40.200 So we will be in line number 123. 15:40.200 --> 15:44.500 When a client has sent a value zero to our server. 15:44.520 --> 15:51.120 So the next thing that our server is supposed to do is to actually send back the result. 15:51.120 --> 15:52.150 And what is the result? 15:52.170 --> 15:57.540 The result is the summation of all values that a server process has computed so far. 15:57.870 --> 16:02.550 So using printf command, we are actually preparing a formatted string. 16:04.350 --> 16:09.660 And this formatted string will be the result that our server process will send back to the client. 16:11.150 --> 16:11.570 Right. 16:11.570 --> 16:18.710 So in line number 124, our server process has actually prepared the result that is supposed to be sent 16:18.710 --> 16:19.910 back to the client. 16:20.930 --> 16:29.190 So in line number 127, our server process is actually sending back the result to the client. 16:29.210 --> 16:31.580 So it is done using right system call. 16:32.120 --> 16:36.470 So the synopsis of the right system call is exactly same as the read system call. 16:36.680 --> 16:44.870 The only thing to note here is that that the right system call is a non-blocking system call that is 16:44.870 --> 16:50.270 write system call, execute immediately and it do not blocks for any reason. 16:51.530 --> 16:57.710 So in line number 127, our server has actually sent back the result to the client successfully. 16:58.100 --> 16:58.760 Right. 16:58.760 --> 17:04.580 And after sending the result to the client successfully, our server process has actually closed the 17:04.580 --> 17:06.290 connection with the client. 17:08.140 --> 17:08.650 Right. 17:10.390 --> 17:17.200 So it means that our server process is done with this client and now our server process should be in 17:17.200 --> 17:19.900 a position to entertain the new client. 17:21.220 --> 17:29.380 So in line number 135, we are actually going to iterate the outer infinite loop once again. 17:30.860 --> 17:31.220 Right. 17:31.220 --> 17:37.850 So the server process will now again invoke the accept system call and remember, accept system call 17:37.850 --> 17:39.290 is a blocking system call. 17:40.600 --> 17:47.260 So our server process is now actually waiting for the new connection request from the new client. 17:48.700 --> 17:55.990 So you can see that this explains the entire state machine or of our of our server process. 17:56.470 --> 18:03.550 You are requested to type out these lines on your own machine and please do not copy paste. 18:03.550 --> 18:09.580 Just type out these lines and try to understand the logic of this server program and try to understand 18:09.580 --> 18:17.170 the synopsis of different system calls we have used in this server program so that you get a fair idea 18:17.170 --> 18:22.810 and practice regarding how to implement a Unix domain server process. 18:23.680 --> 18:30.460 So I have explained all the steps that are required to implement a Unix domain server process. 18:30.580 --> 18:37.420 So we have just discussed all the steps that are required to implement a Unix domain server process. 18:37.570 --> 18:43.760 Now the next we will going to discuss the steps required to implement a client process. 18:44.630 --> 18:50.360 Now note that the implementation of client process is very simple and straightforward.