On 5/24/06, David Sowder (Zothar) <freenet-devl at david.sowder.com> wrote: > freenetwork at web.de wrote: > > Hi you guys, > > > > today I fired up an old node I had (previously updated it to current cvs > > but used old node and peers). It had 1 connection and around a dozen of > > nodes that were outdated and had their version number colored red at the > > darknet page. > > It seemed to me that the outdated nodes were never tried to connect. > > Perhaps they are really dead and gone, because one node came up with > > "connected", but my question is - if noderefs are from outdated nodes, does > > my node try to connect to them or not? > > Wondering I loaded the starting page and saw that 0 ARKS were being fetched > > - so are outdated nodes not checked for their inserted ARKs? > > > > I'm just wondering because if i have old referenced to other nodes, these > > nodes will have old references to my node. If my node does not try to > > connect to them because they are too old, they will not try to connect to > > mine either. So even if both nodes are up and healthy > > they would not connect to each other, despite they have each other's ref > > becuase they are considered too old. > > > > Am I way off here? > > > The /darknet/ page currently indicates nodes that, based on last > information available, are either too old or too new for our current > version in two ways. > > The first is that, based on the ref we currently have for the node, the > node's version will be marked in red rather than in black. > > The second is that, based on a ref we currently have for the node and > only after receiving the latest ref from that node in a handshake since > our node was last started, we'll either display a status of > "INCOMPATIBLE" for that node if it is older than our node's > lastGoodBuild or "TOO NEW" if our version is older than the peer node > ref's lastGoodVersion. This status is considered "verified" in the > Freenet code because it requires traffic from the peer to get the latest > information available and our Freenet node will continue to periodically > send handshake requests to such peer nodes to ensure that they have the > latest information that we have and to, in part, keep any firewall/NAT > UDP port holes punched. > > Unless there is a bug, the starting/wecome page ARK fetch request count > should be correct. Also, unless there is a bug, ARKs will be requested > for any host that is listed on the /darknet/ page as "DISCONNECTED". > ARKs will NOT be requested for nodes listed on the /darknet/ page as > "INCOMPATIBLE" nor nodes listed as "TOO NEW" because we already know we > had connectivity with them to mark them as "INCOMPATIBLE" or "TOO NEW". > Should the peer upgrade, we'll know to change their status based on them > sending us a handshake request with their new information, which they
If our node is NATed then they may not ever be able to connect to us if DNATing it not setup. > will be able to do based on our still publishing our most up to date ARK > and both parties UDP hole punching efforts, regardless of peer version > or requesting or not of the other peer's ARK. > > Bottom line: > Since a handshake request is how a node attempts to connect with another > node, a node will always try to connect to peers that aren't already > connected (status of either "CONNECTED" or "BACKED OFF") no matter why > they're not already connected. (The node just doesn't necessarily > expect to successfully connect in the case of a "INCOMPATIBLE" and "TOO > NEW" status, but, well, the idea of expectation is more of a code > comments matter than the actual program code. :) > > I hope that clears up anything that was murky. If not, please let me > know and I'll try to fix the problem or help "clean" things. > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
