On Mon, Dec 19, 2005 at 02:22:36PM +0200, Jusa Saari wrote: > > A simple solution is to have FProxy parse the HTML and identify links > (which it must do anyway to filter images loaded from the Web and > whatever) and add images and other page requisites to the download queue > without the browser needing to ask each of them separately. Still won't > help for getting multiple pages at once, but at least getting an > image-heavy page becomes faster. This would also combat the effect which > makes other than the topmost images drop off the network since no one has > the patience to wait for them.
Wouldn't help much. > > > Now... here is a suggestion of how to change both of these. > > > > Use the "Redirect"-header of the HTTP-protocol. A simple algorithm: > > > > 1) For a connection C, check if data is being downloaded. > > If not, download the data/add download to queue > > 2) If data not retrieved in 30 seconds, set Redirect to the same URL > > and close socket. Continue to get data in background. > > > > Now, let's assume that the webbrowser uses a maximum of one connection > > and round robin to alternate between requests. Then only one connection > > to the fproxy is used at once and all images get an equal amount of > > time. IMHO adding a suitable time-refresh header is very sensible; in theory it ought to get browsers to retry non-iframed images automatically. > > > > If, however, the webbrowser just queues the requests and bangs until the > > first are done until it gives up, the difference will be that new > > connections for new retries will be made every 30 seconds. So; no bigger > > loss. > > > > The main downside is that a browser maybe never gets done loading the > > data if the key is lost forever. How should this be solved? A countup > > after the URL the rdirection goes to, so after a set number of retries, > > the statuspage shows instead? That's how we do it now. > > > > Also, for htmlpages, it's better to use the statuspage (but with more > > information). Some kind of auto-sensening maybe? but this is a pain for > > download managers. -- 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/20051219/b7c78c7b/attachment.pgp>
