This is all very well, but lets just get the simple functionality working first, then we can worry about more ambitious ways to address the problem.
This always happens, someone suggests a simple idea, then everyone chimes in with how to make it more ambitious, and by the end of it the simple idea has become something so daunting that it never gets implemented. Let's not do that here. Ian. On Tue, Jul 01, 2003 at 10:20:49PM +0100, Toad wrote: > On Tue, Jul 01, 2003 at 04:39:22PM -0400, Nick Tarleton wrote: > > On Tuesday 01 July 2003 04:18 pm, Toad wrote: > > > We can prefetch the front page links on startup. > > The mapfiles and ActiveLinks, or the whole sites? If the last, then > > low-bandwidth users will be horribly annoyed. If there's a config option for > > what to preload, it should NOT default to 'whole site', as new users probably > > won't mess with their config beyond the bare minimum that early. > > Only a problem if they are "low bandwidth users". Who are probably the > minority and shouldn't be running permanent nodes. I wonder if we can > detect modem users somehow... we could use that information... > > > > Prefetching the mapfiles however would be wonderful no matter how you're > > connected. > > Indeed. The original idea was to just fetch the linked pages in the > background i.e. the manifest file and then the index page. Prefetching > too many files could cause excessive network load, especially if it was > done every day, at the time when there is most traffic anyway i.e. the > clock rollover... On the other hand, it would probably be a good idea to > prefetch both the initial frames on TFEE, for example. One obvious > possibility would be to have a general purpose prefetch system where > some metadata in freenet keys indicates pages to prefetch, with some > sort of queue (a stack seems the obvious thing), and the load caused by > prefetching is kept under control by never doing more than a certain > small number of requests (e.g. 1) at once (this is the approach already > taken by the background splitfile healing code). > > There is also an argument for implementing a pool of requests with some > sort of priority system so that when the node is idle it prefetches more, > and when you do 10 splitfile downloads, they all use fewer threads > automatically, but when you only have 1 running, it automatically grabs > as many request "threads" as are available (leaving a few for browsing). > However you still have to consider overall network effects - doing 50 > thread prefetch when idle for half an hour would almost certainly be > disastrous. So perhaps low priority items would only ever have a few > requests allocated to them. The splitfile "threads" side is the most > interesting here, which is also significant for new users. > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. -- Ian Clarke [EMAIL PROTECTED] Coordinator, The Freenet Project http://freenetproject.org/ Founder, Locutus http://locut.us/ Personal Homepage http://locut.us/ian/ _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
