On Fri, Jan 13, 2006 at 12:18:29AM +0200, Jusa Saari wrote: > On Wed, 04 Jan 2006 18:26:27 +0000, Matthew Toseland wrote: > > > > Even with your browser using 24-36 connections? In 0.5, fproxy will allow > > between 24 and 36 parallel fproxy connections, and we recommend that > > browsers are set up to use many connections. > > Sorry it took so long to respond, been busy with other things. > > If I set my browser to use 24 connections, what will happen when I try to > connect to a regular web site ? I consider myself a pretty technical > person, but I have no idea how to set Firefox to use 24 connections on > localhost and 2 elsewhere...
It will increase the load on the server due to more connections. > > Better not give recommendations that have the chance of earning Freenet > project bad reputation. True. So what you're saying is prefetch the inline images on a page, in order to avoid such issues. Hmm, maybe. > > > I can see the argument for prefetching images... It's probably not > > something I will implement before 0.7 though... > >> > >> > If yes, the impact on the network would be interesting to see when > >> > fetching TFE or any other index site... If the network's well > >> > structured it won't break upon the millions of requests... > >> > otherwise... :) > >> > >> Of course it will break in your scenario. It will be impossible to > >> distinguish between often-retrieved and never-retrieved content, so the > >> caching facilities won't work properly, and the network will grind to a > >> screeching halt as it gets hopelessly overloaded, making it impossible > >> to retrieve anything. > > > > :) > > > > Don't you think everyone will have a 50GB download queue anyway for Big > > Files? In which case prefetching fproxy content might actually be the best > > thing to do? > > Hmm... If we can differentiate between "things that can be shown in the > browser" (images and HTML) and everything else, why not ? Just make sure > to not start infinite recursing by accident - only add links from a page > to the queue when that page is actually shown in the browser. > > And of course things added in this way should get priority over large > downloads. Reserve half the queue for them, and the other half for > downloading Big Files ; that way those downloads still proceed, even when > the user is browsing a lot, and on the other hand, having downloads > running in the background doesn't block browsing. Sure, priorities are essential in a download queue system which integrates prefetch. They make it feasible. > > Oh, and you might add a page in the Web Interface, that shows the links > for the websites that are currently available without delay. Possibly, yeah. I was thinking of having a feed page showing which recently visited or explicitly subscribed sites have updated recently... > > Of course all this means that anyone who can get his hands on the machine > is going to be able to figure out where you've been surfing; but then > again, that is impossible to prevent anyway. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060112/9d9cda39/attachment.pgp>
