On Thu, 2003-08-07 at 14:45, Ian Clarke wrote:
> The current bandwidth limiting mechanism seems to be causing serious
> problems.  It works by limiting the speed of transmission of data on a
> byte-per-byte basis.  Unfortunately this creates a situation where
> transfers of data occur more slowly, which means they take longer, which
> means that we have more concurrent transfers overall, which slows them
> down even further - and the cycle continues - with the entire Freenet 
> network getting bogged down in a web of extremely slow transfers.
> 
> The alternative is for a node to try to maximize the per-transfer 
> connection speed by rejecting new requests when the upstream connection 
> speed is maxed out.  Some claim that this is a terrible idea and will 
> screw up routing because it will be impossible to get a node to accept a 
> datarequest, but I disagree.  

The problem with that is that it's hard to tell when the upstream
connection is maxed out.  The bandwidth could be set to unlimited, or it
could be set to high, or the node could have a temporary lack of
bandwidth because of other programs using the bandwidth up.

I also don't like the idea of limiting the max number of connections to
some specific number.  This number would be alchemy, and what might be
good for a node on a cable modem might not be good for a node on an OC3.


> Imagine you go to McDonalds and ask a server for some food, they take 
> your order.  Now, you didn't know, but that server is actually serving 
> 20 other people at the same time and consequently it takes you ages to 
> get your food.  Wouldn't it be better if that server said "Sorry Sir, 
> I'm really busy - please try another server".

Shouldn't NGR solve this?  NGR would be like looking going to the
fastest server you know of.  If that server all of a sudden is slower,
try another server next time.  Nobody wants to frequently go back to a
restaurant with poor service.



_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl

Reply via email to