I disagree. The way they are used now, they just indicate whether the node is routable, and for what reason. The only reason for them being like that in the past was that we would connect to nodes which are unroutable, and then disconnect and periodically do version probes. We don't need to do this now, because we keep open connections to incompatible nodes for purposes of Update Over Mandatory.
On Thursday 03 January 2008 00:45, David Sowder (Zothar) wrote: > In my thinking, we should only change verifiedIncompatibleOlderVersion > and verifiedIncompatibleNewerVersion in four situations, all of which > may even mean that we call a function/method to check for the need to > change in the code paths that are common to each of these situations: > > 1) Potentially set when we've just completed a handshake and therefore > are connected and isConnected() is true (not necessarily isRoutable() > for whatever reason) after which we have no need to fetch an ARK for the > peer > 2) Cleared if we are disconnecting (for whatever reason) from a peer > that has had either verifiedIncompatibleOlderVersion or > verifiedIncompatibleNewerVersion set, after which we may want to fetch > an ARK for the peer just like we would if we had never connected to them > since our last restart > 3) Set verifiedIncompatibleOlderVersion when our node passes a mandatory > threshold date and time > 4) Set verifiedIncompatibleNewerVersion when the peer tells us we are > too old for their idea of the mandatory threshold date and time (I don't > recall by what mechanism this is accomplished ATM) > > Once verifiedIncompatibleOlderVersion or > verifiedIncompatibleNewerVersion is set for a peer, it cannot be cleared > by any means other than the peer reconnecting (either by a intermediate > DISCONNECTED, etc. state or by boot ID change (if I understand that > name/concept correctly)) after their restart or by our node's > initializing the value to it's default False value on our node's restart. > > Caveat the above by the fact that I haven't read this related code in > awhile, so I'm going by my memory of how it should work and what I > remember of changes made by others since. > > Matthew Toseland wrote: > > On Wednesday 02 January 2008 18:30, David Sowder wrote: > > > >> I'm not sure of the thinking of others regarding changes to the > >> verifiedIncompatible variables since, but my thinking in my initial > >> implementation was that they would only be set after a handshake, thus > >> we already had a connected to them and ARKs weren't needed. That won't > >> change until the peer re-handshakes after restarting with a different > >> version of the node's software. > >> > > > > I don't follow - clearly if isConnected(), we don't need the ARK. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080104/a80e2a75/attachment.pgp>
