So, guys, now moving forward now let us implement a publisher subscriber example.
So now that we have already implemented a basic skeleton framework of notification chains, that is
notify and notify files, right?
Now we will going to implement an actual publisher subscriber model as an example.
So what we will going to do is that we will going to create a publisher thread and we will going to
create three subscriber threads, right?
So we will have one process and within that process we will going to create four threads out of which
one is a publisher thread and the rest three are subscriber threads.
Right.
Now for the publisher subscriber model to implement a publisher thread must own some data source.
Right?
So that data source in our example would going to be some simplified routing table.
Now, if you are not very much familiar with the routing table, let me explain the fields of the routing
table.
The very simplified routing table has typical four entries.
The first two entries, that is destination and mask value are the keys of the routing table.
That is No.
Two entries in the routing table would have same keys.
Right?
Whereas the last two entries is other data which is associated with an entry of the routing table that
is outgoing interface name and gateway entry.
Now, you don't have to understand the meaning of these entries in the routing table.
All you need to assume that publisher thread is in charge of some data source and be it any data source.
In our example, we have taken it as a routing table.
You don't have to understand that.
What is the semantics or what is the meaning of an entry in this routing table?
Right.
If you want, you can choose any other data source of your choice while implementing your version of
the example.
So now you can see that the publisher thread owns a data source, a routing table, and the rest of
the threads in this process, that is subscriber threads may be interested in, say, routing table
entry number two or routing table entry number three, Right.
There could be any number of subscribers and any number of subscribers can subscribe for any entry in
the routing table.
Right.
So it simply means that each entry in this routing table must be associated with notification chains.
Each entry of this routing table has its own notification chain.
A notification chain is nothing, but it is a link list of subscribers.
So let us suppose that thread one is interested in the entry.
122 .1.1.1 slash 32.
That is first entry of this routing table, right?
So it will send a subscription request to the publisher telling the publisher that, Hey publisher,
I'm interested in this particular entry.
So what you need to do is that you need to simply add an additional node in this notification chain.
And this node will represent that.
The thread T1 is another subscriber which is interested in the notifications related to the first entry
of the routing table.
Right.
Similarly, there could be more subscribers.
ET cetera.
Interested in notifications of their respective entries of interest from the routing table.
Right.
So note that a subscriber can register for multiple entries in the routing table.
Right?
So in this case, a subscriber thread.
One can register for any number of entries of the routing table.
A subscriber can subscribe or unsubscribe at his will.
Right?
And all the codes related to notification chains can be found in this directory.
So now, in the subsequent section of this course, we will discuss step by step how to implement this
complete picture.
If you have got enough idea, you are free to experiment on your own and implement this problem statement.