On Fri, Jun 02, 2006 at 08:13:55AM -0400, Colin Davis wrote:
> 
> I think the first thing to do is to add a warning, when the node is  
> spending more than XXX% of it's bandwidth/time checking node status.
> 
> Ie, if it's sending out X ARK retch requests, versus 1/2 X in  
> requests/Inserts, there is a problem, and there should be a warning  
> on the main fproxy page.

Possibly.
> 
> The second is to change the delay between checks to see if a node is  
> back up.

No. Some NATs have tunnel timeouts of under 30 seconds. We cannot
therefore increase the delay over that amount. That is the unfortunate
reality; everyone is NATted, and it's a PITA, but that's life.
> 
> As I understand the current system, it's a formula based on the age  
> of the build, the time we've seen it most recently, how often it's  
> connected, and other factors.
> 
> I think it might make sense to make this value increase  
> exponentially, until it hits a max value, set in freenet.ini
> Ie, Start at 10 seconds, go to 1 minute, then 1 hour, then every 10  
> hours. Remain at 10 hours (or whatever value is in freenet.ini) until  
> further notice.
> 
> Doing this negates much of the penalty for having disconnected users.  
> It allows people to have them without hurting their bandwidth.

We did this in 0.5. We can't do it any more because of short tunnel
timeouts on NATs.
> 
> Transient nodes aren't hurt, since if the node RECEIVES a packet from  
> the Just-started transient node, it will immediately consider that  
> node current. It puts the burden on the transient node to tell its  
> peers its back up.

It won't receive it because the tunnel will have closed. We can do
things like this if we are SURE that the port is forwarded, but even
UP&P isn't reliable from what I have heard. So we have to assume that
most connections will need UDP hole punching.
> 
> I'm thinking about implementing an exponential scale in my build, but  
> I think it makes sense to have it generically.
-- 
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/devl/attachments/20060602/ab83038e/attachment.pgp>

Reply via email to