Now you've got it :) Yes, you're right that artificaly limiting the size of the store is a bad idea (zero-one- infinity rule), but that doesn't stop us from advocating that people keep their store size down.
Setting the datasource diffrently when overloaded is an intresting idea. I'll have to twist my brain around it more. > Mark J Roberts: > > Timm Murray: > > > Over time, the large node simply accumulates more data from Freenet. This means > > > there should be more nodes which point to data on the large node. Thus, there >will > > > be more requests routed to the large node. > > > > Uhh... so? The node's big; it can handle lots of requests. That's > > not a problem. What's a problem is if Freenet says: "Hey, your node > > is 10% better than usual, so let's send every request to it!" I > > don't see why this would happen. > > Looks like I totally, embarassingly missed your point the first time > around... I'll try this again. :} > > You're right: it's true that the bigger your store, the more > requests your node will receive. And overloaded nodes are bad > because they make the network unreliable. So our objective is > obviously to prevent overload. > > Well, I really detest artificially constricting the store size in > order to regulate request load. But I _do_ understand your point > now: larger stores demand more bandwidth. Low-bandwidth nodes need > some way to avoid overload, and constricting the size of the store > is one way to do it. The _wrong_ way to do it.... > > What's creepy about this are the various heuristics proposed to > accomplish it: "don't make a large store!", "if you have Y > bandwidth, use a X megabyte store!", etc. It's impossible to find an > acceptable one. Which means that nodes will have to detect overload > and adjust themselves. Which also means that we can stop promoting > this dangerous small-store idea - the recommended size of the store > should be based on the memory required to index its contents. > > One solution might be to, when overloaded, set the datasource not to > yourself but to where you would've routed the request if you didn't > have the data. You'd really actually use a probability scaled by the > current throughput. > > Needs more processing. > > _______________________________________________ > Chat mailing list > [EMAIL PROTECTED] > http://lists.freenetproject.org/mailman/listinfo/chat > _______________________________________________ Chat mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/chat
