- 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
Added a getDHT method to Kademlia
Changed the folder structure in which content is stored in the DHT from Kademlia/substr(contentid, 10)/hash(content).kct TO Kademlia/ownerId/substr(contentid, 10)/hash(content).kct
* @todo Make the KadBucket represent the Bucket interface
* @todo Change the code to reflect the bucket interface and not the specific KadBucket implementation
* @todo Update this interface and use this as parameter type, etc... instead of the KadBucket implementation used throughout the application
Now we're coding to the Bucket interface rather than the KadBucket implementation
- The problem was that we were creating the RoutingTable before the Node initialization was finished, which was causing some problems since the RoutingTable needs the NodeId which is not available until after the Node initialization
