-
Notifications
You must be signed in to change notification settings - Fork 2
Probes
These were introduced with build 1409, and allow gathering statistics from the network in a privacy-conscious and statistically valid way.
To be privacy-conscious, the probes report only a small amount of information at once, and add random noise where appropriate so that the returned information will be less identifiable, yet still useful for statistical purposes.
Individual result types can also be opted out of, and the endpoint identifier used only for probes can be set or randomized at will. To be statistically valid, the probes avoid bias towards well-connected endpoints with Metropolis-Hastings correction. Depending on the network size, and with sufficient hops to live, a probe response can be considered to be from a node selected uniformly at random from the entire network.
A node begins a probe request by sending a probe request message to one of its peers. Whenever a node receives a request, if the request has more hops to make it will attempt to forward it to one of its peers, not taking into consideration back-off or loops so as to avoid bias.
To protect the anonymity of the endpoint, the hops to live are not always decremented from one; (probabilistic decrement) requests are answered at zero. If the node has been set to opt out of a result type it will respond with a refusal. The probes are available over FCP.
Bandwidth (source)
Reports outgoing bandwidth limit in KiB/s
Intended ambiguity: 1 KiB/s
Build (source)
Reports main Freenet version
Identifier (source)
Reports an identifier used only for probes and quantized 7-day uptime percentage.
Intended ambiguity: 1.68 hours
Link lengths (source)
Reports difference in location between the endpoint and each of its peers.
Intended ambiguity: 0.002
Location (source)
Reports network location
Reduced precision
Datastore size (source)
Reports datastore size in GiB
Intended ambiguity: 1 GiB
48-hour Uptime (source)
Reports percentage uptime over the last 48 hours
Intended ambiguity half an hour
7-day Uptime (source)
Reports percentage update over the last 7 days
Intended ambiguity one hour
Probes are started over FCP, at which point they are forwarded from the local node. Requests received from remote nodes are also forwarded. With the exceptions of FCP messages and DMT messages, the probe code is in the freenet.node.probe package.
FCP allows starting probe requests and receiving responses with the ProbeRequest message. source
The response message from the node varies depending on the requested result type, and whether there was an error or the endpoint opted not to respond.
Each node uses per-peer rate limiting. This is implemented with a counter associated with each peer. Probes started locally also have a counter, though this has a higher limit. When a probe request is received, after parsing it the counter for that peer is checked. If the counter is not at its maximum, it is incremented, and scheduled to be decremented 60 seconds later. Counters are cleaned up by being removed when they hit zero.
A node will select a peer at random.
By default nodes will share their peers' locations (Friend Of A Friend locations) to assist with routing.
The number of reported peer locations is used to determine peer degree for the Metropolis-Hastings routing correction.
The correction means that depending on the ratio of local and remote degree, a selected peer can be rejected in favor of a new selection. If the Metropolis-Hastings correction rejects a peer, the hops to live is decremented.
This means a local response can occur at times other than immediately after receiving the request. A node is limited in how many send attempts it can make without forwarding, and if this limit is reached it will return an error to the requesting node.
When the hops to live value reaches zero, the node sends a response back to the node it received the request from, applying noise for a level of ambiguity depending on the result type.
A small randomized delay is added before sending the response in an attempt for further anonymity protection (in addition to the probabilistic decrement) - the request might have been forwarded further.
If the user has opted out of that result type, it sends a refusal instead. Each node in the chain returns the result back to the node it received the request from, until the chain ends at the node which made the request. In the event of connectivity problems such as disconnection or timeout, an error will be propagated earlier on in the chain in the same fashion.