Softnet Free is an IoT communication platform for devices with embedded TCP/IP stack. It implements a software-defined networking environment for direct communication between devices. Softnet makes the TCP and UDP protocols available for use in dynamic IP environments. The platform offers built-in Remote Procedure Calls as an additional IPC mechanism, as well as Pub/Sub Events used to implement event-driven interaction scenarios. The platform also supports notifications used in asynchronous communication. The Softnet mechanism of Access Control can be used to implement different levels of access to device resources, and a mechanism called Service Status Detection provides clients with information about the status of remote devices. Softnet also provides a convenient solution for managing devices, clients, user permissions, and shared access to devices with other individuals/organizations. The latter allows owners to establish user-to-user or business-to-customer relationships. Using Softnet, developers can focus on IoT application logic without concerning about networking issues.
The following features of the platform can be considered as innovative:
- Centralized management of user permissions leveraging the inherent user roles embedded in the devices;
- A packet switching technique for relaying TCP connections. This technique is much more resource-efficient compared to the connection-switching method employed by a TURN relay for TCP connections;
- Framework for seamless integration of widely used protocols like HTTP, WebSocket, SSH, RTSP, etc., within the IoT/IIoT domain, along with the corresponding software and utilization techniques. The integration of the protocols themselves is currently under development.
Softnet Free is licensed under Apache License, Version 2.0. You can use, modify and distribute both the server software and the endpoint libraries without any restrictions.
As of October 2023, the Softnet endpoint library built in Java SE 1.7 is available. It works on Linux platforms, embedded Linux, Armbian, Raspbian, Android 5.0 and later versions. The endpoint libraries for other platforms are under development. First of all, we focus on FreeRTOS, ChibiOS/RT, Contiki and other platforms widely used in industrial microcontrollers such as STM32, TI SimpleLink, Infineon XMC, ESP32, PIC32, EFR32, etc.
- Softnet Free Demo Server / This is a demo server with free registration where you can try out Softnet applications and see if the platform's functionality meets your requirements;
- The User Guide to Softnet Management System / This guide explains how to use Softnet MS for managing devices and clients utilizing the Softnet platform. It is designed for both developers and users;
- Discussions / Here, you can ask questions, view demo examples, participate in discussions, etc.;
- Resources for embedded Java application development:
- Softnet Endpoint Library (Java) / The Softnet endpoint library built on Java SE 1.7. It works on Linux platforms, Raspbian, Android 5.0 and later versions;
- Softnet Programming Model in Java / This guide explains the process of developing applications using Softnet Endpoint Library (Java);
- Softnet ASN.1 Codec (Java) / The ASN.1 codec written in Java. Softnet uses it to encode/decode messages in the ASN.1 DER format for transmission over a network. This tool can also be used to encode/decode application data for transmission over a network, although you can use any other format, such as JSON;
- The Developer Guide to Softnet ASN.1 Codec (Java) / This guide explains how to use Softnet ASN.1 Codec (Java) in the application development;
- A brief developer guide is also published on hackster.io.
- Resources for deploying Softnet servers on the Microsoft Windows platform:
- The administrator guide for deploying and managing Softnet servers is coming soon;
- Softnet Tracker / This server implements the core business logic of Softnet Free;
- Softnet Proxy / This server implements mechanisms for establishing TCP and UDP connections in peer-to-peer and proxy mode;
- Softnet Management System / Softnet MS provides users with tools for managing devices and clients utilizing the Softnet platform;
- Softnet ServerKit / This library contains classes and algorithmes used by the Softnet servers;
- Softnet ASN.1 Codec (C#) / This codec is used by the Softnet servers to encode/decode messages in the ASN.1 DER format for transmission over a network;
- Administration Tool / This tool is used to initially set up the platform database and assign/revoke the "Administrator" role to users;
- Database Generation Script / This is an SQL script for creating a Softnet database in MS SQL Server.
The Internet of Things is essentially a concept that describes a system of interconnected devices that use the Internet for communication. But, oddly enough, one of the primary challenges of IoT is precisely ensuring this Internet-based communication between devices. In this review, I’d like to present you Softnet Free, a communication platform designed for devices with an embedded TCP/IP stack. Typically, an IoT platform is developed to solve some real IoT problem. Although there are many IoT platforms in the market, the problem discussed in this review is relatively new and has emerged recently due to the proliferation of TCP/IP-enabled smart devices. Nowadays, nearly every MCU manufacturer offers a range of MCUs equipped with TCP/IP interfaces. Embedded systems built on them typically have enough capacity to implement on-device business logic, interact with the physical environment, and communicate with clients over IP networks. These MCUs are increasingly used in industrial automation as well as in the production of consumer devices. The platform’s functionality divided into two logical parts: Core Functionality and Protocol Extensions. The first part is now implemented and available for use in Java applications while the second part is under development.
In most cases, an IoT device equipped with TCP/IP support and on-device business logic is also equipped with an API through which clients can interact with the device over IP networks. However, the communication model used to interact with traditional Internet services cannot be simply transferred to the IoT domain, as this comes with significant connectivity, security, and device management challenges. Softnet Free has been designed to address these challenges. The platform implements a software-defined networking environment for direct communication between devices and provides a range of communication patterns. It makes the TCP and UDP protocols available for use in dynamic IP environments. The platform offers built-in RPC as an additional IPC mechanism, as well as Pub/Sub Events, which is typically used to implement event-driven M2M communication scenarios. The platform also supports notifications used in asynchronous communication. And a mechanism called Service Status Detection provides clients with information about the status of remote devices, allowing clients to attempt real-time communication only when the remote device is online. Devices on the Softnet network are not exposed to the Internet directly, and only clients authorized on the platform can interact with them. In terms of the functionality described above, Softnet Free might be similar to some of the other platforms on the market. However, Softnet Free stands out due to its centralized management system, which can support the device's built-in mechanism of access control. The platform employs the concept of a domain to organize all devices and their clients related to a specific IoT project. The domain contains a list of users where each user can have access to different devices in the project with different permissions. Users can also be associated with other individuals and organizations, thereby allowing for shared access to devices. The platform allows device owners to assign the device's native roles to domain users, so that clients then connect to devices with those permissions inherited from users. To better understand how this works, let’s look at the following diagram:
Site shown in the center is a key object that the device owner creates to set up a single device or multiple identical devices on the Softnet network. A domain can contain multiple sites for different types of devices. As shown in the diagram, the site contains User Membership, a component that represents users and their associated permissions on the device. This data, like everything else in the domain, is manageable through the centralized management system (Softnet MS). The main trick is that the device depicted on the right side of the diagram also has its own User Membership, which maintains a synchronized copy of the membership data. It is always aligned with the central User Membership. The embedded application uses it for local access control. Whenever the Service Endpoint receives a request, it resolves the user ID in the local User Membership and provides the application with a MUser object associated with the request. This object provides the user's name, category and roles if RBAC is employed. As shown in the diagram, requests are eventually handled by the request handlers. Developers can apply access rules to the handlers declaratively or programmatically. Thanks to this mechanism, the developers do not have to design an on-device membership system. It also eliminates the need to store user accounts on the device. Moreover, since each client authenticates to the Softnet server, the developers do not have to design an on-device authentication mechanisms as well as security policies such as password complexity, account lockout, and denial-of-services protection.
The core mechanisms of the platform are sufficient for developing a wide range of applications. Nevertheless, the described model has one drawback, which is also inherent in other similar platforms. This model requires that both embedded software for devices and client software be developed utilizing the platform’s API. As a result, developers need to master a new platform, while users require a specifically designed client application for each device type. The last requirement for device-specific client applications can be a critical factor, particularly in a competitive consumer device market. It should be noted that users are accustomed to accessing most Internet services through a few simple steps, such as entering a URL into a web browser and then authenticating. If a service demands an additional plugin installation or a dedicated application on the device, users may find it less appealing. However, if additional network settings are required, such as port forwarding or dynamic DNS, they are more likely to avoid using this service altogether. Typically, service providers offer a dedicated client application only as an additional option for frequent users to make the user experience more comfortable. These considerations are especially relevant when designing the user interface for TCP/IP-enabled devices.
Overall, in the IoT domain, there is a strong demand from both developers and users to incorporate well-established software technologies and user experience principles typically found in traditional software products. Nowadays, HTTP-based technologies form the backbone of the most prevalent IT ecosystem. Many application layer protocols are built on top of HTTP. Therefore, numerous embedded TCP/IP solutions encompass HTTP and WebSocket protocols. Some IoT developers have also a temptation to embrace modern front-end technologies such as React and Angular. Apart from HTTP and related products, other prominent technologies such as audio/video streaming (RTSP+RTP, SRT, etc.), remote device management (SSH, VNC, etc.) and others are also in demand in IoT. However, the primary challenge in adapting these traditional technologies lies in addressing issues related to remote communication with devices, as well as concerns pertaining to security, access control and device management.
According to the requirements discussed above, we can identify three categories of stakeholders whose interests should be taken into account. Users prefer employing familiar user principles and well-accustomed client software. Device owners expect the platform to provide high-quality connectivity, security and device management. Lastly, IoT developers prefer the software technologies they are most familiar with. Let's see how this ambitious task can be solved by using together the management system discussed earlier and a mechanism called Protocol Extensions. As an example, we'll look at how the HTTP extension works, starting with the following diagram:
Here, clients − such as browser-based HTTP clients − interact with the embedded HTTP server hosted on a device. However, they do so indirectly through the HTTP Extension Server. These clients communicate without using a Client Endpoint, in contrast to clients utilizing the core functionality as shown in the previous section. In this way, users interact with the device much like they would with any other Internet server utilizing HTTP. At the same time, a web application running on the embedded HTTP server utilizes the Softnet API only for local access control. This requires developers to have only a minimum knowledge of the Softnet API. As discussed in the previous section, the device’s local User Membership maintains the data synchronized with the central User Membership. If a web application employs role-based access control, the developer simply provides the list of roles to the Service Endpoint. The device owner then will be able to assign these roles to domain users. The diagram shows that through the loopback interface, requests to the embedded HTTP server come from the HTTP Extension Component. In this way, both the HTTP extension server and the HTTP extension component serve as middleware between clients and the embedded HTTP server.
Now let's look at how these two components − HTTP Extension Server and embedded HTTP Extension Component − establish an HTTP connection from the client to the embedded HTTP server. A client must first authenticate with the HTTP extension server. This step is depicted in the diagram as (1) Authentication. Then the server finds the site where both the client and device are registered. If the device is online, the server sends a directive to the HTTP extension component so that it establishes an HTTP connection with the Proxy Agent on the server. This step is referred to as (2) Creating an HTTP connection. The directive passes through the Extension Message Transmitter (ExMT) to the Extension Message Dispatcher (ExMD) contained in the Service Endpoint on the device. ExMD also serves as a registry in which every protocol extension component used by the application must be registered. In our case, we have an HTTP extension component that the directive is addressed to. ExMD passes it to this component. The directive contains the user ID, information needed to authenticate with the server and locate the proxy agent, etc. In the third step, the extension component establishes an HTTP connection with the proxy agent. This step is referred to as (3) HTTP connection establishment. Now that the connection is established, HTTP requests are passed from the server to the extension component, where the extension component acts as a reverse proxy and forwards HTTP requests to the embedded HTTP server. This is depicted as (4) in the diagram. The extension component inserts the corresponding user ID into the header of each request. The web application can then retrieve this ID and resolve it in the User Membership to get the corresponding MUser object. This object, as discussed in the previous section, is used in access control.
Along with HTTP protocol, the HTTP extension server is assumed to support HTTPS, WebSocket and Secure WebSocket. This will enable device developers to adapt front-end technologies such as React and Angular, build Web-API-based interfaces, and use many other HTTP-based protocols for Internet-scale device communications. The HTTP solution we considered is a special case of a general approach that applies to other widely used protocols. Each protocol requires its own pair of extension server + extension component, while Extension Message Transmitter and Extension Message Dispatcher (ExMD) are universal components of the platform. Developers simply need to register the extension components in ExMD for specific protocols they want to use and perform simple configurations on those components.
Earlier we identified the stakeholder interests that should be taken into account. Now we can summarize that Protocol Extensions entirely meet those requirements. Moreover, the platform allows developers to eliminate the need to develop on-device membership systems, authentication mechanisms, and security policies.
Device manufacturers often leverage cloud platforms to provide their products with networking capabilities. Typically, a cloud platform facilitates vertical connectivity for devices to perform cloud-specific operations like data storage, analytics, and AI. However, some IoT applications may also require the platform to support horizontal connectivity or direct communication between the devices themselves, bypassing the cloud server. A simple analysis reveals that device-to-device communication tasks can be organized, structured and implemented within a single unified solution. These considerations allow me to consider Softnet Free as a candidate for this unified solution. It currently offers a management tool for setting up IoT projects via a web interface. However, Softnet Free, empowered with an API for management tasks, could be deployed as a service to serve other platforms that require inter-device networking capabilities. In this way, Softnet Free could significantly reduce the cost of developing cloud platforms for specific IoT applications.
Softnet Free demonstrates considerable promise as a competitive solution in the IoT market. To fully unlock its potential, active engagement from a dedicated developer community is essential. The platform's path to excellence relies on collaborative efforts, contributions, robust support, and a commitment to delivering versatile implementations across diverse platforms. The true potential of Softnet Free can only be realized through the collective spirit of the developer community.
