On Sunday 20 July 2003 11:49 am, Todd Walton wrote: > 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.)
Not a big problem, look how long even unpopular one shot sites last. > > 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? AltDbrUrl != yesterdays edition. I was very confused by this at first. In fact I'm still confused by it's purpose. However it is a way to access todays version, without having to look up the DBR redirect. It uses a static URL that contains todays date in seconds since 1970. If someone would like to explain this better, as well as how / why this is inserted into the network, please do. Anyway what this amounts to from the users prospective, is a way to get todays edition of the site when the normal way fails, and we don't want to get yesterdays edition. > > 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? 6, 7, and 8 really go together. I probably should have made it one item. > > 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.) The idea is that if you do 8, you will be able to fetch the data more relyably. However then you have little recourse it it fails. So you do 6. This means if the first node we ask with htl 15 fails, rather then sending it back to the UI and retrying with 17, we start with a higher number like 19 and then if our first choice fails, we go to the next best choice, like normal. Except we don't timeout, because it is a local request. If you are doing this, requests for data that does really not exist puts a higher load on the network. To combat this you eliminate the UI retrying the data automatically. (We are doing that internally now) And you try to lower your request htl for data that is not likely to be in the network. > > 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. Not so much. It is really easy to add "htl=19" or whatever to bookmarks on the main page. You could even calculate this as, say default htl +4. Also you could automatically add +2 to the default htl for links to CHKs from the web interface that the user clicks and -1 to KSKs. Not too hard. Then because the UI is not automatically retrying all the time nodes are not hammered for requests of NIMs etc that aren't on the network. > > > 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? No, but depending on your time zone, you could be just browsing a site, you click a link to a sub page, and all of the sudden it's not accessable when it was 10min ago. One way to handle this would be to have a config option like: don't fetch todays editions until XX:XX local time. > The TUK idea, or some other more flexible updating scheme, would probably > moot this issue. Yes, TUK would be great, but nobody even seems to have a plan for how this will work. One way I have seen something like this done before, is to give every piece of data an expiration date. Then if the data has expired, rather than deleting it, when the node gets a request for it, it asks upstream: "I got a version of X with checksum y is this current?" Then it ether gets "Yes, here is the new experation date.", "No, here is the new version.", or "No updated reference found in network.". The key to getting this to work is sighing the times. Otherwise any node could just make up a date and fill the network with out dated information. However this does not really solve the problem, because publishers still need to know in advance when the next version will be out. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
