- Before we were doing this by just adding incrementing a value everytime we get a set of nodes as the reply of a FIND_NODE or FIND_VALUE RPC
-- This may be wrong since nodes the same distance away may reply and we'll still be incrementing for both
- Created a route length checker class to properly check route lengths
ContentLookupOperation
- Added the route length check to the CLO operation
Didn't add it to the NodeLookupOperation since I'm not sure we're using it anywhere... Though it can be useful there
- Added a shorter method
- Create a treeset to sort the nodes
- Add all nodes in the routing table to the treeset
- Then select the top Q nodes required from the treeset
- Just found a major Bug!!! We were doing 160 refreshes looking for nodes with the local nodeId as the lookup ID for all 160 refreshes
- Updated to check for nodes at different distances from the local NodeId
Content Lookup Operation
- We were still using KademliaNode instead of KademliaNode.getNode to use the mini node for comparisons
- Made it an interface
- Implemented the interface and made the changes in the code to use the interface
- We do this because we'll extend the code for SocialKad
- Introduced artificial latency when we're in testing mode
ContentLookup & NodeLookup Operations
- Reduce the wait time between data checks to 10 milliseconds
- Added Information to specify whether we're in a testing environment or a production environment
-- we can use this information to put in network latency, etc
Statistician
- Adding counting the number of sendData and receiveData operations
KademliaNode
- Removed the counting of contentLookup if we're getting the content from local storage
- Returns some times in milliseconds instead of microseconds
KadServer
- Made a few operations synchronized
- Handled the exception when the timer is already canceled
- Renamed the statistics class to Statistician since that's is what it is - a statistician that manages the Kad statistics
- Passed the statistician to our Server to collect data
- We were getting some concurrency exceptions because certain data structures were being modified concurrently
- Solved the issues by synchronizing the methods modifying the data structures
We were getting a concurrency Modification error on the treemap because multiple operations may have been accessing the RoutingTable's getAllNodes() method at once.
- Fixed it by making this method synchronized.
- Routing Table had a save state issue because of the KadConfiguration
-- I removed saving the configuration since this may change from boot to boot
-- Provided a way to set a new configuration to the routing table
-- Updated the serializer/deserializer
- Use all nodes to these operations initially instead of the K-Closest because there may be the case that the K-Closest are offline
- The operation takes care of looking at the K-Closest.
- There was an improvement in the paper page 64 to set a contact as stale and replace it if it's stale, but only if there is a replacement, otherwise just keep a stale count. The stale count is the amount of time a contact failed to respond to a request.
- The above feature is now implemented now.
- Added the management of stale contacts code to insert and removal
Kademlia Node
- The Kademlia class is renamed to KademliaNode - this will now serve as the main node on the network
- The RoutingTable will be a part of this node
Node
- The node class is now a basic class containing information about a node to be used by peers on the network
RoutingTable
- Working on Evicting contacts from the routing table
- Working on Replacement Cache
- Written another simulation to test these new RoutingTable features
- Added the improvement for content refresh operation from the paper, we keep the last time a content was republished, and on content update operations, we only republish if the last republish was before (current time - republishing time interval)
