Florent Daignière wrote:
> * David Sowder <[EMAIL PROTECTED]> [2008-01-03 07:52:44]:
>
>
>> Florent Daignière wrote:
>>
>>> * David Sowder <[EMAIL PROTECTED]> [2008-01-03 07:36:39]:
>>>
>>>
>>>
>>>> Florent Daignière wrote:
>>>>
>>>>
>>>>> * Robert Hailey <[EMAIL PROTECTED]> [2008-01-02 18:23:28]:
>>>>>
>>>>>
>>>>>> On Jan 2, 2008, at 12:30 PM, David Sowder wrote:
>>>>>>
>>>>>>
>>>>>>> I'm not sure of the thinking of others regarding changes to the
>>>>>>> verifiedIncompatible variables since, but my thinking in my initial
>>>>>>> implementation was that they would only be set after a handshake, thus
>>>>>>> we already had a connected to them and ARKs weren't needed. That won't
>>>>>>> change until the peer re-handshakes after restarting with a different
>>>>>>> version of the node's software.
>>>>>>>
>>>>>>>
>>>>>> As best I can see, the verified* booleans have changed meanings since
>>>>>> update-over-mandatory. If it is still useful to know if the peer node
>>>>>> is presently-verified-{older/newer}, then we should split the booleans
>>>>>> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is
>>>>>> an older (as Matthew suggested). In either case the misleading
>>>>>> comments and variable names should be removed and/or changed.
>>>>>>
>>>>>>
>>>>> 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@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
