schmittlauch/Hash2Pub
1
0
Fork 1
Code Issues 47 Pull requests Releases Wiki Activity

Caching layer for DHT node responsibility resolution #24

New issue
Closed
opened 2020-05-26 11:59:18 +02:00 by schmittlauch · 1 comment
schmittlauch commented 2020-05-26 11:59:18 +02:00
Owner
Copy link

While triggering a key resolution should always cause network requests and a fresh key resolution (except for keys handled by the own nodes), not each resolution request by the ActivityPub layer on top needs to result in an actual DHT query to be made.

The interface between the ActivityPub service layer and the DHT shall cache associations from cache to node (data) for a certain amount of time.

While triggering a key resolution should always cause network requests and a fresh key resolution (except for keys handled by the own nodes), not each resolution request by the ActivityPub layer on top needs to result in an actual DHT query to be made. The interface between the ActivityPub service layer and the DHT shall cache associations from cache to node (data) for a certain amount of time.
schmittlauch added the
advanced features
DHT
 labels 2020-05-26 11:59:18 +02:00
schmittlauch added this to the 1st round of experiments milestone 2020-06-03 00:55:40 +02:00
schmittlauch commented 2020-07-15 01:02:05 +02:00
Author
Owner
Copy link

  • input: key ID to look up

  • output: hostname, servicePort

    • returning the whole RemoteNodeState would be more future proof in case some other information like node ID were needed
    • but this helps providing a clean interface cut and enforce connection via hostname only

  • caching behaviour:

    • for concurrency: similar to NodeCache handling
    • data structure: tree map (Data.Map.Strict)
    • cache hit: check age, if expired trigger new lookup in DHT (requestQueryID) and schedule update, else return cached entry
    • cache miss: trigger new lookup (requestQueryID) and insert result into cache
    • cleaning: periodic cleaning is needed against atttacker triggering a cache fill up by requesting a large number of random hashtags just once
      • check on each access vs. short cleaning duration
- input: key ID to look up - output: hostname, servicePort - returning the whole RemoteNodeState would be more future proof in case some other information like node ID were needed - but this helps providing a clean interface cut and enforce connection via hostname only - caching behaviour: - for concurrency: similar to NodeCache handling - data structure: tree map (Data.Map.Strict) - cache hit: check age, if expired trigger new lookup in DHT (`requestQueryID`) and schedule update, else return cached entry - cache miss: trigger new lookup (`requestQueryID`) and insert result into cache - cleaning: periodic cleaning is needed against atttacker triggering a cache fill up by requesting a large number of random hashtags just once - check on each access vs. short cleaning duration
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
mainline
k-choices
measurement_logging
instrumentation
fix_networking
data_migration
refactorRingMap
instrumentation_prototype
Labels
Clear labels   
ActivityPub

   
advanced features

   
basic functionality

   
bug

   
DHT

   
evaluation

   
refactoring

   
security

   
test case

an edge case or usage pattern that needs a test

No labels
ActivityPub
advanced features
basic functionality
bug
DHT
evaluation
refactoring
security
test case
Milestone
Clear milestone
No items
No milestone
1st round of experiments
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: schmittlauch/Hash2Pub#24
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?