On Sat, 19 Jul 2003, Tom Kaitchuck wrote: > When browsing Freenet just after the date rollover can be very annoying. It is > almost unusable for a period of time. Many DBR don't get their sites out soon > enough, or don't have enough time to distribute them before people start > requesting the new versions. This is in part due to variations in different > peoples clocks. However the fact that a request failed because the content is > not yet widely distributed is not helped by the fact that it is going to be > in the failure table of various nodes for some time. > > Ways this could be improved from the users prospective: > 1. Warn users to make sure their date/time is set correctly.
Sounds sensible. We should anyway. > 2. Tell site owners to insert before the last minute. But then you run into the problem of inserting too early, which leads to bits dropping out of Freenet before they're requested. (I'm not sure *how* much that would be a problem.) > 4. If a site fails, automatically try altdbrurl BEFORE prompting the user. But what if I don't want altdbrurl? What if I know the updated site is out, I just can't retrieve it on the first try? > 6. Eliminate the random first step in routing. (Introduce other mechanisms to > replace it's functionality) This way the queries form the local node can be > routed normally. (Querying the best host then retrying with the next best > etc.) Although we probably shouldn't timeout on out own node :) How would this help the problem you described above? > 7. To eliminate unnecessary network requests, don't retry automaticlay. Most > failed requests are caused by data that does not exist. If the user wants it > they can click retry. How would this help the problem you described above? Automatic retries, I'd say, *help* the situation. If the data really doesn't exist, it'll give up eventually, and if it does exist, then the request will make it through and the data will be distributed better. Also, is it still true that when data comes in, fred will compare it to recently (failed) requested data and, if there's a match, notify the requesting node? (I seem to remember some such.) > 8. So that the user does not have to click retry, make the initial HTL > proportional to how likely we believe the data is on the network. For example > pages linked to from the main page should automatically be given the maximum > initial default HTL. (We are prefetching these anyway as I recall.) Links > that go to CHKs/One shot SSKs/CHK images should get a High initial default > HTL. Finally links to Future edition sites, NIMs, KSKs should get a low > initial default HTL. Note: the difference between the various HTLs should not > be huge otherwise it might become too self reinforcing. Too much brains. > 9. Improve routing ;) That's a good idea. Really, I don't think the problem you describe is really that much of a problem. Do people really sit crouched over their mouse, trigger finger at the ready, waiting for the rollover so that they can get the new day's worth of DBR sites? The TUK idea, or some other more flexible updating scheme, would probably moot this issue. -todd _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
