- 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)
Before the content lookup operation used to lookup a specified set of nodes then return the latest content; a short review of the paper showed that we only lookup until we find the Value then exit as soon as we do. Made the updates to the code.
- Added last seen data to contact
- Contacts are not sorted by lastSeen
- Contact updating last seen time is handled
Built a simulation to test the contact last seen updates
Had a bug in the content lookup operation, if the total amount of content needed was not found, a Routing exception was thrown instead of returning what was found. Fixed the issue!
CLO was timing out even if it had found the specified amount of content needed. Fixed that by exiting after the specified # of content required has been found
When doing a NodeLookup, Content Lookup or Connect operation, after sending the message, we used to wait(operation_timeout) time before checking for a result.
Now what I'm doing is waiting for 100 ms and check for a result every 100ms; I keep a count of total time waited, and only when the total time > operation_timeout do we make a timeout.
So now we can handle the response if it comes in before Operation_timeout time is finished
- Didn't do this before, but now it's setup: content will be updated on the DHT if a StoreContentMessage is sent with a newer version of the content
GetParameter
- Updated the GetParameter so that it can be constructed from a KadContent object or a StorageEntryMetadata object
- Move it to the DHT package
Others
- Added a few methods to StorageEntryMetadata, StorageEntryManager& DHT to simplify conversions between KadContent, GetParameter & StorageEntryMetadata
Tests
- Written a test to check content updating
