Consider a “hub and spoke” type arrangement (though this should be effective for other use cases).
Propose that each Syncthing instance can be configured to provide to it’s peers it’s location. This could be a publicly available address like “tcp://myhost.mydomain.com:22000” or a list, like “tcp://myhost.mydomain.com:22000, tcp://192.168.1.85:22000”. Upon a successful connection, this instance would transmit it’s publicly available addresses to peers which can be used for subsequent connections. These would be “semi-permanent” connections in that they would be stored as connection targets for that host on the peer unless they are changed in the host machine’s configuration. Upon successful connection, the host could also transmit a list of “temporary local addresses” which may allow a peer to “upgrade” the connection from a WAN connection to a LAN connection. The peer, as it does today can attempt these “temporary” addresses and if successful can upgrade the connection. Also upon successful connection, the peer would also share it’s “temporary local addresses” as well as it’’s “publicly available addresses” if configured to be stored on the host for host initiated connections to that peer.
Propose that each Syncthing instance caches connection info for each paired device. The peer would store the “semi-permanent” connection string provided at the last successful connection. The peer could also store, for instance any recent successful “upgraded” connection (last 7 days?).
Propose that if Global discovery is disabled for a peer, that peer would be able to contact introducers which would effectively act as the discovery server and share the stored connection information with the peer. The introducer would also share this information with a peer during the first introduction.
The discovery server would still be used if connections via the above methods fail.
Pros:
- Machines can provide a preferred connection method and path, i.e. through a VPN which the discovery server may not be aware of.
- Newly started connections (unpaused, or restarted instances) can immediately attempt a connection to the stored address without having to contact the discovery server
- Some discovery server load can be reduced. It may also be possible to reduce how often machines “advertise” their locations to the discovery server.
- A peer with stored connection information trying to find a host may be able to reduce request frequency for updated connection information from the discovery server.
- If IP’s haven’t changes, repeat connections can still be made if discovery servers are down, overloaded, or otherwise unable to fulfill requests.
Cons:
- Machines need a successful connection before being able to exchange the preferred addresses. Some may wonder why new connections fail. “I put the host name in, I don’t need discovery since I provided the hostname, why didn’t they connect”? (Because you need discovery the first time or provide the hostname manually to the client.)
- If machines are off or not reachable, nothing is really saved. Machines trying to connect to peers will assume the stored addresses are stale and will contact the discovery server (if enabled) to attempt connection. This may end up being the majority of a discovery server’s load so it may not save much load.
Is it a crazy idea?