GLINT — проприетарный протокол подключения пользователя к удаленному рабочему столу

A joint event by OCS and «DACOM M» (Space) dedicated to the functionality of the GLINT protocol. You will learn how GLINT ensures data transmission and transforms the experience of working with it, making it more dynamic and rich, which is especially important for performing high-workload processes.

Topics covered at the event:

• Advantages and features of the GLINT protocol.
• How GLINT is structured and which usage profiles it is suitable for.
• Measuring GLINT bandwidth.
• How GLINT interacts with peripherals: USB and webcams.
• An overview of GLINT's development plans for 2024.
• Project roadmap, including the use of smart cards for access and adjusting the protocol to the channel width.
• In addition, we will discuss proprietary protocols and their support by various operating systems, as well as open-source protocols and their features.

Today's event is led by Ruslan Belov, Product Director at Space VDI. He mentioned that access protocols are an interesting and complex topic. He started by discussing the GLINT protocol, the problems with protocols, and why such a protocol is needed. He briefly touched on the global history of protocols.

The first point is the advantages and features of the protocol, how we can configure and adapt GLINT for a specific solution, and its bandwidth. We will see how the protocol behaves when the channel width changes. We will look at the options for interacting with peripheral connection devices. And most importantly, the development plans for our protocol, where we are heading, and what additional features will appear.

Regarding the protocols themselves, we have identified and outlined the following requirements for the access protocol: ensuring consistency when decoding video, so that the image does not break up, and the user can work comfortably in VDI environments, in various profiles. This point needs to be taken into account, i.e., our compression algorithm and options for displaying the image on the client side, so that everything is in real-time mode with minimal delay. For this, the protocol also needs to be adapted for arbitration of streams in virtual channels and other options for transmitting various signals, i.e., not only the image itself that comes from capturing frames of a remote session, but also input-output device management, such as USB, cameras, keyboard, mouse, and others.

Real-time responsiveness, which is precisely ensuring traffic balancing, determining delays, capturing key frames so that this image can be built further. And the last point is recovery and prediction. That is, if we had some drawdown in the network, or there were some other problems with the load on the performance of the devices themselves, so that the protocol itself could understand which frames it needs to show, which to skip. And, accordingly, the last is prediction, but here are options for new technologies, that is, neural systems, like cloud gaming or the like, that in some cases processors with cores for neural networks can predict specific frames, thereby increasing the number of frames, that is, FPS, and allows you to provide smoothness of the image itself, well, and the quality of the display.

And the most important question is, why do we need some kind of protocol, why invent something when there is already an RDP protocol on the market, everyone uses it, it meets the needs of the market and is very well optimized by Microsoft itself. This is just one of the first problems of this protocol, it is precisely the proprietary protocol of Microsoft, but here it has a plus that it sets standards, it has the right to do so, it is one of the first that appeared in the world of remote access, thereby it can set the rules for how we can build our protocol. Of course, each protocol has its own characteristics. And regarding the disadvantage of RDB, it is specifically organized for the Microsoft ecosystem. If we use terminal servers, RDS, and so on, then RDP is the best solution in this regard, because they natively allow remote access to these solutions.

But if we move to the current market, the current position of the operating system in our country, that is, these are already operating systems based on Linux kernels, that is, Astra Linux, RedOS, then the RDP solution makes it difficult to further develop and adapt to these operating systems.

Thus, we have various solutions, such as Open RDP, SPICE, VNC, which provide an open package base, and we can use these developments and adapt them to our ecosystem. Of the protocols that I wanted to highlight in the VDI environment, these are, respectively, the RDP protocol, the BLAST protocol, and ECA, that is, the Citrix protocol. It is not shown on the slide here, but it is also very popular and often used. The advantages of these protocols are indicated here, that is, great support for both peripherals and encryption options. BLAST has its own proprietary technology with balancing, but both RDP and it are designed specifically for their infrastructure, that is, for Windows, and BLAST is designed specifically for correct operation in the VMware environment. All this does not allow it to be taken and applied to VDI in our solutions.

And therefore, the first thing that was used was the SPICE protocol, VNC, such as FreeRDP and xRDP. They can allow remote access, but they have major drawbacks. In some packages, there is no sound support, there is no, for example, forwarding of some devices, and besides, they adapt poorly to bad channels, which is the main feature for the VDI solution. That is, when we build a network, calculate resources for each user, we must clearly understand that we need the maximum channel width in order to, accordingly, distribute it among users and be sure that, for example, in a loaded session mode, when we have hundreds of users and at the same time they are connected to some kind of VCS, that is, there is both video and audio transmission, peripheral devices are involved, that our channel can withstand and we fall under the necessary parameters.

