mirror of
https://github.com/openziti/ziti.git
synced 2026-09-10 08:45:41 +00:00
Paul Lorenz
ecbdb92ecb
routerConnectChurnLimit predates the per-router connect lock. It was added alongside the ability for a new control channel to take over from an established one, as the guard on how often that may happen, and it was also the only thing keeping two connections for one router out of the connected map. That second job is gone: at most one connection per router is now enforced under the per-router lock, where the decision is atomic. The check in the accept path runs against the connected map with no lock held, so it can only refuse a connection early that would be refused there anyway. Its first job remains, and is now the only thing doing it. ConnectRouter always displaces an occupant it does not recognise, so without the limit a spurious first-connection hello would tear down a healthy control channel and make the router redial. Nothing said so, and the field carried no godoc at all. - documents on the option what it protects, that it is churn policy rather than the uniqueness guarantee, and that zero always allows takeover - extracts the decision so it can be tested without standing up a network, and tests it: protected when just established, protected part way through the window, displaceable once past it, and never protected at zero The struct's field alignment shifts because a comment ends gofmt's alignment group; that part of the diff is whitespace only. Behaviour is unchanged. Worth noting for readers of the option: past the window, the established connection is now displaced and the connect refused, so the router redials into the freed slot, where previously the arriving connection took over directly. Same end state, one extra round trip, and nothing unvetted is registered on the way.