[freenet-dev] r16834 - trunk/freenet/src/freenet/node

[Matthew Toseland]

I agree with Zothar.

On Thursday 03 January 2008 14:33, David Sowder wrote:
> >>>>>>             
> >>>>> We want to fetch ARKs in any case imo.
> >>>>>         
> >>>>>           
> >>>> And in my opinion, fetching an ARK for a connected peer is pointless, 
but 
> >>>> perhaps we agree in our assessments and I misunderstand by thinking you 
> >>>> mean to _always_ fetch ARKs regardless of current peer status.
> >>>>     
> >>>>         
> >>> It's not pointless. We want to keep an up to date "edition" for the ark 
so
> >>> that when we will need it we will be able to reach it... Of course we
> >>> could exchange and update the edition number on handshake... but atm we
> >>> don't.
> >>>   
> >>>       
> >> It is pointless.  If the problem is that we don't have updated ARK 
edition 
> >> numbers, then we should fix that by exchanging that across an existing 
> >> connection when we have one rather than forcing the use of a backwards 
and 
> >> network load causing method for for information we have from a directly 
> >> connected peer.
> >>     
> >
> > It has at least two assets : 1) code simplicity 2) it propagates the ARK
> >   
> IMO, both 1 and 2 are outweighed by the network load of all nodes 
> constantly fetching ARKs for all of their peers network-wide.
> 
> 1) IMO, this is a flimsy argument considering that there are many parts 
> of the Freenet code base that are much more complex than what I'm 
> talking about would require and many of them, while perhaps they could 
> be simpler, have to be somewhat complex by necessity.
> 2) Fetching the ARK on first connect and some number of minutes or hours 
> after the peer tells us via differential references that it has changed 
> would have a much more gentle impact on network load.  It could be 
> argued that if ARKs aren't propagating from their inserts correctly, 
> there is a routing issue.  If we're worried about the ARK falling out of 
> the network, we could fetch it once every seven days after it's last change.
> >> Fixing that is simply a matter of exchanging either full 
> >> or differential references with our peers any time our node's reference 
> >> changes. 
> >>     
> >
> > Lots of things are that simple and in need of doing because noone is
> > available to implement them.
> >   
> Perhaps this one interests me enough to code up if I'm in the right mood 
> after work some day in the coming weeks.  I'll probably implement it on 
> top of N2NMs since they were designed to be generic and I see no reason 
> not to use them as they already support sending arbitrary SFS blocks.
> >> I'm not exactly available to implement it right now, but I know 
> >> for a fact that this is not a hard problem to solve.
> >>     
> >
> > Neither am I
> >
> >   
> >> In fact, differential 
> >> references could be trivially implemented using the existing N2NM 
messaging 
> >> facilities.
> >>     
> >
> > Creating a new DMT message type or extending an existing one is the way
> > to go.
> >   
> 
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 
-------------- 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/20080104/1743c8eb/attachment.pgp