# 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.

ChannelService/ProtocolPrimary RoleIdeal 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:

1. **Simultaneous Broadcast**: Hexnode sends a “nudge” or silent notification through **all three channels** at once.
2. **The Handshake**: The device receives the nudge from whichever channel is fastest or currently unobstructed.
3. **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.
4. **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.

 Note: 
For **Apple (iOS/macOS)** devices, Hexnode integrates with **[APNs (Apple Push Notification service)](https://www.hexnode.com/mobile-device-management/help/apns-settings/)**. 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.