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. Fixing that is simply a matter of
exchanging either full or differential references with our peers any
time our node's reference changes. 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. In fact, differential references could be trivially
implemented using the existing N2NM messaging facilities.
_______________________________________________
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
