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 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.
