On Fri, Aug 08, 2003 at 01:59:49AM +0100, Toad wrote: > How will this limit output bandwidth, on even a minute by minute basis?
It is true that this approach has a slower feedback-loop than reimplementing a Quality of Service TCP/IP stack within Freenet, as you seem determined to do - but it is the natural way for Freenet to reduce its bandwidth usage (namely, not to take on more work when it is overloaded), rather than taking on more work - but just doing it more slowly. Does it guarantee that if someone gets out Ethereal and starts to collect statistics that Freenet won't occasionally exceed the bandwidth allocation? No, it doesn't. Will it mean that Freenet tries to stick to the bandwidth allocation using reasonable means - yes it does - and I suspect that will be enough for 99.9% of Freenet's users. > Users will regularly, and as part of the network's normal behaviour, > have their link saturated by unluckily having a few downloads from > people with fast links. Only if the next slowest person in the reply-chain is faster than their total upstream allocated bandwidth. I am sure you can agree that this will be rare unless their internet connection involves smoke signals. > Since we want people to run freenet 24x7 in the > background, in parallel to their regular browsing, this is a bad thing. For those subscribed to SmokeSignalLink - yes, you may be right. My apologies to Freenet's isolated 17th century Navajo users. > How will you limit incoming transfers? By rejecting the requests that lead to incoming transfers in the first place. Ian. -- Ian Clarke [EMAIL PROTECTED] Coordinator, The Freenet Project http://freenetproject.org/ Weblog http://slashdot.org/~sanity/journal
pgp00000.pgp
Description: PGP signature
