The Concept of Softnet Free

[Robert-Koifman]

The Concept of Softnet Free

Softnet Free is an IoT communication platform for devices with embedded TCP/IP stack. It implements a software-defined networking environment that enables direct communication between devices. Softnet makes the TCP and UDP protocols available for use in dynamic IP environments. The platform offers Remote Procedure Calls and Pub/Sup Events as additional remote IPC mechanisms. The latter is used in event-driven interaction scenarios. The Softnet mechanism of Access Control can be used to implement different levels of access to devices, and a mechanism called Service Status Detection provides clients with information about the connectivity 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.

Softnet Free is licensed under Apache License, Version 2.0. You can use, modify and distribute the server software and the endpoint libraries without any restrictions.

The challenges of TCP/IP connectivity in IoT

Softnet Free was developed to address the communication challenges that emerged with the evolution of basic IoT components – embedded systems and network technologies. Today, IoT is more about consumer products, while its derivative IIoT is about industrial automation. But the challenges we are going to discuss are inherent in both concepts.

Let's analyze the typical structure of any IIoT system represented in the form of five technological levels.

The first two levels – device hardware and device software consist of IIoT gateways and microcontrollers that interact with the physical world using sensors and actuators. The data about states of physical objects travels from the sensors through the communications level to the cloud platform that processes, analyses and stores the data. The cloud platform, in turn, issues commands to the actuators that change states of the physical objects. Finally, the cloud applications level provides end users with a way to interact with the IIoT system. According to this model, electronic devices that form the first two levels do not implement their own business logic. They only collect data on the states of physical objects and execute commands from the cloud platform to change the object states. All the business logic of the system is implemented in the cloud and manages equipment, often assembled in close proximity.

At the same time, the rapid progress in microelectronics has led to the fact that today embedded systems, built even on inexpensive microcontrollers, can be powerful enough to implement on-device business logic and operate autonomously, interact with the physical environment, and communicate with clients over IP networks. Thanks to this, consumer electronics such as air and ground unmanned vehicles, smart home systems, surveillance systems, etc., have gained popularity. TCP/IP-enabled embedded systems have been increasingly used in industrial automation. In this article, we won't touch on the functionality of networked embedded systems, but will focus on the challenges associated with remote communication with such devices over the Internet.

Typically, the network embedded system implements some interface that clients use to communicate with the device. From this point of view, it may even seem that the model of communication with embedded systems is similar to that used for communication with stationary Internet services. But that is where the similarity ends. Regarding connectivity, in most cases, for clients to communicate with an Internet service, it's enough for both the clients and the service to be connected to the Internet. Other functional requirements, such as security and access control, are mostly implemented by the service itself. However, IoT applications that involve communication with embedded systems in a dynamic IP environment require completely different communication model. This is what Softnet Free is designed for.

Let's take a look at the challenges that developers face when designing networking capabilities for embedded systems.

Addressing of devices. Perhaps, this is the first problem that developers have to solve. In order for clients to be able to make requests to a device, the latter must have a permanent address. However, when the device moves from one network to another, it is often assigned a dynamic IP address. Also, the device may be situated behind a NAT or in a different IP stack. As a consequence, clients either do not know the device’s current address or the device becomes unreachable even when its address is known. In some cases, the problem can be solved by leveraging the concept of "Home Address/Care-of Address", using dynamic DNS and/or port forwarding. However, it should be noted that assigning a permanent public address to a device has a serious security drawback. The problem is that often embedded systems have weak protection against network attacks, and being directly exposed to the Internet, such devices create a security breach.

Security. This is one of the major problems in IoT. There are a dozen types of attacks in the Internet. Hosting providers use firewalls, intrusion detection systems, traffic filters and other tools to protect online services. However, such protection methods are hardly applicable to networked embedded systems. A qualitatively new approach is required to solve this problem.

Device status detection. The remote device may lose the connectivity from time to time. Clients waiting to communicate with the device require to be notified when the device goes online or offline. Clients should also be able to check the online status of a remote device before making a request to it. This function is highly important in M2M applications.

