Evento conjunto de OCS y "DACOM M" (Space), dedicado a la funcionalidad del protocolo GLINT. Descubrirá cómo GLINT asegura la transmisión de datos y transforma la experiencia de trabajo con ellos, haciéndola más dinámica y enriquecedora, lo cual es especialmente importante para la ejecución de procesos de trabajo de alta carga.
Temas tratados en el evento:
- Ventajas y características del protocolo GLINT.
- Cómo está estructurado GLINT y para qué perfiles de uso es adecuado.
- Medición del ancho de banda de GLINT.
- Cómo interactúa GLINT con la periferia: USB y cámaras web.
- Presentación de los planes de desarrollo de GLINT para 2024.
- Hoja de ruta del proyecto, incluyendo el uso de tarjetas inteligentes para el acceso y el ajuste del protocolo al ancho de banda del canal.
- Además, discutiremos los protocolos propietarios y su soporte por diferentes sistemas operativos, así como los protocolos de código abierto y sus características.
El evento de hoy lo dirige Ruslán Belov, director de producto de Space VDI. Comentó que los protocolos de acceso son un tema interesante y complejo. Y comenzó hablando sobre el protocolo GLINT, sobre los problemas de los protocolos y para qué se necesita un protocolo así. Mencionó brevemente la historia mundial de los protocolos.
Es decir, lo primero son las ventajas y características del protocolo, cómo podemos configurar y adaptar GLINT a una solución concreta, sobre su ancho de banda. Veremos cómo se comporta el protocolo al cambiar el ancho de banda del canal. Veremos qué opciones hay para interactuar con la periferia de conexión de dispositivos. Y lo más importante, son los planes de desarrollo de nuestro protocolo, hacia dónde nos dirigimos, qué funcionalidades adicionales aparecerán.
En cuanto a los propios protocolos, hemos identificado y señalado los siguientes requisitos para el propio protocolo de acceso: asegurar la consistencia al decodificar el vídeo, es decir, que la imagen no se deteriore y que el usuario pueda trabajar cómodamente en condiciones VDI, en diferentes perfiles. Es necesario tener en cuenta este punto, es decir, nuestro algoritmo de pulsación y las opciones, respectivamente, de visualización de la propia imagen en el lado del cliente, es decir, que todo esté en tiempo real con la mínima latencia. Para ello, también es necesario adaptar el protocolo a la arbitraje de flujos en canales virtuales y otras opciones de transmisión de diferentes señales, es decir, no sólo la propia imagen que proviene de la captura de fotogramas de la sesión remota, sino también el control de entrada y salida de dispositivos, es decir, como USB, cámaras, teclado, ratón y otros.
Capacidad de respuesta en tiempo real, es decir, asegurar el equilibrio del tráfico, la determinación de retrasos, la captura de fotogramas clave para poder seguir construyendo esta imagen. Y el último punto es la recuperación y la predicción. Es decir, en caso de que tengamos alguna caída en la red, o si hay otros problemas con la carga en el rendimiento de los propios dispositivos, que el propio protocolo pueda entender qué fotogramas necesita mostrar, cuáles omitir. Y, respectivamente, lo último es la predicción, pero aquí ya hay opciones para nuevas tecnologías, es decir, sistemas neuronales, como el cloud gaming o algo parecido, que en algunos casos los procesadores que tienen núcleos para redes neuronales pueden predecir fotogramas concretos, aumentando así el número de fotogramas, es decir, FPS, y permite proporcionar suavidad a la propia imagen, así como calidad de visualización.
Y la pregunta principal es, ¿para qué se necesita algún protocolo, para qué inventar algo, cuando ya existe en el mercado el protocolo RDP, todo el mundo lo usa, satisface las necesidades del mercado y está muy bien optimizado por la propia empresa Microsoft? Este es precisamente uno de los primeros problemas de este protocolo, es precisamente el protocolo propietario de la empresa Microsoft, pero aquí mismo tiene una ventaja, que establece estándares, tiene derecho a ello, es uno de los primeros que apareció en el mundo del acceso remoto, por lo que puede establecer las reglas de cómo podemos construir nuestro protocolo. Por supuesto, cada protocolo tiene sus propias características. Y en cuanto a la desventaja de RDB, está organizado precisamente para el ecosistema de Microsoft. Si utilizamos servidores terminales, RDS y demás, entonces RDP es la mejor solución en este sentido, porque de forma nativa permiten proporcionar acceso remoto a dichas soluciones.
Pero si ya pasamos al mercado actual, a la situación actual del sistema operativo en nuestro país, es decir, ya son sistemas operativos basados en núcleos Linux, es decir, Astra Linux, RedOS, entonces la solución RDP dificulta el desarrollo y la adaptación a estos sistemas operativos.
Por lo tanto, aparecen varias soluciones, como Open RDP, SPICE, VNC, que proporcionan una base de paquetes abierta, y podemos utilizar estos desarrollos y adaptarlos a nuestro ecosistema. De estos protocolos, que quería señalar en el entorno VDI, son respectivamente el protocolo RDP, el protocolo BLAST y ECA, es decir, el protocolo Citrix. Aquí no se muestra en la diapositiva, pero también es muy popular y se utiliza con frecuencia. Las ventajas de estos protocolos se indican aquí, es decir, un gran soporte tanto de la periferia como de las opciones de cifrado. BLAST tiene su propia tecnología propietaria con equilibrio, pero tanto RDP, está diseñado precisamente para su propia infraestructura, es decir, para Windows, y BLAST está diseñado precisamente para funcionar correctamente en el entorno VMware. Todo esto no permite tomarlo y aplicarlo a VDI en nuestras soluciones.
Y por lo tanto, lo primero que se utilizó fue el protocolo SPICE, VNC, como FreeRDP y xRDP. Pueden permitir proporcionar acceso remoto, pero tienen grandes desventajas. En algunos paquetes, no hay soporte de sonidos, no hay, por ejemplo, paso de algunos dispositivos y además se adaptan mal a los canales deficientes, lo cual es la principal característica para la solución VDI. Es decir, cuando construimos una red, calculamos los recursos para cada usuario, debemos entender claramente que necesitamos el máximo ancho de banda, para, respectivamente, distribuirlo entre los usuarios y estar seguros de que, por ejemplo, en modo de sesión cargada, cuando tenemos cientos de usuarios y en ese mismo momento están conectados a alguna ВКС, es decir, hay transmisión de vídeo, audio, dispositivos periféricos involucrados, que nuestro canal aguanta y cumplimos con los parámetros necesarios.
En cuanto al protocolo GLINT, tiene la configuración más amplia para el perfil de uso. Es decir, si entramos en la configuración del propio protocolo Glint, podemos ver un gran número de parámetros que podemos ajustar a determinados escenarios. En un futuro próximo, planeamos lanzar una versión simplificada de esta configuración, es decir, como en algunas aplicaciones hay una opción de baja calidad, calidad media, alta calidad, o adaptación al ancho de banda del canal. Nosotros planeamos implementar una opción así, para que a los administradores que configuran ya en los clientes esta configuración, sea más fácil entender cómo configurar para un escenario de uso concreto. Y además de esto, también una de las principales posibilidades es el acceso centralizado a la configuración del protocolo desde el propio administrador. En esto también hay una ventaja precisamente del protocolo propietario, porque es nuestro, podemos adaptarlo a los sistemas VDI, podemos gestionar la configuración no directamente desde la parte del cliente. Lo principal, respectivamente, es el acceso a la cuenta de dominio, es decir, sin esto no se puede. Y si tomamos soluciones basadas en Open Source, entonces en algunos casos no existe esta posibilidad. O hay que añadir, o conectar algunas bibliotecas adicionales.
Limitación del ancho de banda asignado, es decir, es lo que podemos indicar para un ancho de banda concreto y por encima de él los usuarios no ocuparán el canal. Disponibilidad en modos de entorno de software protegido Astra Linux, aquí se entiende que para las soluciones Space dispatcher y Space client… (Space dispatcher es un broker que gestiona las conexiones de los usuarios, se basa en el sistema operativo Astra Linux, bajo el cual construimos nuestro VDI). Se admiten otros sistemas operativos. Desde la parte del cliente, es un amplio espectro de estos sistemas operativos. En la parte del servidor, ofrecemos la posibilidad precisamente de dos SO: RedOS y Astrа Linux. Aquí por ahora estos dos sistemas operativos porque ahora son los más demandados en el mercado nacional. Y con Astra Linux realizamos una evaluación de la compatibilidad en modo de programa protegido.
Selección del protocolo de seguridad, gestión de la calidad de la discretización del sonido. Y también esto es lo principal, es la flexibilidad en la adaptación a soluciones concretas. La segunda cualidad principal de un protocolo propietario es que podemos cambiar la base de código. De este modo, el cliente ya puede influir en el desarrollo del protocolo y proponer algunas soluciones que sean necesarias para su infraestructura. Y lo último es la transmisión de la señal de control desde los dispositivos del usuario al servidor para cualquier programa y aplicación que consuma muchos recursos. Aquí la cualidad importante del protocolo GLINT es que, incluso si hay una capacidad de ancho de banda muy baja del canal, continuará su interacción con la sesión remota, no se interrumpirá y nos suministrará señales a la parte del cliente. Incluso se nos suministrarán fotogramas en 4 píxeles, no veremos nada, pero la estabilidad del propio protocolo continuará, es decir, se realizará la autoconexión. Y cuando se restablezca nuestra red, respectivamente, el protocolo ocupará el ancho de banda que necesite y continuará su interacción. Esta es otra ventaja sobre las soluciones de código abierto.
Nuestro protocolo utiliza paquetes freeRDP. Decidimos dedicarnos a esto ya al principio del establecimiento de nuestro protocolo. Tomamos este protocolo precisamente por el hecho de que se adapta muy bien a Linux y es muy fácil de personalizar. Del propio freeRDP queda poco, es decir, hemos reescrito tanto la parte del cliente como la del servidor, pero cuando aparecen algunas soluciones nuevas de freeRDP, intentamos verlas, reescribir el código precisamente para nuestras soluciones.
Por lo tanto, aquí no encontrará el propio GLINT en ningún repositorio externo, está allí con nosotros, y en esto también está su ventaja, donde nadie podrá hacer con él algunas variantes que violen la seguridad. Posibilidades de trabajo cómodo VDI, pero esto como ya he dicho, que la solución de outsourcing freeRDP no permite trabajar cómodamente en VDI, porque ocupa todo el ancho de banda del canal, con bajas capacidades de ancho de banda del canal empieza a desmoronarse e incluso desconectarse. En algún momento puede que no tengamos una sesión GLINT, y al mismo tiempo todo se mantendrá. Aquí todo está genial, y esto se debe a que hemos dividido el protocolo en módulos que permiten optimizar este protocolo en una parte concreta. Es decir, bitrate, framerate, sonido y varias opciones de trabajo con otros canales virtuales. Es decir, tanto el portapapeles, como la conexión de dispositivos, y las demás opciones.
En cuanto a las mediciones. Aquí se puede ver el gráfico de medición del protocolo GLINT (ver diapositiva anterior). Se realizó al medir la velocidad del flujo en 30 megabits por segundo. Aquí podemos ver que GLINT muestra el valor medio en cada escenario. Es decir, aquí tenemos un escenario: trabajo con modelado 3D, trabajo con visualización de YouTube a pantalla completa, en una mitad de la pantalla, navegación web, presentación, trabajo con tablas y trabajo en un editor de texto. El propio protocolo, si se mira en cuanto a RDP, intenta ocupar el máximo ancho de banda del canal, por lo que vemos aquí que se topa con 30 megabits por segundo en el caso de valores medios, y en valores máximos puede ocupar un ancho de banda mayor. Incluso si se limita, en la primera conexión tomará la cantidad necesaria de fotogramas y distribuirá la carga más adelante. Bluetooth, respectivamente tiene un menor ancho de banda del canal, en este caso no lo ocupa todo e intenta mantener los valores medios, es decir, aproximadamente como el protocolo BLAST, si se mira este gráfico.
Pasemos ahora a la periferia. Las posibilidades de GLINT en la periferia son amplias, tanto la conexión a teclado y ratón con cable, como el trabajo con dispositivos USB, como unidades flash o el paso de directorios.
El trabajo con SmartCAD y tokens en este momento se implementa precisamente para los tokens ruToken. En la versión actual se está ampliando esta posibilidad y de esto ya hablamos en nuestra hoja de ruta. Trabajo con auriculares USB y reproducción de sonido, trabajo con auriculares, respectivamente, auriculares de 3,5 mm. Trabajo con cámara USB con compresiones, trabajo con cámaras integradas y trabajo con dos monitores para la solución, cuando es necesario, respectivamente, transmitir la imagen a dos monitores.
Ahora en la página principal
