Matthew Toseland wrote:
> They should see it when they try to connect; we exchange references, and
> then it fails.
>
> At least, that's the theory. There is actually a bug filed about this;
> I'm not sure what the actual fact is, somebody needs to test this.
>
Happen to know the bug number? I may have pretty much tested this in my
testing for the r8754 and r8755
> On Thu, May 18, 2006 at 01:29:43PM +0200, freenetwork at web.de wrote:
>
>> Thanks to both Davids, that cleared it up, I vaguely thought it would work
>> like this.
>>
>> But isn't the "border" between too new and too old builds creating an event
>> horizon, a network separation as the old nodes behind the border don't know
>> that they are outdated (unless a direct neighbor updates his node and places
>> a new "seed" for the current
>> lastGoodBuild)? If the border nodes don't upgrade (any supposing freenet is
>> run all day long as a daemon in the background without user intervention and
>> attention) the old nodes won't see the newer lastGoodBuild.
>>
>> I would not like to have the lastGoodBuild to be propagated as that would
>> open a can of worms, but how to address above?
>>
>>
>>
>>> freenetwork at web.de wrote:
>>>
>>>> What if someone forges his reference and sets lastGoodBuild=9999 ? How
>>>> will that affect this?
>>>> How ist lastGoodBuild propagated anyway? Is it propagated? What are the
>>>> implications for the network if one or more nodes are forging
>>>> lastGoodBuild?
>>>>
>>>>
>>> A node running r8755 or higher simply won't connect to such a rogue node
>>> since they are too new for our node. Likewise, unless the rogue node
>>> changes some code in the process, his node won't connect with anybody
>>> else's either. There are much more sinister things such a rogue node
>>> could try to do than fake a lastGoodBuild.
>>>
>>> lastGoodBuild is "propagated" by people upgrading their nodes to new
>>> software. A node does not start advertising a new lastGoodVersion (the
>>> noderef version of lastGoodBuild) by any means other than getting
>>> upgraded to a newer version of software that declares a different
>>> lastGoodBuild. A node does not "adopt" a lastGoodVersion advertised by
>>> another node as it's own advertised lastGoodVersion, nor does it treat
>>> it internally as it's lastGoodBuild (it would immediately stop
>>> connecting to anybody if it did anyway... :).
>>>
>>> If there are any existing problems with rogue nodes advertising fake
>>> lastGoodVersions, my recent looking at the code suggests that they're
>>> very subtle and hard to notice as the current mechanism looks solid to me.
>>>
>>>>> Author: zothar
>>>>> Date: 2006-05-18 03:57:03 +0000 (Thu, 18 May 2006)
>>>>> New Revision: 8755
>>>>>
>>>>> Modified:
>>>>> trunk/freenet/src/freenet/node/PeerNode.java
>>>>> Log:
>>>>> Activate the user build too old alerting commited in r8754. We only aler=
>>>>> t if we get a handshake request from a peer that's still advertising a la=
>>>>> stGoodVersion that's newer than our version. This allows the lastGoodVer=
>>>>> sion to be lowered and thus older nodes would potentially be able to conn=
>>>>> ect again. This commit also removes the handshake timer renew when we re=
>>>>> ceive a handshake from a peer that's too old because, otherwise, that mig=
>>>>> ht prevent us from sending them our ref (and the latest lastGoodVersion i=
>>>>> nformation) in a handshake request sent to them. Persons running builds =
>>>>> after this that are too old should get the idea pretty quick with a user =
>>>>> alert on the welcome page and one or more peers in "TOO NEW" status on th=
>>>>> e Darknet Connections page.
>>>>>
