WEBVTT 00:06.340 --> 00:11.860 So, guys, now moving forward now let us implement a publisher subscriber example. 00:11.980 --> 00:18.040 So now that we have already implemented a basic skeleton framework of notification chains, that is 00:18.070 --> 00:21.430 notify and notify files, right? 00:21.520 --> 00:26.950 Now we will going to implement an actual publisher subscriber model as an example. 00:27.340 --> 00:33.220 So what we will going to do is that we will going to create a publisher thread and we will going to 00:33.220 --> 00:35.920 create three subscriber threads, right? 00:35.920 --> 00:41.620 So we will have one process and within that process we will going to create four threads out of which 00:41.620 --> 00:45.400 one is a publisher thread and the rest three are subscriber threads. 00:45.400 --> 00:46.120 Right. 00:47.210 --> 00:53.210 Now for the publisher subscriber model to implement a publisher thread must own some data source. 00:53.240 --> 00:53.990 Right? 00:54.260 --> 01:00.290 So that data source in our example would going to be some simplified routing table. 01:00.320 --> 01:05.660 Now, if you are not very much familiar with the routing table, let me explain the fields of the routing 01:05.690 --> 01:06.270 table. 01:06.290 --> 01:09.800 The very simplified routing table has typical four entries. 01:09.830 --> 01:14.900 The first two entries, that is destination and mask value are the keys of the routing table. 01:15.050 --> 01:16.130 That is No. 01:16.130 --> 01:19.180 Two entries in the routing table would have same keys. 01:19.190 --> 01:19.940 Right? 01:21.410 --> 01:27.440 Whereas the last two entries is other data which is associated with an entry of the routing table that 01:27.440 --> 01:30.230 is outgoing interface name and gateway entry. 01:30.260 --> 01:34.670 Now, you don't have to understand the meaning of these entries in the routing table. 01:34.700 --> 01:42.200 All you need to assume that publisher thread is in charge of some data source and be it any data source. 01:42.200 --> 01:46.120 In our example, we have taken it as a routing table. 01:46.130 --> 01:47.870 You don't have to understand that. 01:47.870 --> 01:52.670 What is the semantics or what is the meaning of an entry in this routing table? 01:52.700 --> 01:53.360 Right. 01:53.570 --> 01:59.510 If you want, you can choose any other data source of your choice while implementing your version of 01:59.510 --> 02:00.440 the example. 02:00.650 --> 02:07.220 So now you can see that the publisher thread owns a data source, a routing table, and the rest of 02:07.220 --> 02:12.770 the threads in this process, that is subscriber threads may be interested in, say, routing table 02:12.770 --> 02:17.000 entry number two or routing table entry number three, Right. 02:17.810 --> 02:24.390 There could be any number of subscribers and any number of subscribers can subscribe for any entry in 02:24.390 --> 02:25.440 the routing table. 02:25.440 --> 02:26.160 Right. 02:26.460 --> 02:32.980 So it simply means that each entry in this routing table must be associated with notification chains. 02:33.000 --> 02:37.440 Each entry of this routing table has its own notification chain. 02:38.040 --> 02:41.760 A notification chain is nothing, but it is a link list of subscribers. 02:42.180 --> 02:46.170 So let us suppose that thread one is interested in the entry. 02:46.170 --> 02:49.800 122 .1.1.1 slash 32. 02:49.830 --> 02:52.910 That is first entry of this routing table, right? 02:52.920 --> 02:58.740 So it will send a subscription request to the publisher telling the publisher that, Hey publisher, 02:58.740 --> 03:01.280 I'm interested in this particular entry. 03:01.290 --> 03:07.680 So what you need to do is that you need to simply add an additional node in this notification chain. 03:07.680 --> 03:09.720 And this node will represent that. 03:09.720 --> 03:15.600 The thread T1 is another subscriber which is interested in the notifications related to the first entry 03:15.600 --> 03:16.740 of the routing table. 03:16.740 --> 03:17.460 Right. 03:17.610 --> 03:20.040 Similarly, there could be more subscribers. 03:20.040 --> 03:20.610 ET cetera. 03:20.610 --> 03:21.710 ET cetera. 03:21.710 --> 03:27.500 Interested in notifications of their respective entries of interest from the routing table. 03:27.500 --> 03:28.280 Right. 03:28.760 --> 03:33.250 So note that a subscriber can register for multiple entries in the routing table. 03:33.260 --> 03:33.770 Right? 03:33.770 --> 03:36.830 So in this case, a subscriber thread. 03:37.100 --> 03:40.700 One can register for any number of entries of the routing table. 03:40.730 --> 03:44.630 A subscriber can subscribe or unsubscribe at his will. 03:44.630 --> 03:45.380 Right? 03:45.380 --> 03:50.390 And all the codes related to notification chains can be found in this directory. 03:51.260 --> 03:56.780 So now, in the subsequent section of this course, we will discuss step by step how to implement this 03:56.780 --> 03:58.040 complete picture. 03:58.160 --> 04:04.010 If you have got enough idea, you are free to experiment on your own and implement this problem statement.