Tyler Riddle <triddle_1999 at yahoo.com> writes: > Thank you so much Edgar =) > [snip] > > > > > I don't know how the conversation got to the topic > > of nodes guessing > > other nodes' specialization. This started about > > whether a node could > > guess what other nodes believe its specialization > > is. > > I took a temporary steer in that direction to feel the > waters for how for sneakernet may negatively impact > the rest of the network. I really should of asked > directly, do you think sneakernet (in this > incarnation) could be abused to cause a dedgregation > of network performace? The case of a node operator > importing hundreds of megs of new keys and purging his > datastore is obvious but is there another method that > might be used? > It's contrary the design of freenet to put data into the store that hasn't been requested, nor to put references into the routing table (with the exception of a initial seeding for bootstrapping purposes only) unless they're the result of a successful request/insert. I'm still unconvinced that shuffling data around like this has enough value for the investment.
The one thing I see sneakernet being used for is to break MitM assumptions, i.e. no incoming request came within 10 minutes of this request going out, thus the request was locally initiated. Having requests enter freenet via a few hops of sneaker-level mixmastering would be interesting, though. > [snip] > > > > The reason I think that trying to model a node's > > specialization within > > a node is futile is because specialization is a > > function of the > > routing tables of many many nodes. Since freenet > > makes it > > purposefully difficult to model the global routing, > > trying to build > > functions on top of code that attempts to do this in > > realtime looks to > > me like the height of folly. > > > > I agree - doing this in realtime is not a good idea. I > was thinking of a procedure like this: > Doing it offline/non-realtime may not be the height of folly, but it's still a bad idea because of the amount of unknown information that'd be needed to really assert any kind of specialization. > Assuming an individual just received his new > sneakernet media and is ready to do an import. Fred, > on a permanent node, needs to figure out which keys on > that cd are going to help him. At this point, prior to > the import, analyze the datastore and look for the > statistical anamolies (this is not a realtime process, > nothing is kept in memory in fred, etc) - use this > information to guess which keys might be good to pull > off the cd. > > Of course it is not perfect but is it close enough to > be of any use? If we can't come up with a system where > importing keys into a permanent node makes sense I say > we just forget that part of it. Sneakernet still has a > good use for transient users in that it can provide > them plausable denibility. Permanent node users in > this case only export information into sneakernet and > import it only if they feel like it. This way it is of > mamximum use to the entire network. > I don't see any system for importing keys into a permenant node being worthwhile at all, with the exception of normal inserts. > I am confident that I can spearhead a team to code > this up, it seems like a simple enough modification to > fred. I also know a couple people who are very > interested in seeing this happen as well as getting > active in freenet development. I would need, at most, > some support in understanding fred's internals. I > don't expect you guys to write this for me but would > you accept a patch to integrate into fred? > > Thanks for your help Edgar, > > Tyler > > ===== > AIM:rllybites Y! Messenger:triddle_1999 > A lot of little patches that build up to an entire sneakernet transport may be acceptable; one megapatch that does the whole thing will not be. Also, be careful about all the places in fred where code assumes TCP, if you're going to use the existing transport framework. Thelema -- E-mail: thelema314 at swbell.net Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
