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
