mirror of
https://github.com/zerotier/ZeroTierOne.git
synced 2024-12-20 21:43:08 +00:00
9933d83cf8
Proactively seek, and distribute external surface addresses This patch introduces a new "self-awareness" behavior which proactively queries peers for external surface addresses and distributes them via PUSH_DIRECT_PATHS. This has the effect of making ZT more responsive to interface changes. Current behavior: Previously, this type of information was only mediated via RENDEZVOUS and was only triggered when the client detected that it no longer had a single alive path to a peer. While PUSH_DIRECT_PATHS would correctly (and often) send local addresses, this was not the case for external addresses collected from response HELLOs. This would lead to situations where only one physical address would be distributed to peers. Additionally, if a new physical interface were to be made available to the client, the client would correctly bind to it but never seek information about its external mapping from a peer, and thus the new physical interface would remain unavailable for other peers to learn about until all paths on the previous interface have expired which can take a couple of minutes. In traditional usage of ZT this is not usually a problem, but it becomes a problem in the following scenarios: Network interfaces go up and down while ZT is running (e.g. switching to LTE or WiFi from a wired connection) Network interfaces are added or removed in multipath setups Proposed behavior: I propose that normal full HELLOs are sent not only on the first interface in use, but all interfaces. This causes planets to respond with a HELLO containing the surface address for each interface. We then collect each address using SelfAwareness::whoami() and distribute them via the normal PUSH_DIRECT_PATHS mechanism. |
||
---|---|---|
.. | ||
Address.hpp | ||
AES_aesni.cpp | ||
AES_armcrypto.cpp | ||
AES.cpp | ||
AES.hpp | ||
AtomicCounter.hpp | ||
Bond.cpp | ||
Bond.hpp | ||
Buffer.hpp | ||
C25519.cpp | ||
C25519.hpp | ||
Capability.cpp | ||
Capability.hpp | ||
CertificateOfMembership.cpp | ||
CertificateOfMembership.hpp | ||
CertificateOfOwnership.cpp | ||
CertificateOfOwnership.hpp | ||
Constants.hpp | ||
Credential.hpp | ||
Dictionary.hpp | ||
DNS.hpp | ||
Hashtable.hpp | ||
Identity.cpp | ||
Identity.hpp | ||
IncomingPacket.cpp | ||
IncomingPacket.hpp | ||
InetAddress.cpp | ||
InetAddress.hpp | ||
MAC.hpp | ||
Membership.cpp | ||
Membership.hpp | ||
Multicaster.cpp | ||
Multicaster.hpp | ||
MulticastGroup.hpp | ||
Mutex.hpp | ||
Network.cpp | ||
Network.hpp | ||
NetworkConfig.cpp | ||
NetworkConfig.hpp | ||
NetworkController.hpp | ||
Node.cpp | ||
Node.hpp | ||
OutboundMulticast.cpp | ||
OutboundMulticast.hpp | ||
Packet.cpp | ||
Packet.hpp | ||
Path.cpp | ||
Path.hpp | ||
Peer.cpp | ||
Peer.hpp | ||
Poly1305.cpp | ||
Poly1305.hpp | ||
README.md | ||
Revocation.cpp | ||
Revocation.hpp | ||
RingBuffer.hpp | ||
RuntimeEnvironment.hpp | ||
Salsa20.cpp | ||
Salsa20.hpp | ||
SelfAwareness.cpp | ||
SelfAwareness.hpp | ||
SHA512.cpp | ||
SHA512.hpp | ||
SharedPtr.hpp | ||
Switch.cpp | ||
Switch.hpp | ||
Tag.cpp | ||
Tag.hpp | ||
Topology.cpp | ||
Topology.hpp | ||
Trace.cpp | ||
Trace.hpp | ||
Utils.cpp | ||
Utils.hpp | ||
World.hpp |
ZeroTier Network Hypervisor Core
This directory contains the real ZeroTier: a completely OS-independent global virtual Ethernet switch engine. This is where the magic happens.
Give it wire packets and it gives you Ethernet packets, and vice versa. The core contains absolutely no actual I/O, port configuration, or other OS-specific code (except Utils::getSecureRandom()). It provides a simple C API via /include/ZeroTierOne.h. It's designed to be small and maximally portable for future use on small embedded and special purpose systems.
Code in here follows these guidelines:
- Keep it minimal, especially in terms of code footprint and memory use.
- There should be no OS-dependent code here unless absolutely necessary (e.g. getSecureRandom).
- If it's not part of the core virtual Ethernet switch it does not belong here.
- No C++11 or C++14 since older and embedded compilers don't support it yet and this should be maximally portable.
- Minimize the use of complex C++ features since at some point we might end up "minus-minus'ing" this code if doing so proves necessary to port to tiny embedded systems.