On Monday 10 December 2007 18:52, Robert Hailey wrote: > > On Dec 10, 2007, at 11:49 AM, Matthew Toseland wrote: > > >> In the present network, it probably would; but in theory I think that > >> the patch is correct (or some variant thereto). > > > > Nothing would ever be dropped from the network, because when it's > > considered > > for dropping, it would get reinserted to 20 other nodes! > > I am not recommending that this patch be applied... yet. Every point > that you have raised against it is perfectly valid. In the present > network, because the nodes drift locations soo much, this patch (even > if perfectly tuned; maybe re-insert with HTL=1) would cause data > blocks to "chase" the nodes around the network. Resulting in massive > network traffic increases, as you said. *IF* it helped access of data, > it would only be due to the renewed data being passed through the node > caches (which would probably be overflowed with old insert data). > > My suggestion at present is to: > (1) stabalize node locations enough that data stores come alive, or
Dependant on topology (which we can control), node uptimes (which we can't control), ... > (2) bias/soft-anchor towards what is in the datastore (or perhaps what > has most-recently been put in the data store?). Will not happen without major simulations. > > I agree that either of which would require simulations. Right. And in the latter case, simulating it would be slow, as we'd have to maintain fairly large virtual datastores in the simulation. > #1 would be a > statistical solution (network drift < datastore utility-threshold) and > may be presently attainable with tuning, whereas #2 would be more > pragmatic (and tend to specialize nodes further). #1 may already be > the case if the network size was large enough, but an algorithmically > correct freenet should support any size network (as math scales very > well). IMHO the next step forward is simply to log location changes and display them either on the location page or on a subpage, or as CSV data (or perhaps through SNMP) so it can be graphed externally. Maybe for the node's peers as well as itself. Are you interested in doing some data collection code? Lets discover whether there actually is a problem with location drift before we try to solve it ... Another thing you could do would be to implement a datastore histogram generator. We had one in 0.5. > > As an example of the general problem (although it seems to have helped > get a routable network); even the theory of a node randomizing it's > location totally obsoletes it's datastore. Usually the node will swap back to where it should be within a fairly short period. However, again, we need some hard data from the real network before we even implement simulations. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071210/e1d86024/attachment.pgp>
