Changes between Version 21 and Version 22 of NetDB/NextBackend


Ignore:
Timestamp:
Jun 2, 2013 11:31:05 AM (6 years ago)
Author:
hottuna
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NetDB/NextBackend

    v21 v22  
    4848
    4949|| '''Name''' || '''Source''' || '''Description''' ||
    50 || Recursive lookups || R5N[4]|| By making each node in a FIND_VALUE request forward the query recursively and (recursively, to the previous requester in the chain of the recursion) return the answer, a reliability metric of nodes can be obtained.  Which can be used in conjunction with the last_seen attribute of k-bucket entries to create a combined eviction policy. ||
     50|| Recursive lookups || R5N[4]|| Make FIND_VALUE request recursive by forwarding the query recursively and (recursively, to the previous requester in the chain of the recursion) returning the answer, a reliability metric of nodes can be obtained.  Which can be used in conjunction with the last_seen attribute of k-bucket entries to create a combined eviction policy. ||
    5151
    5252
     
    5555
    5656|| '''Name''' || '''Source''' || '''Description''' ||
    57 || Recursive lookups || [6] || Make FIND_VALUE request recursive by forwarding the query recursively and returning the answer directly to the original source of the request.  ||
     57|| Recursive lookups || [6] || Make FIND_VALUE request recursive by forwarding the query recursively and returning the answer directly to the original source of the request. ||
    5858
     59== Proposal ==
     60This is a draft of the proposal.
     61
     62==== 1: Implement Kademlia ====
     63Kademlia is preferable to freenet due to its speed and extendibility and chord/pastry due to being at least as fast but safer. A full routing table will be needed to provide the O(log n) routing that is needed.
     64
     65 * Investigate i2p.zzz.kademlia implementation
     66 * Make sure that i2p.zzz.kademlia implements Kademlia fully
     67   * Implement k-bucket merging
     68
     69==== 2: Improve performance ====
     70For Kademlia to be a viable alternative, lookup speed must be kept high. This means that lookup steps should be kept low and that as many round-trips as possibly should be avoided.
     71
     72 * Implement recursive lookups
     73   * Investigate performance
     74
     75==== 3: Attack resistance ====
     76The two main attack resistance methods will be recursive and random recursive lookups.
     77Recursive lookups are not only fast, but can be be used to provide a lookup success metric that is useful when doing the k-bucket evictions.
     78Random recursive lookups allows FIND_VALUE requesters to eventually find a path to the data if one exists.
     79
     80 * Implement recursive lookup metric
     81   * Change k-bucket eviction policy to also use recursive lookup success metric
     82 * Implement random recursive lookups
     83
     84
     85
     86== Unresolved issues ==
     87==== K-bucket building for recursive lookups ====
     88K-buckets need to be continually updated.
     89In the case of iterative searching, this is not a problem. But when doing recursive searches, the search originator will not get the usual information about nodes that are close to the queried key. [[BR]]
     90[6] suggests to solutions to this issue.
     91'''Source: Direct Mode'''  [[BR]]
     92'''Source: Source-Routing Mode'''  [[BR]]
     93
     94
     95== Further work ==
     96==== Use the locally known nodes as for routing ====
     97If we have nodes in our local NetDB that have distance, d,,xor,, , that is lower than any distance found in the Kademlia routing tables they are good candidates for FIND_VALUE querying. However to find such candidates, the local NetDB has to be sorted, which is expensive.
    5998
    6099[[BR]][[BR]]