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: <https://emu.freenetproject.org/pipermail/devl/attachments/20080104/1743c8eb/attachment.pgp>
