On Sat, May 17, 2003 at 01:24:33PM -0700, Todd Walton wrote:
> On Sat, 17 May 2003, Toad wrote:
> 
> > I would like to point out here that
> > transparent portability to arbitrary future or obscure platforms IS NOT
> > AND NEVER HAS BEEN A CORE PROJECT GOAL.
> 
> Great!  Then we can begin reimplementation of fred in C?  This would have 
> the added benefit of reducing CPU usage.

There are larger issues than portability in the
reimplement-fred-in-my-favourite-language debate. The main one is that
Fred is written in java, and we're not about to take a year or more out
reimplementing it from scratch - it's a waste of resources that should
be spent making Freenet work.
> 
> I would argue that getting as close as possible to "transparent 
> portability" *is* and *always has been* a core project goal.  'Core' in 
> the fullest sense of the word.

Read the web site. Read the goals of the Freenet Project Inc non-profit.
It's pretty clear that portability is a means to an end.
> 
> > Since load balancing is fairly critical to a functioning
> > Freenet, I would like to add this code to Fred at least as an option.
> > Does anyone agree with me?
> 
> It's gonna be messy.

Sure.
> 
> However, handling CPU load is definitely an issue, and it may be that, at 
> this time, installing platform specific code to attack the symptom is more 
> important to the functioning of the network than finding the cause.  At 
> this time.  On the other hand, if the symptom goes away then motivation to 
> find the cause may go away as well.

What if there is no resolvable underlying issue? I'm sure we can speed
up Freenet, but the P120 on a T1 is always going to have problems. In
fact, it may well be the case that (especially with the implementation
of more expensive crypto, e.g. premix routing), a normal node can be
overwhelmed with a particular traffic pattern that fits well within its
available bandwidth.

Load balancing affects everything from probabilistic caching to
anonymity to attack resistance. We must get it right. If we cannot use a
valuable measure of load, we have rather less hope of doing so.
> 
> In any event, if CPU load monitoring gets put in, please make it an option 
> (as you said) and please make it easy to factor out.
> 
> Also, as someone who isn't even working on the problem, I thank you for 
> doing so.
> 
> -todd
-------------- 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/20030517/2e264375/attachment.pgp>

Reply via email to