From the next version of Praim products, the ThinOX, Windows, Agile4PC, Agile4Pi and ThinOX4PC devices will communicate with ThinMan through a new communication protocol. The devices that will use this protocol will maintain an always-active connection to ThinMan, through a secure websocket channel. The new protocol will allow greater control over the status of the devices connected to the console, highlighting sudden shutdowns and connection failures.
At the same time, it will be possible to use free and validated certificates through the “Let’s Encrypt” service, or directly use certificates within the company. Through the use of these two types of certificates it will be possible to greatly increase the security in communication: the devices in this mode will be able to communicate and receive commands only with the ThinMan console equipped with validatable certificates.
With the new protocol it will no longer be necessary to allow connections on the port 443 of the device. In fact, all the commands will pass through the established websocket channel, thus simplifying the firewall settings within the network.
From the technical point of view the main changes will be:
- The communication becomes full-duplex on the same channel, allowing the passage of data even in networks under NAT. For example, to perform remote assistance on a device in a remote office, it was necessary for ThinMan to be able to reach the device through an IP address. Now, having now a bi-directional connection always active, the remote assistance will pass from the channel.
- Having an always-active connection allows you to know the status of the device in real time. This will also be able to perceive and therefore to report any sudden shutdowns or connection failures due to external reasons.
- Using only the outgoing port 443, the new protocol does not need any change on the firewall side.
We have seen how the new protocol brings technical improvements, but in practice what use cases will it allow?
- Teleworking: providing a device to a user connected to his home network will no longer be a problem. By having ThinMan reachable, maybe even in Cloud, it will be possible to manage the station as if it were in the same subnet.
- Service provider: it will become very simple to manage more than one fleet of devices through a single ThinMan console. Simply put the ThinMan server in the Cloud, and all the devices will be connected.
- Management of laptops and mobile devices: it will make it easy to manage workstations that can be moved, such as laptops.
- Debug device: often to check the status of internal services, it is necessary to create a VPN in order to access the network. Leaving a device connected to ThinMan in the Cloud, it will be possible, through the remote assistance function, to access the various corporate services directly from the Thin Client.
This table summarizes the evolution of communication protocols between the devices and ThinMan:
|TCP/UDP||HTTPS||HTTPS unlinked||HTTPS linked||WSS||WSS safe|
|Half Duplex FTP||Half Duplex||Half Duplex||Half Duplex||Full Duplex||Full Duplex|
|Not using certificates||Self-Signed Certificates||Self-Signed Certificates||Self-Signed Certificates||Self-Signed Certificates||Use of certificates validated by Let’s Encrypt or by the company CA|
|Request-Response type||Request-Response type||Request-Response type||Request-Response type||Bidirectional type with messages||Bidirectional type with messages|
|Big Overhead per request/connection||Big Overhead per request/connection||Moderate Overhead per request/connection||Moderate Overhead per request/connection||Moderate overhead to establish & mantain the connection, then minimal overhead per message||Moderate overhead to establish & mantain the connection, then minimal overhead per message|
|Used on response to ThinMan Browse||Used to communicate to Reference ThinMan||Used on response to ThinMan Browse||Used to communicate to Reference ThinMan||Used to communicate to Reference ThinMan||Used to communicate to Reference ThinMan|