On Feb 8, 2008, at 8:36 AM, Matthew Toseland wrote:
On Wednesday 06 February 2008 20:04, [EMAIL PROTECTED] 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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
