On Tuesday 23 Jul 2013 01:45:26 Matthew Toseland wrote:
> What about bundles?
> - Inserts are mainly slow because of the downstream nodes, right? Inserts go 
> to 20+ nodes atm.
> - So the number of parallel bundles necessary, even to maintain full speed, 
> may be relatively low?
> - Lets say we go 5 hops random routed as a bundle (i.e. without diverging). 
> This should get us a significant distance from the originator. Then we random 
> route individual requests for another 2 hops (line + starburst). Then we do 
> normal inserts (but without the don't-cache-at-high-htl hack, since we don't 
> cache up to starting the regular inserts). This would slow down inserts by 
> roughly 1/3rd. If we can limit it to 4 or 5 such bundles, we can probably 
> achieve performance close to not bundling at all, but going the same number 
> of hops.
> - Short term: Accept the requests one at a time. No storage. Possibly check 
> uptime before accepting, maybe option to accept on previous node if it goes 
> down etc.
> - Medium term: Store the data (on disk!). Once sent committed, we will send 
> the data even if we restart. Then insert it (as a local insert). Limit the 
> number pending per peer etc. Fire and forget. Completion: Top block is a 
> FEC'ed SSK/PSK splitfile (fetchable from a single URI, not too big, but 
> divided up among the various bundle inserters), with a highish threshold, so 
> it is completed collaboratively. Security/reliability tradeoff. Possibility 
> of recovering data and doing a regular insert.
> - Long term we'd like to start a large number of inserts all at once at the 
> destination, as this further reduces the possibilities for MAST. But it has 
> load management implications.
> - 20 hops is probably too high anyway - but it may be problematic / 
> significant testing etc to establish the correct HTL.
> 
> Implement basic bundle protocol (no storage, relatively small bundles, 
> probably need an uptime check before accepting), and tests to compare speed 
> of different numbers of bundles vs regular inserts going the same distance. 
> E.g. by a hack to use a lower HTL on starting so they both go the same number 
> of hops. How many bundles do we need to get 80% of the performance of just 
> sending the inserts?
> 
> Even if we send a bundle to every single peer, we'd still have a significant 
> security gain relative to the current situation...
> 
> Various people have contributed to this idea's evolution over the years...
> 
One possible complication nextgens pointed out: We may need to implement the 
bundles API, and group related requests (from the same splitfile insert, or 
even FCP connection), relatively early, i.e. before we formally deploy this. 
Otherwise we have passive attackers picking up correlations between different 
pseudonymous identities.

But testing it to get the basic code and the performance parameters should be 
easy enough.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to