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. 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. > >>> > >_______________________________________________ > >Devl mailing list > >Devl at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- 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/20060518/12a322ba/attachment.pgp>
