Represent neighbours as composite datatype of RingMap and lazy list representation #51
Labels
No labels
ActivityPub
advanced features
basic functionality
bug
DHT
evaluation
refactoring
security
test case
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: schmittlauch/Hash2Pub#51
Loading…
Reference in a new issue
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?
Currently, neighbours of a node (predecessors, successors) are represented as a sorted list, but need to be converted to a RingMap for all modifications and then back again to a List, each with a complexity of O(n).
list representation: allows ordered head access, indexed access, slicing
RingMap representation: required for modular sorting on ring in successor/ predecessor direction
Idea for reducing number of conversions:
nieghbours of one direction are a composite type (product type?) of
Maybe [RemoteNodeState]
andRingMap RemoteNodeState
.All modifications are done immediately on the RingMap representation, the list representation is invalidated (set to
Nothing
). On demand (list read access), the list representation is generated, wrapped into aJust
and stored.If the size of the RingMap exceeds 2 * kNeighbours, it needs to be purged from unnecessary intries (e.g. by converting it to a list of kNeighbours and back).
disadvantage: makes read-only operation to a possible read-write operation as list-representation-generation can be triggered by each read.