WEBVTT 00:06.580 --> 00:11.870 So guys, in the previous lecture video we discussed and we implemented the subscription. 00:11.890 --> 00:14.710 Now we will going to implement the notification. 00:15.070 --> 00:20.740 So whenever a publisher updates any entries of its routing table, a notification is supposed to be 00:20.770 --> 00:25.270 sent to the all the threads which are subscribed to that entry, which is being updated. 00:25.270 --> 00:25.870 Right. 00:26.020 --> 00:32.110 So in order to send the notification, we will use an API and invoke notification chain which we have 00:32.110 --> 00:33.040 already implemented. 00:33.040 --> 00:33.640 Right. 00:33.670 --> 00:40.030 This is one API which can be used to send all type of notifications, whether it is an update or it 00:40.030 --> 00:44.680 is an ad or it is a deletion of an entry from the routing table by the publisher. 00:44.680 --> 00:45.400 Right. 00:46.300 --> 00:51.250 So I expect that you have implemented this API in the file notifs already. 00:51.340 --> 00:58.810 And now let us see that how we can make our routing table or data source intelligent so that whenever 00:58.810 --> 01:04.810 any entry in the data source is updated by the publisher, our data source would be intelligent enough 01:04.810 --> 01:11.290 to send notification to all the subscribers which are subscribed for that entry, which is being updated. 01:11.290 --> 01:11.980 Right. 01:12.750 --> 01:20.250 So this will be the final part of implementation of publisher subscriber model using notification chains. 01:22.590 --> 01:28.380 So guys, you can see that I'm in the function to add or update routing table entry. 01:28.380 --> 01:34.200 And we already know that publisher uses this API in order to update routing table entries in the routing 01:34.230 --> 01:34.850 table. 01:34.860 --> 01:35.580 Right? 01:35.700 --> 01:41.280 So coming to the problem statement that whenever any entry in the routing table is updated by the publisher, 01:41.280 --> 01:46.500 we need to send notification to all the registered subscribers for that entry, Right? 01:47.670 --> 01:49.440 So you can see that here. 01:49.440 --> 01:54.360 We need to hook up some code inside this function in order to accomplish our goal. 01:54.540 --> 02:00.000 So what are we going to do is that I will going to add some code at the end of this function to achieve 02:00.000 --> 02:00.780 our goal. 02:00.810 --> 02:01.590 Right. 02:01.890 --> 02:07.830 So what I will going to do is that I will simply check whether this entry has a relevant data. 02:07.860 --> 02:11.340 The data means the gateway IP address and the outgoing interface. 02:11.340 --> 02:12.000 Right. 02:12.030 --> 02:18.180 The data part of the routing table entry will be not null if this routing table entry is being updated 02:18.180 --> 02:19.260 by the publisher. 02:19.260 --> 02:19.940 Right. 02:19.950 --> 02:25.680 So in that case, simply you need to notify all the subscribers which are associated to this routing 02:25.710 --> 02:26.700 table entry. 02:26.910 --> 02:28.200 As simple as that. 02:28.920 --> 02:34.650 So it simply means that whenever publisher updates the routing table entry in the routing table, a 02:34.680 --> 02:39.570 notification will be sent to all the subscribers associated with this routing table entry. 02:39.600 --> 02:40.440 Right. 02:41.410 --> 02:47.260 So remember, this function is used by the subscribers also to create a routing table entry. 02:47.260 --> 02:51.800 And this function is also used by the publisher to create a routing table entry. 02:51.820 --> 02:58.060 The only difference is that that when this function is invoked by the publisher, the data part associated 02:58.060 --> 03:01.930 with this routing table entry would have some valid values, right? 03:01.960 --> 03:08.590 Whereas if this API is invoked by the subscriber, then gateway and outgoing interface of the routing 03:08.620 --> 03:10.210 table entry would be null. 03:10.240 --> 03:10.900 Right? 03:10.900 --> 03:17.320 So you can use this logic in order to differentiate whether this entry is being updated by the publisher 03:17.320 --> 03:19.840 or it is being created by the subscriber. 03:19.870 --> 03:20.560 Right. 03:21.600 --> 03:26.310 Similarly, if the subscriber chooses to delete an entry from the routing table. 03:26.310 --> 03:29.550 So this is currently our implementation is right. 03:29.550 --> 03:33.910 The data source doesn't convey anything to the subscribers at all in this function. 03:33.930 --> 03:39.030 Now we will going to add an additional code in this function so that whenever the publisher deletes 03:39.030 --> 03:44.820 an entry from the routing table before the entry is finally deleted from the routing table, a notification 03:44.820 --> 03:51.150 should be sent to all the subscribers and telling them that, Hey, subscribers, this entry is going 03:51.150 --> 03:51.840 to be deleted. 03:51.870 --> 03:54.180 Do whatever you want, right? 03:54.270 --> 04:02.070 So you can see that in this API after I have found the entry of interest to be deleted, I remove this 04:02.100 --> 04:08.430 entry from the routing table and before actually freeing the entry, you need to notify this entry to 04:08.430 --> 04:09.720 all the subscribers. 04:09.720 --> 04:15.390 So before actually freeing the entry, let us invoke an API and invoke notification chain. 04:15.390 --> 04:16.110 Right. 04:16.110 --> 04:20.190 And simply do the same stuff since we are deleting the entry. 04:20.190 --> 04:23.650 Therefore you need to pass NFC delete as an operation code. 04:23.650 --> 04:24.370 Right. 04:25.460 --> 04:31.810 And when this function returns, it means that all the subscribers have been notified about this entry. 04:31.820 --> 04:38.870 And then simply because the entry is going to be deleted, it is your job to free the notification chain 04:38.870 --> 04:42.110 associated with this routing table entry, right? 04:42.140 --> 04:44.930 Otherwise you will end up doing some memory leak. 04:44.930 --> 04:51.010 And finally, free up the notification chain itself, which is associated with the routing table entry. 04:51.020 --> 04:55.490 And then finally, you can free the routing table entry, right? 04:55.520 --> 05:02.270 So by adding only this piece of code, your routing table has become intelligent that whenever the entry 05:02.270 --> 05:04.670 is deleted from the routing table entry. 05:04.700 --> 05:10.130 Before freeing the routing table entry, a notification will be sent to all the subscribers about this 05:10.130 --> 05:10.820 delete. 05:10.820 --> 05:11.540 Right. 05:11.900 --> 05:19.250 So it simply means that your data source has now become intelligent and now it has an intelligence to 05:19.250 --> 05:25.080 tell the subscribers about all the operations that is being done on this data source by the publisher. 05:25.080 --> 05:25.860 Right.