Category filter
Beyond Polling: Scaling to 200,000 Connections with Hexnode’s MQTT Engine
Why MQTT Matters in the Hexnode Ecosystem
In the world of Unified Endpoint Management (UEM), “management” is only as good as its speed. When an IT admin clicks “Wipe” on a stolen laptop, minutes translate to data breaches. When a policy changes, compliance must be instant.
MQTT (Message Queuing Telemetry Transport) is the lightweight messaging protocol that powers this immediacy. While traditional protocols are heavy and slow, MQTT acts as a persistent, low-bandwidth “heartbeat” between the Hexnode Cloud and your device fleet.
For Hexnode customers, MQTT is the difference between hoping a command reaches a device and knowing it has been executed instantly.
1. The Strategic “Why”: Beyond Standard Connectivity
Most MDM solutions rely heavily on platform-specific push services (like Apple’s APNs, Google’s FCM, or Windows’ WNS). While Hexnode leverages these, we go further by implementing a robust, proprietary MQTT layer.
A. The “200,000 Concurrent Connections” Benchmark
Reliability at scale is the hardest challenge in UEM. Hexnode has engineered its architecture to handle load balancing of over 200,000 concurrent MQTT connections.
What this means for the Enterprise:
- Zero Bottlenecks: Whether you are managing 50 devices or 50,000, the “pipe” remains unclogged.
- Stability: This load-balancing capability ensures that during peak times (e.g., 9:00 AM login storms or mass-patch deployments), the server does not buckle. Every device stays connected, listening for commands.
- Future-Proofing: As your fleet grows, our MQTT infrastructure scales horizontally to meet the demand without requiring you to re-architect your network.
B. The “Always-On” Connection
HTTP is a “ask and receive” model—the device has to “call home” to check for work. MQTT is a “pub/sub” model—the device creates a permanent, ultra-lightweight tunnel to the server.
- Low Bandwidth: Perfect for employees on roaming data or spotty Wi-Fi (e.g., field workers, logistics).
- Battery Efficient: Unlike constant HTTP polling which drains battery, MQTT sits idly in the background, consuming negligible power until a command is sent.
2. Real-World Use Cases: MQTT in Action
Scenario 1: The “Lost Device” Emergency (Security)
- The Context: An executive leaves a laptop containing sensitive IP in a taxi.
- Without MQTT: The admin sends a “Corporate Wipe” command. The system relies solely on WNS/APNs. If those services are congested or the device is behind a strict firewall that blocks them, the command hangs.
- With Hexnode MQTT: The device maintains an active MQTT subscription via push.hexnode.com. The “Wipe” command bypasses external congestion and travels down this dedicated tunnel. The device receives the packet instantly and initiates the wipe. Crisis averted.
Scenario 2: The Kiosk Update (Operations)
- The Context: A retail chain needs to update the pricing app on 5,000 Android tablets across the country before stores open.
- The Hexnode Edge: Using ports 1883/8883, Hexnode broadcasts the notification to update configurations. Because of the 200,000 concurrent connection capacity, all 5,000 devices receive the “wake up” signal simultaneously without crashing the command queue.
3. Technical Architecture & Network Strategy
To leverage this strategic advantage, network administrators must ensure the “nervous system” has a clear path. Hexnode’s MQTT implementation is designed to be firewall-friendly, favoring outbound connections.
The Connectivity Matrix
Hexnode uses MQTT primarily for Windows, macOS, and Android devices to facilitate push notifications when platform-specific services (FCM/APNs) are unavailable or to augment them for speed.
| Component | Port | Description |
|---|---|---|
| Standard MQTT | 1883 (TCP) | The standard messaging channel. Used for general command delivery. |
| Secure MQTT | 1883 (TCP) | The encrypted channel (TLS). Ensures commands cannot be intercepted or spoofed. |
| Regional Scale | N/A | Traffic is routed to regional hubs (e.g., push-eu.hexnode.com, push-us.hexnode.com) to reduce latency and ensure data sovereignty. |
Firewall Considerations
Unlike complex bidirectional setups, MQTT requires the device to initiate the outbound connection. Once established, data flows two-way.
- Requirement: Allow outbound traffic on ports 1883 and 8883.
- Destinations: push.hexnode.com and regional variants (e.g., push-ldn.hexnode.com).
Strategic Note for CISOs:
Utilizing port 8883 ensures that this persistent connection is encrypted. Hexnode’s ability to load balance these secured connections means you do not sacrifice security for speed—you get both.
5. Conclusion
MQTT is not just a technical specification in the Hexnode documentation; it is a strategic asset. By maintaining a highly scalable, low-latency bridge to your devices—capable of balancing 200,000 concurrent streams—Hexnode ensures that your control over the digital workspace is absolute, immediate, and reliable.
In an era where “work from anywhere” is the norm, MQTT is the invisible thread that keeps the enterprise connected.
