On Feb 8, 2008, at 8:36 AM, Matthew Toseland wrote:
> On Wednesday 06 February 2008 20:04, robert at freenetproject.org wrote:
>> Author: robert
>> Date: 2008-02-06 20:04:55 +0000 (Wed, 06 Feb 2008)
>> New Revision: 17609
>>
>> Added:
>> trunk/freenet/src/freenet/node/NetworkIDManager.java
>> Modified:
>> trunk/freenet/src/freenet/node/Node.java
>> trunk/freenet/src/freenet/node/NodeDispatcher.java
>> Log:
>> initial SecretPing implementation (for discussion; untested &
>> disabled)
>>
>> [...]
>> + //This is the node that the ping intends to reach, we will *not*
>> forward it; but we might not respond positively either.
>> +//don't set the completed flag, we might reject it from one peer
>> (too short a path) and accept it from another.
> It's very likely that the long path to a node includes the short
> path, and if
> we try the short path and get rejected, we won't be able to use the
> long
> path.
>
> So it's essential that on this path we don't add the UID to the
> recentlyCompleted set.
You are correct, of course; and that is one motivation for initial
random paths. Whereas this is a local connectivity test (not intended
to go deep into the network), I think that this possible behavior
("clogging the only path back to the node") is actually useful so long
as we don't make any single ping the end-all standard. Plus, this is
the only way to detect wide "bridges" between two subnets (which is a
possible way that a Sybil network could otherwise defeat this
mechanism; by connecting to a chain of people who are all peers).
Keep in mind that this is ping is effectively traveling in a circle.
>> + //Set the completed flag immediately for determining reject loops
>> rather than locking the uid.
>> + node.completed(uid);
>
> Now, this is dangerous. If to get to node A you have to go through
> node B, and
> you go through node B with a short path, then you won't be able to
> go through
> node B with a longer path later on because the UID will be rejected.
No... because the uid will change for "later" ping attempts; unless
you are speaking to the same point as above, or I misunderstand your
poing (or general small world topologies).
> IMHO if you want to find long paths you're going to have to start a
> few hops
> out by random routing for a while.
That is the nature of the "dawnHtl", and to the best of my knowledge
it works and does exactly that.
> I'm still not entirely sure I understand what's going on here: are you
> attempting to show that you can connect to a specific node via a
> specific
> subnetwork?
Well.. we are ultimately trying to determine what is a 'subnetwork',
so technically no; I am attempting to find out if we can reach one
peer through another, but am keeping it general enough so that we
could use it however we want to (HTL/Random start, etc).
>> +if (htl<=0) {
>> + //would be dnf if we were looking for data.
>> + source.sendAsync(DMT.createFNPRejectedLoop(uid), null, 0, null);
>> + break;
>> +}
>
> This is gonna visit an awful lot of nodes then ...
Yes... but since it is never reset, the maximum theoretical is (HTL^2)/
2; ignoring probabilistic decrement. If there are any slow local
nodes, there is a much lower practical cap with the fatal timeout. I
was thinking that we will use a smaller htl than 10, although... if
this request is lightweight enough, even visiting 50/100 nodes would
not be terrible.
--
Robert Hailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080208/d59a6b40/attachment.html>
