WEBVTT 00:06.110 --> 00:09.930 So guys, now let us discuss the problem statement of this project. 00:09.950 --> 00:16.370 So we will take an example in which there are total of six nodes in the ring topology, right? 00:16.880 --> 00:21.830 So on each node, a user can actually perform two operations. 00:21.860 --> 00:26.750 The first operation is put operation which takes two argument. 00:26.750 --> 00:35.120 The K and X, both are integers, K represents a key and X represent a value corresponding to that key. 00:35.150 --> 00:36.050 Right. 00:36.080 --> 00:44.480 The second operation is a get key operation where K is an integer and this operation must return x that 00:44.480 --> 00:47.000 is value corresponding to the key K. 00:47.120 --> 00:47.960 Right. 00:49.620 --> 00:55.790 Originator is a node on which user has issued either put or get request. 00:55.800 --> 00:56.490 Right? 00:56.490 --> 01:01.200 So this is how our user will going to interact with our project. 01:01.230 --> 01:07.740 The user can issue, put request or get request on any node of the ring topology. 01:08.070 --> 01:13.320 Now let us try to understand what is the functionality of put request. 01:14.340 --> 01:23.160 So put request is basically used by the user whenever the user wants to save key value pair on some 01:23.160 --> 01:24.960 node of the ring topology. 01:24.990 --> 01:25.890 Right. 01:26.280 --> 01:31.860 So let us try to understand the functionality of put request with the help of an example. 01:32.190 --> 01:39.720 Suppose a user issued a put request with k is equal to five and X is equal to five on node number two 01:39.750 --> 01:41.220 in this ring topology. 01:42.060 --> 01:48.840 So on this node that is node number two, the user has issued this put request. 01:48.990 --> 01:56.850 Now the next thing is that that the Node two immediately performs the hash operation on the key supplied 01:56.850 --> 01:57.840 by the user. 01:57.870 --> 02:05.380 The hash function, which is used to perform this hash operation on a key is k mod n, right. 02:05.400 --> 02:13.170 Here, capital N denotes the total number of nodes in this ring topology and K is the key value which 02:13.170 --> 02:15.850 is specified in the put request. 02:17.640 --> 02:21.560 Here Mode operator is actually a remainder operator. 02:21.570 --> 02:26.670 That is when K is divided by this capital N, then this k mode. 02:26.670 --> 02:29.970 N will going to return a remainder. 02:30.920 --> 02:37.100 So applying the hash operation on a key, we're going to return us an integer value. 02:37.340 --> 02:44.660 So if we apply a hash operation on key K is equal to five, then hash function we're going to return 02:44.660 --> 02:46.350 us the value six. 02:46.370 --> 02:49.610 It simply means that X is equal to five. 02:49.640 --> 02:53.480 That is, value needs to be saved on node six. 02:53.480 --> 02:57.260 Hash table against key K is equal to five. 02:57.560 --> 03:02.960 Now note that every node in this ring topology maintains a table called hash table. 03:03.260 --> 03:09.560 The first column of this hash table is a key, and the second column of this hash table is a value, 03:10.010 --> 03:10.820 right? 03:11.120 --> 03:19.550 So when Node two on which put request is issued, the Node two performs has operation on the key value. 03:19.580 --> 03:20.330 Right. 03:20.330 --> 03:23.810 The return value as per our example will be six. 03:23.840 --> 03:31.050 It means that key value pair five five needs to be saved on node number six. 03:31.660 --> 03:37.300 So now at this point of time, user has issued the put request on node number two. 03:37.300 --> 03:45.640 And after applying the hash operation, Node number two now knows that key value pair needs to be saved 03:45.640 --> 03:47.170 on node number six. 03:47.560 --> 03:56.470 So it simply means that now Node two knows that it do not have to save this key value pair in its own 03:56.470 --> 03:57.850 local hash table. 03:57.970 --> 04:04.540 Hence it forwards the key value to successor node, which is node number three. 04:04.570 --> 04:10.900 Using UDP communication, we will call this message as put forward message. 04:11.110 --> 04:13.870 So you can see that in this diagram. 04:13.870 --> 04:19.780 Node number two is forwarding put forward message to its successor node. 04:21.210 --> 04:26.430 Now the question arises that what should be the content of this put forward message? 04:26.460 --> 04:35.490 The content of this put forward message should be that this message should encode IP address of node 04:35.520 --> 04:40.470 two and TCP port number of node two. 04:41.100 --> 04:41.790 Right. 04:41.790 --> 04:43.800 So input forward message. 04:43.800 --> 04:46.270 We need to encode these three values. 04:46.290 --> 04:51.150 Y we encode these three values, you will going to understand it shortly. 04:51.630 --> 04:56.190 Now, when this put forward message is received by Node three. 04:56.220 --> 05:02.190 Node three Inspect the value of K and applies the hash function on it. 05:02.310 --> 05:09.420 Since we already know that hash function returns six, it simply means that node three do not have to 05:09.420 --> 05:10.170 save. 05:11.310 --> 05:18.780 These key value pair in its local hash table and therefore it forwards the put forward message to its 05:18.780 --> 05:19.980 successor node. 05:20.040 --> 05:26.820 Now note that when node three forwards put forward message to its successor node, the content of the 05:26.820 --> 05:29.310 put forward message is not changed. 05:30.170 --> 05:37.430 The put forward message was prepared by that particular node on which put request was issued by the 05:37.430 --> 05:42.530 user that is node number to prepare the put forward message. 05:42.590 --> 05:49.850 The rest of the node in the ring topology simply forward this put forward message without any modification 05:49.850 --> 05:51.560 to its successor node. 05:51.950 --> 05:58.820 The node decides to forward the put forward message after applying the hash function on the key value 05:58.940 --> 06:02.360 which is specified in this put forward message. 06:02.920 --> 06:10.870 So node three to forwards the put forward message to node four using UDP connection without changing 06:10.870 --> 06:17.710 any content of the put forward message that is put forward message still contains these three values 06:17.710 --> 06:25.090 and this process continues until the put forward message is received by node number six in the topology. 06:25.480 --> 06:31.990 Now, when Node six receives this put forward message, it applies the hash function on the key value 06:32.020 --> 06:34.780 which is specified in put forward message. 06:34.780 --> 06:40.270 And we already know that the hash function returns six for K is equal to five. 06:40.300 --> 06:45.370 It means that the value returned by the hash function matches with the node number. 06:45.520 --> 06:53.170 It simply means that now Node six knows that it has to save key value pair in its local hash table. 06:53.410 --> 06:54.250 Right. 06:55.780 --> 07:03.130 But remember, in the put forward message, which is circulating around the topology, we do not have 07:03.130 --> 07:07.420 the value of X encoded in this put forward message. 07:07.600 --> 07:17.080 So the question is how Node six will know the value of X so that it can save key value pair in its local 07:17.080 --> 07:18.040 hash table. 07:18.370 --> 07:25.480 Now you will understand that why in put forward message we encoded the IP address of the originator 07:25.480 --> 07:29.560 machine and the TCP port number of the originator machine. 07:30.150 --> 07:38.850 Note six established TCP connection with the original originator of put request that is node two and 07:38.850 --> 07:40.970 ask for the value of x. 07:40.980 --> 07:41.760 Right. 07:42.630 --> 07:49.380 So you can see that Node six is establishing TCP connection with the originator of this put request. 07:49.440 --> 07:55.230 So how Node six will come to know who was the originator of the put request? 07:55.260 --> 08:01.920 The originator node is that node on which user originally issued put request. 08:02.310 --> 08:09.540 Since Node six has received this put forward message from Node five from put forward message, Node 08:09.540 --> 08:13.530 six can read the IP address and TCP port number. 08:13.650 --> 08:20.070 These IP address and TCP port number are the credentials of the originator node. 08:20.100 --> 08:27.390 So it means node number six knows everything it needs in order to establish TCP connection with the 08:27.390 --> 08:28.380 originator. 08:29.270 --> 08:36.950 So once the Node six established the TCP connection, the Node six asks the originator that Hey, for 08:36.950 --> 08:40.160 the key K, what is the value of X? 08:40.550 --> 08:50.210 Let us call this question asked by Node six to node two as what X message When Node two receives this? 08:50.210 --> 08:52.820 What X message from Node six. 08:52.850 --> 08:59.330 Node two sends the value of five over TCP connection to Node six directly. 09:00.170 --> 09:04.130 Let us call this message as put reply x. 09:05.510 --> 09:07.470 So Node six sends what? 09:07.530 --> 09:14.480 X message to the originator and the originator replies back with the put reply X message. 09:15.560 --> 09:22.670 Now when the node six receives put reply X message, the Node six would know the value of K is equal 09:22.670 --> 09:24.980 to five and X is equal to five. 09:24.980 --> 09:32.810 And finally, it saves these two key value pairs in its local hash table and closes the TCP connection 09:32.810 --> 09:34.280 with the originator. 09:36.220 --> 09:41.560 So this is the functionality of the put request in the resource section. 09:41.560 --> 09:49.780 I have attached the flow chart of put request and get request which will help you in order to develop 09:49.780 --> 09:53.770 and implement your logic in order to do this project. 09:55.700 --> 10:01.070 Now, next we will going to discuss the algorithm or the functionality of get request.