Message Drop Policy Support and Bubble Rap Implementation #43
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi all,
I created a pull request some time ago adding the support for message drop policies, but, I closed it because I had decided to make more tests at that time.
With this modifications I have added the support for message drop policies. There are 4 basic policies available: EDrop, FIFO, MOFO and SHLI. When specified in the configuration file an instance of a drop policy is created and called by the ActiveRouter class instead of the original makeRoomForMessage method when a message is received. It's easy to understand the code and there are some basic unit tests. If you want to implement your own drop policy, all you need to do is create a new class in the buffermanagement package extending from DropPolicy.
I also have created a configuration example file in the examples folder.
I have also implemented the BubbleRap routing protocol. My implementation is based on this https://github.com/knightcode/the-one-pitt , but using the methods available in the ActiveRouter class to do the message exchange process, so it is more integrated to the simulator in general. I have used this implementation in my research. There are some limitations in this implementation, for example, it considers that each node have only one community. But this can be improved.
The BubbleRapRouter use an implementation of CommunityDetection and Centrality to detect the communities and compute the local and global centrality values for each node, respectively. There are two implementations of CommunityDetection interface available: DistributedKCliqueCommunityDetection and ExternalCommunityDetection. The first is based on the algorithm with the same name and the second loads the communities from an external file. There are two implementations of the Centrality interface: CWindowCentrality that implements the algorithm CWindow and the ExternalCentrality that loads the centrality values from an external file.
There are some unit tests for the BubbleRap implementation.
I hope these modifications help someone.