How the Connector Shutdown Process Works
Why do you need to know about how Connectors shut down?
When a Connector shuts down (either intentionally, such as when it is upgraded, or unintentionally), that event impacts any Clients connected to it. It is important, for availability planning purposes, to understand the process by which a Client will attempt to maintain connectivity by trying additional Connectors and Relays.
What you should know
- Each Connector maintains connections to 4 Relays
- Each Connector tells the Controller which Relays it is connected to via a regular heartbeat
- Upon connecting to Twingate, the Controller sends each Client an ordered list of Connector-Relay pairs to try
- The Client connects to the first Relay and Connector for the requested Resource
How the list of Connector-Relay pairs is established
The list is randomly generated but is seeded by a unique device ID and iterates over all Connectors to ensure minimum downtime. (The list always stays consistent for a given device but may differ between devices.)
How it works on the backend
Let’s assume a typical setup with a Remote Network containing 2 Connectors (A and B). When Connector A goes down, the following happens:
- The connections between Connector A and any Twingate Client connected to it are terminated
- The Twingate Client tries to re-establish a connection to the first Connector-Relay pair in the list communicated by the Controller
- The Relay waits for Connector A to establish a connection to it (this takes approximately 20 seconds)
- Since Connector A is down, the Relay responds to the Client that it could not establish a connection to the first Connector-Relay pair
- The Twingate Client then moves on to the second Connector-Relay pair in its list (i.e., Connector B, since the order communicated by the Controller iterates over Connectors when establishing the list)
- The Twingate Client successfully connects to Connector B
Last updated 10 months ago