As for the GLINT protocol, it has the widest settings for the usage profile. That is, if we go into the settings of the Glint protocol itself, we can see a large number of parameters that we can adjust for certain scenarios. In the near future, we plan to release a simplified version of these settings, that is, as in some applications, there is a choice of low quality, medium quality, high quality, or adaptation to the channel width. We plan to implement such an option so that administrators who configure these settings on clients can more easily understand how to configure for a specific use case. And in addition to this, one of the main features is centralized access to protocol settings from the dispatcher itself. This is also a plus of the proprietary protocol, because it is ours, we can adapt it to VDI systems, we can manage the settings not directly from the client side. The main thing, accordingly, is logging into a domain account, that is, without this, there is no way. And if we take solutions based on Open Source, then in some cases this feature is not available. Either you need to add something, or attach some additional libraries.

Limiting the specified bandwidth, that is, this is what we can specify for a specific channel width and users will not occupy the channel above it. Availability in the protected software environment modes of Astra Linux, here it means that we for Space dispatcher and Space client solutions… (Space dispatcher is a broker that manages user connections, is based on the Astra Linux operating system, under which we build our VDI). Other operating systems are supported. From the client side, this is a wide range of these operating systems. On the server side, we provide the possibility of exactly two OS - RedOS and Astra Linux. Here, so far, these two operating systems are because they are now the most in demand on the domestic market. And with Astra Linux, we are conducting a compatibility assessment in the protected program environment mode.

Selection of a security protocol, management of sound sampling quality. And also this is the main thing, this is flexibility in adapting to specific solutions. The second main quality of the proprietary protocol is that we can change the code base. Thus, the customer can already influence the development of the protocol and offer some solutions that are necessary for its infrastructure. And the last thing is the transmission of a control signal from user devices to the server for any resource-intensive programs and applications. Here, the important quality of the GLINT protocol is that even if there is a very low channel bandwidth, it will continue its interaction with the remote session, will not be interrupted and will supply us with signals to the client side. We will even have frames supplied in 4 pixels, we will not see anything, but the stability of the protocol itself will continue, that is, self-connection will be carried out. And when our network is restored, accordingly, the protocol will take the channel width that it needs and will continue its interaction. This is another advantage over open source solutions.

Our protocol uses freeRDP packages. We decided to do this at the beginning of the establishment of our protocol. We took this protocol precisely from the grounds that it is very well suited for Linux and it is very easy to customize. Little remains of freeRDP itself, that is, we rewrote both the client and server parts, but when some new solutions from freeRDP appear, we try to look at them, rewrite the code specifically for our solutions.

Therefore, you will not find GLINT itself anywhere on external repositories, it is located there with us, and this is also its advantage, where no one can somehow make its versions from it that will violate security. The possibility of comfortable VDI operation, but this is as I said, that the outsourcing solution freeRDP does not allow comfortable operation in VDI, because it occupies the entire channel width, with low channel bandwidths it begins to fall apart and even disconnect. At some point, we may not have a GLINT session, but we will still support everything. Here we have everything wonderful, and this is due to the fact that we have divided the protocol into modules that allow us to optimize this protocol in a specific part. That is, this is bitrate, framerate, sound and various options for working with other virtual channels. That is, this is both the clipboard, and the connection of devices, and other options.

Regarding measurements. Here you can look at the graph of the GLINT protocol measurement (see slide above). It was carried out when measuring the stream speed at 30 megabits per second. Here we can see that GLINT shows the average value for each scenario. That is, here we have a scenario - this is working with 3D modeling, working with watching YouTube in full screen, in one-half of the screen, web surfing, presentation, working with tables and working in a text editor. The protocol itself, if you look at RDP, it tries to occupy the maximum channel width, so we see here that it rests on 30 megabits per second in the case of average values, and in peak values it can occupy a larger channel width. Even if you limit it, it will take the required number of frames when first connecting and will distribute the load further. Bluetooth, respectively, has a smaller channel bandwidth, in this case it does not occupy it all and tries to keep the average values, that is, approximately like the BLAST protocol, if you look at this graph.

Let's move on to peripherals now. GLINT's capabilities in peripherals are extensive, including connection to a wired keyboard and mouse, working with USB devices such as flash drives or directory forwarding.

The operation of SmartCAD and tokens is currently implemented specifically for ruToken tokens. In the current release, this feature is being expanded and we are already talking about this in our roadmap. Operation of USB headsets and sound playback, operation of headphones, respectively, 3.5 mm headset. Operation of a USB camera with compression, operation of built-in cameras and operation with two monitors for a solution when it is necessary, respectively, to transmit the picture to two monitors.