Skip to content

Conversation

@jnpkrn
Copy link

@jnpkrn jnpkrn commented Sep 14, 2016

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.

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.
@jnpkrn
Copy link
Author

jnpkrn commented Sep 15, 2016

Note that beside exact match is now preferred to fuzzy match all
the time (fixed behavior), there's another (side-)effect of the patch:

if there are more exact matches to be discovered in the "host-assigned
addresses X addresses in the configuration", now the first exact match
will get selected -- previously it was the first one with longest network
prefix.

So with this change, booth can select a different address, possibly
resulting in the role change. But also note the degenerate case of
a host having equal/similar addresses differing just in network prefix
assigned is inherently not supportable reliably in booth as it doesn't
allow configuring the addresses with said prefixes (intentionally or
due to ignorance?), which is why the implemented "best effort" works
most of the time.

Perhaps emitting a warning when such a potential clash is discovered
during the startup would be a good idea.

@dmuhamedagic
Copy link

On Wed, Sep 14, 2016 at 02:31:28PM -0700, Jan Pokorný wrote:

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.

OK.

Just let's not forget that booth servers are never supposed to run
in the same network, hence this commit shouldn't be marked "high."

@jnpkrn
Copy link
Author

jnpkrn commented Apr 2, 2020

Delayed closure in favour of long-merged #58, with a link to this
comment from its discussion shall the question of determinism ever
become relevant in retrospect:

#58 (comment)

@jnpkrn jnpkrn closed this Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants