search

syncthing / syncthing

Open Source Continuous File Synchronization
https://syncthing.net/
Mozilla Public License 2.0
65.55k stars 4.31k forks source link

Remember previously used / discovered device addresses and retry them #3474

Open calmh opened 8 years ago

calmh commented 8 years ago

In addition to global and local discovery, try any addresses we've recently seen a given device use.

AudriusButkevicius commented 8 years ago

Also, after ClusterConfig, we can send KnownAddresses message for any peers that were part of ClusterConfig of the remote peer, which I guess sends also "last N addresses" even if not connected.

calmh commented 8 years ago

Yep, exactly what I was coming here to write, as that came out of the other discussion I just didn't get it until now.

That KnownAddresses message could also be spontaneously generated along the way, that is when I connect to device A I also send a KnownAddresses update to devices B and C to let them know about the address I managed to find for A.

AudriusButkevicius commented 8 years ago

Yep, the question is weather we send only currently known alive addresses or even the old addresses? Also, this could be done fairly easily with the discovery mux, yet the functionality bleeds from model back to discovery which is strange

masgo commented 8 years ago

Sounds good. This means if I happen to know/contact any device from a group, it will inform me about all other in the group.

Ferroin commented 8 years ago

The other thing to think about is if we want inform peers of our alternative addresses. For example, if A and B are talking over IPv4 directly, should they inform each other of any IPv6 or relay addresses they have too? This would increase the bandwidth requirements, but would probably make it even less likely that talking to the discovery server is necessary to establish a connection.

masgo commented 8 years ago

Devices should exchange all their information. This could be alternative IPv6 addresses, as well as additional IPv4 addresses.

The bandwidth overhead is negligible. If one node has a 10 IPv6 addresses it would add 10 * ( 128 bit Address + 16 bit for the port + 1 bit flag for TCP/UDP)) = 1450 bit = 182 byte 182 byte will almost certainly fit in a single packet.

If this device sends all the information about all other devices in the group and if every device has -again- 10 addresses, we have: 256 bit device ID + 1450 bit contact info = 1706 bit = 214 byte per device of the group Ethernet uses a MSS of 1500 byte, DSL lines usually limit MSS to 1492 byte. If we subtract the IPv4 header (max 60 byte) or IPv6 header (variable length, lets assume 80 byte) we can still fit the information for 6 nodes in ONE packet.

Even if you add padding, inefficient encoding, information about the last time an IP was seen, the last RTT, or if you make the groups bigger - you will still end with only a few packets which need to be sent, way less than 1 KB.

Ferroin commented 8 years ago

That's kind of my thought too, it's not very expensive, and it reduces the need for global discovery even further. If implemented such that this info is only gathered when a new device connects or an existing one changes address, there should be almost no overhead compared to the rest of the protocol.