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.
>>>     
>_______________________________________________
>Devl mailing list
>Devl at freenetproject.org
>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl










Reply via email to