Oskar Sandberg writes:
We discussed this, but decided that we would rather have a system
where you set the htl a little higher and where it contains and
absolute control over the number of messages sent because of the
request (if the htl is reset on every RequestFailed, then a Request
could in theory go on until it has touched the entire network).
This makes no sense to me:
1. What are you setting the HopsToLive a little higher than? The
incoming HopsToLive could easily be 1 (or 0), which is unlikely to be
higher than either of the choices I proposed.
2. I don't see any correlation between the HopsToLive of the
RequestFailed and the number of nodes visited by a DataRequest. The
outgoing DataRequest's HopsToLive is always one less than the value of
the incoming DataRequest had.
3. If a node receives a RequestFailed, and has no other options for
forwarding the DataRequest, it sends a RequestFailed to the node it
received the DataRequest from. As things stand, this RequestFailed
has the bizarre property that its HopsToLive is *larger* than the
RequestFailed that the node just received. In essence, the protocol
calls for nodes to increment the HopsToLive value of a RequestFailed
instead of decrementing it.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