Eventing mechanism. The majority of Internet applications are designed in such a way that any interaction between endpoints occurs as a result of human action. It could be a click on a user interface button, a click on a URL-link or something else. In the IoT world, however, applications often interact without human intervention. Such applications use event-based interaction model. IoT applications need a reliable mechanism to deliver events raised on the remote devices to the clients.

TCP and UDP connections. Almost any application-level protocol uses TCP or UDP as a transport protocol. In order to communicate, embedded systems should have an ability to establish transport-level connections. However, if the target device is situated behind a firewall or NAT, it becomes unreachable for clients. To solve this problem, developers use special techniques to create peer-to-peer or relay connections. As these techniques are quite complicated, it is desirable that all stuff is done transparently for user applications. There is also an IPv4/IPv6 inter-stack communication issue.

Devices administration. As a rule, an electronic device with networking capabilities supports an interface for device administration. This can involve configuring the device parameters, as well as managing user accounts and their permissions. If you have just a few of such devices, you can manage them with no efforts. However, device administration becomes complicated if you have a large number of devices. Let's say you have dozens of IP cameras connected to the network. Since each camera has its own user account registry, you will most likely need to create at least one or two accounts on each device to set up the cameras. If, for example, the user accounts on each device have the same name and password, and if you need to make a change to the account on one device, then you will have to duplicate this change on the rest of devices. And, if you use different names and passwords, you will have to keep the list of accounts in your diary. This example shows that a conventional approach to administration is hardly applicable in IoT. The solution could be a centralized management system, capable to manage entire IoT projects, each consisting of many devices, as well as capable to maintain a single registry of user accounts for all devices in the project.

Shared access to devices. As in the previous section, suppose you have dozens of IP cameras connected to the Internet, and you want to grant access to the devices to some person or organization. This task overlaps with the administration task, discussed above. Following to a traditional approach, you will have to create an appropriate user account on each device and provide your partner with the authentication data. As a result, you and your partner will have to manage dozens of user accounts. This problem is similar to one described in the previous section. Hence, it is desirable that a centralized management system be able to apply device sharing operations to an entire group of devices in just a few clicks.

Typically, device manufacturers use cloud platforms to ensure the networking capabilities of their products, including those described above. The popular protocols used to implement inter-device messaging are MQTT, NATS and ZeroMQ. And WebRTC is often used if applications involve real-time media streaming or peer-to-peer communication between devices. In addition, such platforms can have a cloud storage, apply analytics to the data, and use artificial intelligence to take decisions. It is obvious that the development of an IoT platform is a complex and expensive task even when the devices to be networked are relatively simple. This can be a major barrier for start-ups, small-scale manufacturers and Do-It-Yourself developers. As for DIY, you can verify this by simply doing a google search for the keywords Top Raspberry Pi Projects. You will find a large number of Raspberry Pi projects, but very few of them that involve remote communications over the Internet. Things are even worse with industrial microcontrollers such as STM32, PIC32, etc. While suitable platforms may already exist for some popular IoT applications, such as platforms for controlling drones over 4G networks, new ideas in IoT are being born all the time. So the problems with remote communication are still relevant.

The good news is that the communication tasks described above can be organized, structured, and put into practice by creating a single, unified platform. This platform would be used on its own, as well as integrated into application-specific cloud platforms or run as a service with a unified API to serve other platforms that require networking capabilities for embedded systems. These considerations form the basis of the Softnet Free concept.

Softnet Free as a unified solution

Softnet Free is a platform that implements the communication tasks partially described in the previous section. We'll first explore the key abstractions used by the platform and then take a closer look at the platform's functionality.

Service and Client are the key abstractions that refer to the software representation of a networked device that serve clients and a client that interacts with devices, respectively. Each service implements an interface that clients use to interact with it. In Softnet, an interface is denoted by a name consisting of the service type name and the name of the author who developed the interface contract. This combination is represented as follows: <Service Type> (<Contract Author>), for example: Smart Home (John Doe). When a device connects to a Softnet network, it declares the name of the interface it supports. Each client, in turn, connecting to a Softnet network also declares the name of the interface with which it is capable to communicate. Unlike a typical database-driven Internet service, an embedded system connected to a Softnet network provides access to the resources of an electromechanical device. Usually these resources are quite limited, hence the Softnet service has a rather limited set of clients. It is not desirable that the service be exposed to a public network so that clients not approved by the administrator could not even attempt to connect to the service.

