Category filter
Triple-Channel Architecture: Ensuring 100% Command Delivery in Hexnode
This documentation explains Hexnode’s proprietary Triple-Channel Communication Architecture, a redundancy-focused system designed to ensure mission-critical command delivery and real-time device synchronization across diverse network environments.
Overview: The Connectivity Challenge
In standard Unified Endpoint Management (UEM), a single notification service (e.g., Google’s FCM) acts as the bridge between the admin portal and the device. If this bridge is severed by a firewall, ISP restriction, or regional blockade (like the Great Firewall of China), the device becomes “orphaned”—unable to receive remote wipes, app updates, or security policies.
Hexnode’s Triple-Channel Architecture eliminates this single point of failure by maintaining three independent, concurrent communication pathways.
The Three Communication Channels
Hexnode utilizes a “tri-force” of protocols to wake up devices and trigger synchronization.
| Channel | Service/Protocol | Primary Role | Ideal For |
|---|---|---|---|
| Channel 1 | FCM (Firebase Cloud Messaging) | Industry-standard push service for Google-certified Android devices. | Global deployments with Google Play Services. |
| Channel 2 | MQTT (Message Queuing Telemetry Transport) | A lightweight, “always-on” binary protocol that maintains a persistent socket connection. | Regions where Google is blocked (China), AOSP devices, and rugged hardware. |
| Channel 3 | Pushy | A specialized, standalone notification gateway that uses its own infrastructure to bypass standard firewall filters. | High-security enterprise networks and fallback for FCM/MQTT failures. |
How the Architecture Works: Step-by-Step
When an administrator initiates a command (e.g., Remote Lock) from the Hexnode Portal, the following “Race to the Device” occurs:
- Simultaneous Broadcast: Hexnode sends a “nudge” or silent notification through all three channels at once.
- The Handshake: The device receives the nudge from whichever channel is fastest or currently unobstructed.
- Secure Check-in: The nudge triggers the Hexnode UEM agent on the device to establish a secure HTTPS (TCP Port 443) connection back to the Hexnode Cloud.
- Policy Execution: The device “pulls” the pending command data over the secure 443 tunnel and executes it immediately.
Technical Requirements for Admins
To ensure the Triple-Channel Architecture functions at peak efficiency, your network’s outbound firewall must allow communication on the following ports:
Network Whitelisting
- FCM: Ports 5228, 5229, and 5230 (TCP).
- MQTT: Ports 1883 (non-SSL) and 8883 (SSL).
- Hexnode Push Domains: Allow push.hexnode.com and its regional variants (e.g., push-us.hexnode.com, push-eu.hexnode.com).
- HTTPS (Mandatory): Port 443 must be open for the actual data synchronization between the device and the portal.
For Apple (iOS/macOS) devices, Hexnode integrates with APNs (Apple Push Notification service). While the underlying protocols differ, the architecture treats APNs with the same priority to ensure near-instant responsiveness.
Key Advantages
- Reliability in Restricted Zones: Successfully manage devices in China or on private networks where Google Services are unavailable.
- Battery Efficiency: MQTT is designed to maintain a connection with minimal battery drain compared to constant polling.
- Near-Zero Latency: Commands often reach devices in under 1 second by using the fastest available pathway.
