The Piper Open Source Project
Piper is a peer-to-peer 'darknet' for the machines that you control. It establishes direct communication links between your machines over the internet, and through plugins provides feature such as remote backup / reboot / etc.
- Plugin loading
- Node API
- NAT Test Harness
- Console interface to node API
- Connection establishment
Core functionality involves a library for simple and effective NAT/firewall traversal. Protocols such as UPnP
and NAT-PMP (both of which allow automated forwarding of ports from a NAT device) will be implemented, which is likely to work on a home network. Platform specific functionality may include opening ports on the Windows firewall. If for neither host a port can be opened or forwarded, mediated [hole punching] (UDP, possibly TCP) will be used, and as a result an impl. of the STUN
protocol is also needed. This means that regardless of network setup, a connection is likely to eventually succeed. This functionality is certainly a bit tricky and sensitive - there is definite benefit for other projects in having it kept separate. Piper needs solid work in this area, as the goal is to have two machines behind different corporate firewalls and laptops roaming on wifi just as accessible to their owners as if they were on a personally controlled network.
A major goal is to be able to remove need for additional infrastructure and any single point of failure. As such, Piper will use OpenDHT
to integrate its concept of a 'network' with the previously mentioned NAT traversal library.
Other solutions such as Hamachi depends on a central server for login and connection establishment. Everyone using Hamachi maintains a _persistent_ connection, as they must be notified when another host comes online (this central server may then need to provide STUN-like functionality for connection establishment). Hamachi provides great speeds through direct connections but not fault tolerance.
is a public distributed hash table. For now, we depend on OpenDHT
(via RPC) for storing/retrieving key/value pairs, but that may change if Piper hosts can eventually actively participate in a DHT (like BitTorrent
clients). Each Piper network has a unique name/encryption key, so hosts can advertise their open ports (which may result from UPnP
or NAT-PMP for example) in a secure manner. When a host comes online, it simply checks the DHT for host/port combos to try. In the event that no existing hosts have open ports (all behind a restrictive firewall), the new host advertises its _desire_ to join - the existing hosts will poll for updates, and by this can agree to perform hole-punching at a determined point in the future. This degenerate case can take up to the polling interval for connection to succeed, but it _works_. As far as we know, this approach has never before been used. Full details available in establishment procedure
Most user-level functionality will be provided via Plugins
, and the control interface will be a very simple layer on top of these plugins. Realize that with direct connections plugins can be very simple but useful just the same - a PortBouncer
for instance, or remote reboot. A small set of functionality for reliable messaging between darknet members allows a surprising set of user-level features and easy extensibility by others."
Useful pages: FormattingRules