[freenet-dev] r19072 - trunk/freenet/src/freenet/client

[Matthew Toseland]

On Tuesday 08 April 2008 19:38, Robert Hailey wrote:
> 
> On Apr 8, 2008, at 9:19 AM, toad at freenetproject.org wrote:
> 
> > Author: toad
> > Date: 2008-04-08 14:19:00 +0000 (Tue, 08 Apr 2008)
> > New Revision: 19072
> >
> > Modified:
> >   trunk/freenet/src/freenet/client/FECCodec.java
> > Log:
> > Increase redundancy from 128 -> 192 to 128 -> 255.
> > This will increase the cost of an upload by 33%, but inserts are  
> > pretty fast right now.
> > We expect it to increase reliability significantly. Redundancy at  
> > the FEC level is far more efficient than redundancy at the simple  
> > block duplication level.
> 
> To help when blocks are dropped out... right...
> 
> I know this has probably already been discussed and rejected, but  
> would it be feasible to add a boolean flag to blocks (to be stored) to  
> indicate if it is a short-term block or long-term? It seems like there  
> are at least two types of traffic: short-term (messages, file  
> transfers, etc) which become irrelevant shortly after posting, and  
> long-term (like freesites, big files, etc) which are intended to be  
> stored as long as possible. But I guess that's if they are naturally  
> decaying...

Most of the short-term traffic is Frost spam, which is just SSKs, because it's 
cheaper to insert SSKs pointing to random CHKs that already exist...

If it wasn't for the spam, it would be equal numbers of SSKs and CHKs, 
assuming a typical message can't fit in 1kB (or has a MIME type).

I don't think short term traffic is that big a part of the total though. Stats 
would be welcome of course. Also any sort of preference system will be abused 
by clients to prioritise their data over everyone else's, and by attackers as 
an extra bit of information to identify what the data is.
> 
> Is this more to do with natural decay, network churn (blocks actually  
> being removed from the network), or nodes just changing location?
> 
> Maybe inserts need to be stored on more nodes' stores (than present  
> 2-3), meaning that the caches (20) do not suffice?

Well, most keys are in fact fetched from the cache, according to the 
statistics.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080408/67497204/attachment.pgp