IoT Request Forwarding Server Application

This desktop software application is designed to act as a proxy/relay to forward requests from end-user IoT edge devices to their main production server when direct access to the server becomes unavailable due to routing issues, network blocks, or other external factors. The application is capable of seamlessly forwarding both raw telemetry requests from embedded hardware devices and API requests from associated client applications (such as Android or iOS apps).

Hardware products developed under the Internet of Things (IoT) architecture have become widely adopted. A critical link in this architecture is the connection between the user’s local gateway device and the remote Cloud server; without this link, the entire system ceases to function. While ready-made software solutions like VPNs exist for browsers and mobile phones, embedded microcontroller hardware often lacks the resources to run such protocols.

Connection lost between IoT device and Server KVV EL
Connection lost between IoT device and Server

One highly effective solution is the deployment of a custom proxy/relay server application. This software acts as a transparent middleman: it receives incoming requests from the IoT edge devices (acting as the local IoT server), forwards the payload to the actual remote IoT server, awaits the server’s response, and finally relays that response back to the IoT device.

Operating Principle

The software is written in C++ utilizing the WinAPI and Windows Sockets API (WSA / WinSock). It operates as a server-side application running on a PC that maintains connectivity with both the IoT device and the remote server. To standardize IoT device firmware, it is highly recommended to route data using DNS hostnames rather than hardcoded IP addresses. The IoT gateway firmware implements a priority-based routing fallback: its primary goal is to send requests directly to the main IoT server. If that connection fails, it falls back to a secondary DNS address where this “Forwarding Server” application is hosted.

When an IoT device initiates a request to the PC running the Forwarding Server, a TCP Socket connection is established. The application accepts the request and immediately initiates a secondary outbound connection to the actual IoT server. Upon success, the received payload is forwarded. Since this is bidirectional communication, the IoT server generates a response, which the Forwarding Server receives. The remote connection may then be closed by either the server or the Forwarding application. The Forwarding Server then passes this response back down to the IoT edge device, after which the local socket connection is gracefully closed by either the device or the application.

IoT Device to IoT Server communication via a PC running the Forwarding Server KVV EL
IoT Device to IoT Server communication via a PC running the “Forwarding Server” application

The application architecture is fully multithreaded. Every new incoming connection from an IoT device spawns a dedicated thread that executes the proxying procedure described above and is automatically destroyed upon completion. The software allows forwarding requests from both IoT edge devices and mobile applications on Android/iOS. Additionally, it can be extended to support full browser request forwarding (HTTP proxying). The software architecture also supports the implementation of custom traffic filters and blocking rules for various security, debugging, or logging purposes.

Leave a Reply