To implement the described ideas, Softnet introduced the concept of Site, which is an object that carries out communication between the endpoints. The device owner creates a site to set up one device or multiple identical devices. The devices are represented on the site as services. The device consumers, in turn, set up clients on sites that host the services they want to consume, according to their permissions of course. All services and clients on a site must support the same interface denoted by a given <Service Type> (<Contract Author>). The site runs on the Softnet server and ensures interaction of connected endpoints. The site synchronizes states of the endpoints, communicates commands between them, receives events from the services and delivers them to the clients, transmits RPC requests and responses, assists in establishing TCP and UDP connections, controls the authority of users and associated clients, manages the endpoint accounts, etc. There are two categories of sites: single-service and multi-service. A single-service site can host exactly one service, while a multi-service site can host multiple services of the same type, i.e., devices that implement the same interface contract.

What’s about users and permissions? Earlier we discussed the problem of managing a large number of devices when each of them has its own user account registry. We came to the conclusion that it is desirable to have a single user registry for all devices in a project. To implement this idea, Softnet introduced the concept of Domain. In Softnet, you create a separate domain for each IoT project. The domain contains a list of sites and a list of users. A Softnet site implements a structure that contains permissions for domain users to access the services on the site. This structure called User Membership is managed by the administrator through the site management panel. A softnet service can leverage one of the following two access control schemes – Role-Base Access Control (RBAC) or Plain Access Control (PAC). In case of PAC, users have access to the service just by the fact of being added to the site on which the service is installed. It is also true for a multi-service site. However, the RBAC scheme is more flexible. Use it if you want to have various levels of access to the service. If the Softnet service uses RBAC, it provides the site with a list of roles, which Softnet makes available for the administrator to assign to domain users. We're all talking about user access rights, but it’s not users that interact with services, but clients. Then how are clients related to users? In Softnet, the concept of User differs from a classical one. A domain user does not have an account. It is just an entity to which the administrator assigns access rights to various services in a domain. By doing this with all users in the domain, the administrator creates a user authority scheme for the entire project. As a result, each site contains the list of domain users authorized on this site. And each client on the site is associated with one of these users, from which the client derives the access rights. One user can have many associated clients. On the site management panel, you can add or delete clients as well as change their parameters. If you need to change a client device or you simply lost it, you can just delete the client and create a new one. Thus, we have a single user list for all devices in the project, and manipulations with clients are separated from managing their permissions. This makes the administration tasks convenient. However, the real power of this approach reveals when a domain user is associated with your partner. It is about shared access to devices.

The term social network is usually associated with Facebook or other similar networks where users can share articles, videos and other resources. But electromechanical devices with embedded systems can also be thought of as resources that owners may have a need to share with partners. Softnet implements the concept of Contact, which allows you to establish partnerships with individuals and organizations registered on the same Softnet server as you. In a domain, you have a category of users called contact-users that are associated with your contacts. When you create a new user, you simply specify which contact it is associated with. Then you assign it the necessary permissions on sites. That’s all. Your partners can see what services you share with them and with what permissions. They themselves can create and manage client entities on the sites. And, of course, your contacts can also share services with you.

At first glance, the Softnet features described above seem to be designed for device consumers. But what advantages does Softnet offer to developers? Usually, embedded system developers are good at GPIO programming, but don't really like to go deep into solving complex TCP/IP networking problems. In addition, there are often severe limitations in development tools and resources of the underlying platform. The further discussion is all about developing on the Softnet platform.

You already know that each site implements the User Membership structure that contains permissions for domain users to access the services. When a service application hosted on the physical device connects to the site, Softnet loads the User Membership into the application and keeps it synchronized with the site. Any change to the User Membership made on the site is immediately propagated to the application’s copy. Thanks to this mechanism, the developers do not have to design their own membership system. It also eliminates the need to store user accounts on the device. Whenever the application receives a request from one of the clients, Softnet provides the app with a membership user object associated with the client. This object contains the permissions of the user. Moreover, since each client authenticates to the site, the service application doesn't have to authenticate them itself. Consequently, the developers do not have to design their own authentication mechanism as well as security policies such as password complexity, account lockout, and denial-of-services protection.

