-
Notifications
You must be signed in to change notification settings - Fork 71
Replication Lifecycle
This is a high-level description of the states the replicator goes through.
State | Description |
---|---|
Offline | Unable to reach server |
Connecting | Opening TCP / WebSocket connection |
Busy | Connected and transferring data |
Idle | Continuous replication has nothing to do; waiting for changes |
Stopped | One-shot replication finished; or any replication has a fatal error |
DISCLAIMER: The Offline state has not been implemented yet. See issue #98.
There are quite a few causes behind the offline state:
- Device is in "airplane mode", networking switched off
- Out of range of WiFi and/or cell signal
- WiFi router is available but itself has no connectivity (DSL is down, cable modem unplugged, bad IP configuration, etc.)
- DNS can't resolve the hostname (DNS servers down, wrong DNS configuration on device or router, or host is on a private network and hostname is not public)
- Proxy server is unreachable (DHCP misconfiguration, proxy is down, proxy is up but misconfigured, etc.)
- Hostname is known, but that IP address is on an unreachable private network like an intranet
- Other network issues along the route to the server (ISP problems, a backhoe has cut a backbone fiber line, AWS went tits-up again, etc.)
- Server itself is down
- Sync Gateway is down
The replicator detects these by the errors they produce, like No such host, No route to host, Connection refused, Connection timeout, 502 Bad Gateway, 504 Gateway Timeout. These cause a transition to the Offline state.
While offline, the replicator has a limited ability to detect when conditions might have improved. Changes to causes 1 and 2 can be detected by OS-specific network change events. The others can't, because they don't involve changes in the device's network interfaces. However, a change in network can mean that the problems are resolved (user may have switched WiFi networks or logged into a VPN, for example.)
While in the Offline state the replicator will listen for network-change events, and attempt to reconnect. It also tries periodically even without an event, using an exponential-backoff schedule.