* David Sowder <freenet-devl at david.sowder.com> [2008-01-03 07:52:44]:
> Florent Daigni?re wrote:
>> * David Sowder <freenet-devl at david.sowder.com> [2008-01-03 07:36:39]:
>>
>>
>>> Florent Daigni?re wrote:
>>>
>>>> * Robert Hailey <robert at emu.freenetproject.org> [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
> 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.
> 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.
NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080103/b219de47/attachment.pgp>