We've covered what developers don’t have to do having Softnet, and now we're moving on to what developers have with Softnet. The platform provides four communication patterns – TCP and UDP protocols in dynamic IP environments, remote procedure calls, and application events. Let's figure out for which tasks each is best suited.

As it is known, TCP and UDP are the most adopted transport protocols. But in IoT there is a problem with this. We discussed earlier that establishing TCP and UDP connections in a dynamic IP environment is a challenging task. However, in Softnet, your client simply requests the platform to establish the connection. Softnet does the job behind the scene and returns the connected socket to the client. In fact, the range of possible applications of TCP and UDP is huge. The most obvious ones are real-time or streaming data transfer, file transfer, or as a transport for application layer protocols.

Some IoT tasks are quite simple and can be solved using a request-response pattern. In such cases, you can leverage Softnet RPC instead of messing around with other application layer protocols.

Interaction with a remote device is often triggered by an event on that device. This is the so-called event-driven interaction. A popular eventing model in IoT is Pub/Sub. For example, it is employed in MQTT. Pub/Sub implements loose coupling between publishers and subscribers. That is, subscribers have no idea who the publishers are. Softnet also implements the Pub/Sub model. Services publish events on the site, and clients subscribe to the events. But unlike the traditional model, clients know which service raised each received event. Use the Softnet eventing pattern to react to the state changes on the remote devices.

Now it's time to move on to the platform’s functionality.

Softnet Addressing Scheme. Any Softnet service can be identified on the Internet by a combination of the Softnet server address and an integer ID assigned to the Softnet service. However, this doesn’t mean that a client can simply specify a domain name, such as <serviceId>.<serverAddress>, and make a request to the service. Instead, Softnet employs the concept of a software defined network (SDN). Communication occurs in two stages. At the first stage, each service or client connects to the site, authenticates, and establishes a control channel. The site binds them to the SDN governed by this site. At the second stage, clients communicate with services within the SDN using the service IDs as addresses. It turns out that clients use a combination of the Softnet server address and the service ID to address the service on the Internet, but they do this in two stages. In conclusion, it’s worth noting that TCP and UDP connections that the Softnet site assists to establish go outside the SDN.

Softnet provides services and clients with URIs to connect to the site. Each endpoint has its own URI. Let’s take a look at their formats. The service URI format is the following:

      softnet-srv://<serviceUuid>@<serverAddress>

Note that we're talking about the URIs that services use to connect to the site, not the ones used to access the services. The URI scheme, 'softnet-srv', denotes the protocol used by services to communicate with the site. The second component of the URI format, <serviceUuid>, represents the service UUID which Softnet assigns each service along with the service ID. It is used as the account name when the service authenticates to the site. However, within the SDN, clients refer to the service by the service ID. The last component of the service URI format, <serverAddress>, is the address of the Softnet server.

Next, we have 4 client URI schemes and, with that in mind, 4 client URI formats that differ only in the schemes:

• softnet-s://<clientKey>@<serverAddress>
• softnet-m://<clientKey>@<serverAddress>
• softnet-ss://<clientKey>@<serverAddress>
• softnet-ms://<clientKey>@<serverAddress>

Here, <clientKey> is a client key used as the account name to authenticate to the site. And we have 4 URI schemes to consider:

• 'softnet-s' denotes a single-service client. It can communicate with a single remote service;
• 'softnet-m' denotes a multi-service client. It can communicate with multiple remote services of the same type and registered on a single site;
• 'softnet-ss' denotes a single-service stateless client. It can communicate with a single service and as a stateless client unable to receive private events fired on the service;
• 'softnet-ms' denotes a multi-service stateless client. It can communicate with multiple services of the same type, and it also unable to receive private events.

So, we have 4 categories of clients that use slightly different protocols to communicate with the site.

