High: zealous local address matching with the same subnet entries #52
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, having booth components on the same subnet could seriously
confuse self-determination of those tolerating fuzziness when doing so
(i.e., not site nor arbitrator).
It would be the case when there are two (or more) addresses sharing the
same network part of the address as one of the actual hosts's addresses
(assigned to one of its interfaces), and the exactly matching one is
listed after at least a single network-part-match-only one ("fuzzy"
match). Due to the original requirement that any subsequent candidate
would have to beat a running winner in the length of the network prefix,
such exact match could never have been tested and hence missed.
(IOW, algorithm used to search for local, not global maximum in some
circumstances).
Now we allow further examination of the candidate with the same length
of the network prefix as a running winner, which -- moreover -- cannot
be the exact match because now, it terminates the search immediately.