BCoates suggested a possibility for working around the browser max
threads issue. It goes like this: bind to a whole range of addresses on
localhost, not just 127.0.0.1 (can we bind to 50 addresses with less
than 50 threads? If not with current java, then with NBIO?), and
randomly redirect requests that come in on 127.0.0.1 to the other 
"servers".
Pro:
* We are only limited by the browser total connections limit (unless it
  counts 127.0.0.0/8 as a single address, which seems unlikely).
* We do not need people to reconfigure their browser to get acceptable
  performance loading TFE.
* We will probably implement prefetch hints (or prefetching inline
  images) eventually, which has some of the same goals... but this hack
  would be much more helpful if many of the images are going to DNF
  (slowly).
Con:
* We may need one thread to listen on each address.
* We will need to limit the requests on the node end. However, we need
  to do this anyway, for browsers that don't limit or have more liberal
  limits, and some of the same code would be useful for parallel
  splitfile downloads etc.
* The browser set the per host limit lower than the overall limit for a
  reason, which is to enable the user to visit multiple sites at once.
  If we hack around it this way, unless the number of connections is
  well under the browser limit (which we don't necessarily know), the
  user will probably lose this ability.

Certainly if we implement it it would need to be configurable, and I'm
inclined to leave it for 0.5.2 and the client side load allocation
thingy I'm gonna have to write for splitfile downloads, but what do
people think about this?
-- 
Matthew Toseland
toad at amphibian.dyndns.org/amphibian at users.sourceforge.net
Freenet/Coldstore open source hacker.
Contracted full time by Freenet Project Inc.
http://freenetproject.org/
ICTHUS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20030109/8212b3b2/attachment.pgp>

Reply via email to