Nabto Edge Platform Overview
The Nabto Edge platform makes it possible to communicate directly between two entities: Instead of interacting indirectly with a device through a cloud service, the platform makes it simple to communicate directly with the actual device to invoke services or transfer data - also through firewalls:
This means higher performance as there is no central processing overhead and the network path is short. And better privacy as nothing needs to be stored outside the user’s own device - making GDPR compliance a breeze.
We distinguish among clients and embedded devices: The client has plenty of resource, e.g. like a smartphone or a desktop computer. The embedded device can be resource constrained like typically seen in IoT scenarios. The client initiates a connection towards the device to start an interaction.
Essentially, the device can be regarded as a server and solutions can be developed following the traditional client/server paradigm. So in addition to better performance and privacy, direct connectivity also yiels a simpler development process as the developer just needs to focus on the client and device applications - no central application to develop and operate: You just communicate on the edge.
So the Nabto Edge platform is ideal if simple, secure and high performance communication between your client and device is more important than e.g. centralized analysis of large amounts of sensor data.
The Nabto Edge Direct Protocol
How is it possible to communicate just between your devices on the edge without traffic going through central cloud services?
Discovery, UDP Hole Punching and Fallback to Relay
If both client and device are on the same local network, the problem is simple - existing discovery methods like mDNS (BonJour) or UPNP can be used by the client to locate the device. When the device is not directly discoverable by the client and there are firewalls between them, the problem is more complex, similar to when a VoIP client makes a phone call to a remote peer.
Indeed, Nabto Edge uses the exact same principles as used in VoIP communication: Using a central mediation service (just like a phone central), the two peers are provided with information about the opposite peer and can establish a direct connection. This common technique is called UDP hole punching - the resulting direct connection is called a peer-to-peer (P2P) connection.
The phone central like mediation services are denoted the “Nabto Edge Basestation”. Instead of a phone number, Nabto Edge uses a symbolic identification of devices. So where the VoIP client requests a phone connection to “phone number XYZ” through a phone central, the Nabto Edge Client requests a Nabto Edge connection to the device with id “ABC” through the Nabto Edge Basestation.
The hole punching technique works well with most combinations of firewall types. However, in some cases it is not possible to establish a direct connection and fallback to relay is necessary.
Nabto Edge Direct - all of the Above
The Nabto Edge Direct protocol transparently handles all of the above 3 scenarios:
- Local device discovery using mDNS
- Direct p2p connection
- Fallback to central relay
The application developer only needs to worry about which device to connect to, not how: That is, the developer just supplies a device id to the Nabto Edge Client SDK which takes care of discovery, hole punching and relay fallback. Under the hood, all connection types are attempted to be established at the same time.
The resulting abstract connection can be used by the application developer without needing to worry about the actual underlying type (unless specifically interested - for instance to limit relay use).
Communication between the client and the remote application is started once any type of connection is established - specifically this means that if it is faster to establish a relay connection, application communication immediately starts on relay and is then migrated to a direct connection if such turns out to be available.
The UDP hole punching attempt may take a few seconds, hence the ability to instantly start using the indirect relay connection and automatically migrate to a direct connection yields a better overall user experience.
This ability to initially communicate on relay and do transparent switchover from relay to direct is denoted QuickConnect.
Extended Rendezvous for Symmetric NAT Traversal
The traditional UDP holepunching techniques e.g. using STUN and ICE do not allow traversing symmetric NAT firewalls, any such firewall encountered would hence yield costly and low performance relay connections.
The Nabto Edge Direct protocol extends the standard technique, exploiting the fact that it is reasonably easy to guess the symmetric NAT port if using a sufficiently large number of ports at each peer (an application of the birthday paradox). In the default configuration, this makes it possible to establish direct P2P connections in 95% of connect attempts where one peer is behind a symmetric NAT firewall. In the 5% failed attempts with this firewall configuration, you can just try again for another 95% probability. Also, the ratio can be made higher by being more aggressive (and vice versa).
Applying the extended rendezvous technique greatly increases the overall P2P ratio. Currently 98% direct P2P connections are observed in EU.
Simple and Secure
The Nabto Edge Direct protocol uses standard public key cryptography to enabled secure, end-to-end encrypted communication between the two peers, this is the subject of the Security Guide. The guide also explains how token based access control (such as JWT) can be used for authentication and authorization as well as preventing Denial-of-Service attacks on devices.
Once a connection is established using the Nabto Edge Direct protocol, the vendor application can use the following communication patterns on the connection:
Turn-Key Solution for Minimal Hassle
The Nabto Edge platform provides all necessary components to establish secure, direct connectivity between your clients and devices.
The Nabto Edge Client SDK and high level wrappers make client application development simple and efficient. The lowest level SDKs implementing the actual Nabto Edge Direct protocol are delivered as pre-compiled binaries for all popular client platforms. Higher level wrappers are distributed through package repositories such as CocoaPods, typically with source code available.
The Nabto Edge Embedded SDK makes it simple to integrate remote access in embedded applications in a secure and robust way. Some popular embedded platforms are supported out of the box and the step-by-step integration guide and test harness makes it straightforward to port to a new platform.
The embedded SDK is distributed as open source (commercial license) through github to make integration on target devices simple, flexible and transparent.
No central cloud application development needs to take place - once you have registered your purchased devices with the Nabto Edge Basestation, it simply mediates connections between your client and device applications without further ado.
The Nabto Edge Basestation can either be hosted on-premises at the customer or in Nabto’s Data Centers. We maintain a global network of datacenters, making sure users are always geographical close to a datacenter.
We expand our network with new locations as necessary. All nodes are interconnected for maximum availability and performance: Each device automatically registers with the datacenter that has the lowest latency and clients are routed to the correct datacenter when requesting a device.