On Saturday 12 May 2012 05:23:25 Steve Dougherty wrote: > I'm still working on the initial implementation of MH-corrected probes > in Fred. I'm pretty close to having minimal functionality working, and > next week I plan to finish up the initial implementation. However, I'm > not happy with the current design, so if anyone would like to take a > look at the bleeding edge of development and possibly offer feedback, > the code is available. [1] This branch is quite rough; before submitting > a pull request or a formal request for review I will rewrite the history > onto another branch with each commit making a reasonable unit of change > along with descriptive commit messages. Which is to say this branch does > not have those properties.
Linear history isn't really a problem. What is a problem is messy code and repeated reverts; rewriting it for a more sensible history is fine, but for the record, don't feel obliged if the only reason is to linearise the history. BTW having reviewed your code, it looks good, although there are various issues being dealt with. > > The probes do not have a concept of acknowledgement or two-stage > (propagated) timeouts. The possible outcomes of a probe request are > a timeout, a node participating in the probe being disconnected, (also > not propagated - only occurs for local disconnection) or a set of > results. The possible results are: Two stage timeouts probably aren't necessary for probes... > > -Swap identifier - useful for network population estimates > -Statistics on uptime: session, 48-hour percentage, and 7-day percentage > -Output bandwidth limit > -Datastore size limit > -Link lengths > -Freenet build Okay. > -Whether a key is found at the endpoint > -The number of nodes along the trace back on which a key is found I'm not sure that I follow. IMHO re keys all we need is to do a normal request - this will tell us about the key's reachability. Being able to determine its prevalence in datastores per 1000 nodes is probably overkill, and may be (mildly) dangerous (not very dangerous as probing stores is pretty easy even if you just have HTL-1 requests). > > Results like link lengths, bandwidth limit, or store size will have a > small amount of random noise added in an attempt to make them less > identifiable. The originating node requests exactly one type of result. > As the request is routed the HTL is probabilistically decremented, with > a very low probability of decrementing at HTL = 1. This is intended to > make it more difficult to interrogate directly connected nodes by > sending them probe requests with HTL = 1. Each node has a hard limit of > how many probes it can be waiting on at any point in time, and will not > respond to requests beyond that limit. Timeout is proportional to HTL. > > The probes are exposed over FCP. A tentative design for the request and > names for responses is available on the wiki. [2] Nodes will be able to > disable any number of these response types, and refusal to respond to a > probe is (intended to be) indistinguishable from a timeout. > > Comments and suggestions are very welcome! > > Thanks, > operhiem1 > > [1] https://github.com/thynix/fred-staging/tree/newProbesDev > [2] https://wiki.freenetproject.org/User:Operhiem1/MHProbeFCP
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