TCP & UDP in dynamic IP environments. Softnet prefers to establish a connection in P2P mode, and if this is not possible, then in proxy mode. Services listen for TCP/UDP connection requests on virtual ports. Bindings to fixed physical ports aren't used. This approach ensures reliable protection against Brute-Force and DDoS attacks on the services. To transfer data through TCP connections in proxy mode, the platform uses IP packet switching technique instead of the connection switching one used by TURN. This approach significantly reduces the requirements for the processing power of proxy servers. Softnet also supports IPv4/IPv6 inter-stack connections for both TCP and UDP protocols, i.e., when one endpoint is located in IPv4 network and the other one in IPv6 network.

Remote Procedure Calls. Softnet has a built-in RPC mechanism. The procedure parameters and return value have an ASN.1 format, which makes it possible to pass complex hierarchical data to and from the procedure. For this purpose, Softnet offers developers a convenient tool for working with the ASN.1 format. As for error handling, there is always a chance that an RPC request to the service can result in an error. Softnet has a built-in mechanism that allows the service to return structured information about that error.

Pub/Sub Events. Eventing is a basic mechanism of machine-to-machine interaction that occur without human intervention. Almost any IoT application uses eventing to some extent. Softnet supports the pub/sub eventing model. Here, publishers are services, and subscribers are clients, respectively. Each event that the service will be raising must be defined in the service's Site Structure object. Softnet uses this information to configure the event broker hosted on the site. For each event, the developer must specify such parameters as the name, lifetime, maximum queue size, and access rule. All Softnet events are divided into 3 categories.

• Replacing Events. These events are convenient for representing changes in state parameters of an electromechanical device over time. For example, such parameters can be the readings of temperature, humidity, pressure, etc. The service can raise a replacing event whenever the corresponding parameter reaches a certain value or changes by a certain delta. Each time an event is raised, the previous instance is replaced with a new one. Those clients that haven’t yet received the previous instance of the event will no longer be able to receive it, but only the last one.
• Queuing Events. Unlike replacing events, an event of this category does not replace the previous instance, but rather joins a queue of previously created instances. Queuing events are used when clients need all event instances in chronological order.
• Private Events. At times, a service may not be able to immediately respond to a client request and may take an indefinite period of time to do so. Given that the client request cannot last longer than a short timeout interval, there is a need for a mechanism that would allow the service to notify the client that the result is ready or that the interaction can continue. For this purpose, the category of private events has been introduced in Softnet. Unlike the previous categories, only the client for which it is generated can receive the private event.

Access Control. This is perhaps the weakest side of the most existing communication platforms. Meanwhile, a handy mechanism of access control is one of the most required features in the IoT realm. Softnet offers developers two types of access control – Plain Access Control (PAC) and Role-Based Access Control (RBAC). If you choose PAC, it does not involve any additions to the service’s source code. Any client registered on the site will have a full access to your service if the associated domain user is added to the site. If you choose RBAC, the list of roles must be defined in the service’s Site Structure object. Then the roles from that list can be specified in the definitions of access rules to RPC procedures, events, and listeners on TCP and UDP virtual ports. Distribution of the roles among domain users is carried out centrally through the management panel. When a client request comes in, the platform immediately finds the corresponding membership user object. This object contains the name and roles of the user. If the client does not have enough access rights, it receives an access error.

IoT Project Management. Softnet provides Softnet Management System (Softnet MS) to perform management tasks. It was earlier discussed that an IoT project is deployed in a domain. The domain contains a list of users, and each site implements the User Membership structure with access rights to the services. There are two built-in domain users: Owner and Guest. Also, Softnet supports two categories of users: Private users and Contact users. Owner is associated with the project’s owner. Usually, you assign it administrative permissions to the services so that clients derived from Owner have full access to devices to perform administrative tasks. However, client devices in the field should not have administrative permissions for security reasons. The right solution is to create private users with restricted permissions. Some devices may support guest access. For this purpose, you have a built-in user called Guest. And the last category is contact users. They represent your partners in device sharing. Softnet offers a handy way to establish partnership with other persons and organizations registered on the same Softnet server with you. You can send and accept contact invitations, manage the contact list, create domain users associated with the contacts, and assign them access rights.