On Sun, 16 Apr 2000, hal at finney.org wrote:
> You need an algorithm which will (A) find the data in the college
> network if it's there (so as to avoid load on gateways), (B) find the
> data anyway out in the world if it's not in the local network, and (C)
> not require HTL to be much more than it is now.
I'm just going to toss thoughts around and see what pops out.
Taking your 10^6 nodes/HTL=5 numbers, that means each hop chooses
between ~16 nodes (16^5 ~=10^6). That means !1.3 hops get spent
in our 100 node local network (16^1.3~=100).
If we want to do a more exhaustive search of the local network,
we should increase the hops spent in that network. That means that
we either do a less exhaustive search of the remaining nodes, or we
increase the HTL of the entire search.
We want to take latency/throughput into effect because using
faster nodes uses less time and fewer network resources. We can
have "cheaper" discussions with fast nodes.
We use HTL to specify a certain level of tradeoff between the
time (and network load) and completeness of a search. If we
absolutely *must* know without doubt whether a key exists, we
would use an HTL equal to the number of nodes in the network. If
we only want the information if we can have it *now*, we would use
HTL equals zero.
A node cannot (and should not) know what paths a search will take
after forwarding it. It follows that a node shouldn't increase HTL
"expecting" to use a fast network.
What would happen if we allowed non-integral HTL's? We could
define a "standard" connection to have HTL 1. Connections faster
than the standard would have HTL < 1, slower would have HTL > 1. The
1.3 hops that our college network is alotted might actually
represent 1.5 or 2.0 physical hops.
Completely leaving aside implementation issues for the moment, and
assuming that we can actually define a "standard" connection, does
anybody see problems with this?
>
> One possibility would be to use a strict key-closeness criterion for
> small HTL (the same algorithm we have now), while weighting performance
> issues more highly for larger HTL. For example, you could start with
> a somewhat larger HTL, maybe 7 or so, and weight the algorithm so the
> first 2 hops would be within the college network, and if they fail do
> the remaining 5 hops out into the world.
This would work, but it would bias us toward fast networks only
at the beginning of our search. If (for example) our college network
was connected to the outside world over a single 56K modem, your plan
would help optimize outgoing requests, but we would never receive
incoming requests.
-mike
>
> Hal
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--
"Modern electronic-rock music, inaugurated in the early 1960s, is, and
always has been, a joint enterprise of British military intelligence
and Satanic cults."
-- "The Satanic Roots of Rock"
http://www.av1611.org/othpubls/roots.html
GnuPG key available at http://devel.duluoz.net/pubkey.asc
Key ID = 1024D/9A256AE5 1999-11-13 Mike Glover <mpg4 at duluoz.net>
Key fingerprint = EF6E 8BCB 4810 E98C F0FD 4596 367A 32B7 9A25 6AE5
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
