Tecnología de Terminales

David Santo Orcero

Universidad de Málaga, España

Resumen

En este artículo analizamos diversas tecnologías de terminales, centrándonos en NX y en sus características.


1. Introducción

El concepto de terminal no es nuevo: en informática, llevan empleándose los terminales como tecnología viable en entornos de producción desde la década de los 70.

Dentro de las tecnologías de terminales que han sido más populares incluimos los 3270; los “terminales inteligentes” tradicionales de los mainframes de IBM. También tenemos los “terminales tontos”, compatibles VT-100, tradicionales de servidores Unix.

Entre las tecnologías de terminal nacidas en la década de los 80 y que aún se emplean masivamente, contamos con los terminales gráficos X.

Han surgido distintas formas de acelerar los terminales X, manteniendo compatibilidad con todas las aplicaciones X. Las tres formas existentes son LBX, DXPC y NX.

Finalmente, actualmente está de moda hablar de escritorios virtuales. La idea es romper con la compatibilidad hacia atrás, y reescribir desde cero todas las aplicaciones -procesadores de texto, hojas de cálculo, programas de presentación, visores de imágenes, programas de contabilidad, navegadores...- para que operen en un escritorio virtual. Dentro de esta línea, tenemos los escritorios virtuales AJAX, y líneas de pensamiento como la del escritorio virtual Java.

2. La tecnología de terminales X

X-Window se diseñó, desde sus inicios, como un sistema que permitiera aplicaciones de terminal gráfica remota incluso en redes que hoy se considerarían muy lentas. Además, uno de sus puntos fuertes ha sido tradicionalmente su filosofía, basada en el principio: “mecanismo, no política”. Según este principio, X es concebido como una capa de abstracción del vídeo; que nos da un mecanismo para poder dibujar gráficos en cualquier lugar de la red, con cualquier hardware de vídeo. X no nos da una política de uso. De la política ya se encargan los gestores de ventanas.

Este elemento es clave para entender porqué X no ha envejecido en 20 años: los avances en la interacción entre usuario y máquina en interfaces gráficos han sido a nivel de política de uso: un escritorio tipo KDE y Gnome no se parece prácticamente en nada a los primeros escritorios de Unix. Sin embargo, el mecanismo de acceso al vídeo ha sido siempre el mismo: dibujar puntos, líneas, y cadenas de texto. No ha cambiado en los últimos 20 años.

X, sin embargo, tiene una serie de lacras derivadas de las limitaciones tecnológicas de la época que se diseñó. En la época en la que se diseñó X, las máquinas eran muy poco potentes. Y por “poco potentes” no nos referimos a que tengan la potencia de un Pentium; sino que tenían una potencia uno o dos órdenes de magnitud a los primeros procesadores en los que se podían ejecutar los Linux: los i80386. La cantidad de memoria disponible también era escasa: 1 o 2 Megabytes de memoria RAM ya se consideraba una cantidad de memoria inmensa en esta época, así que la mayor parte de las terminales X de la época disponían de muy poca memoria para los estándares incluso del mundo de los primeros Pcs con Linux. Todo esto significa que cualquier técnica de optimización de las comunicaciones que se empleara, tenía que minimizar el uso de la memoria y del procesador.

Al mismo tiempo, las redes WAN de principio de los ochenta eran poco fiables -en el mejor de los casos-; y su rendimiento las hacía apenas válida para correo y, con limitaciones, el envío de archivos de tamaños razonables. Esto dio un lugar a los diseñadores de X para recortar: en redes locales, las latencias son siempre bajas. En redes WAN, las latencias son muy altas; pero, como ese escenario no existía en la época. Esto permitió optimizar el protocolo para minimizar las necesidades de memoria y cómputo que tenía, a costa de hacer X por diseño muy dependiente de la latencia.

Los años han pasado, y X se ha mantenido vigente porque es muy potente, y está bien pensado. Y no ha sufrido modificaciones importantes en su arquitectura desde su nacimiento. Rinde mejor que otros protocolos de terminales más modernos de otros sistemas operativos.

En enlaces de latencia alta -superior a la décima de segundo-, como puedan ser los de redes metropolitanas o los WAN, este protocolo no sea adecuado en su estado bruto.

Con la popularización de los enlaces de alta latencia para interconexiones WAN, surge la necesidad de establecer sesiones de terminal a través de estos enlaces. Y aquí comenzaron los intentos de optimización de X para hacerlo apropiado para este tipo de enlaces.

En los intentos de optimización de X, hay dos factores que condicionan -para bien y para mal- todos los trabajos realizados: el primero, la ingente cantidad de aplicaciones preexistentes que funcionan bajo X hacen que cambiar el protocolo, a priori, no parezca sensato -especialmente porque funciona bien-. La segunda razón es que, al ser un protocolo de comunicaciones, lo más fácil es implementar el mecanismo de optimización como un proxy de protocolo X.

X es un protocolo de comunicaciones, y que por lo tanto se puede redirigir a través de un proxy. Podemos interpretar el proxy como una tubería -ojo, esto es un símil, no hay relación con los pipes de Unix-. Un extremo de la tubería está en la máquina que ejerce de servidor de procesos -ejecuta, por lo tanto, los procesos-. El otro extremo de la tubería está en el servidor de X, es decir, la máquina que dibuja los gráficos.

En principio, el protocolo X establece comunicaciones directas entre máquinas; pero si lo transmitimos a través de un proxy así descrito, podemos hacer nuevas operaciones soportadas por X: podemos cifrar la transmisión de X -empleando un túnel ssh-, podemos comprimir la transmisión, o incluso cachear mensajes.

Y aquí entran distintos proyectos que nacieron para optimizar el rendimiento de las conexiones remotas. De ellos, los más conocidos fueron LBX y DXPC. Estos dos proxies funcionan bien, pero los dos tienen un problema muy grave que ha supuesto el límite a su implantación real: si bien sí mejoran el rendimiento considerablemente en redes de poco ancho de banda y alta latencia, la mejora no es lo suficientemente alta en ninguno de ellos como para hacer útil el enlace. Dicho de otra forma: empleando LBX o DXPC, la conexión irá mejor que sin emplearlos; pero seguirá sin ir lo suficientemente bien como para poder conectarse a través de un modem o un ADSL a un servidor remoto. LBX y DXPC tienen otro problema: no optimizan la latencia lo suficiente como para ser útiles; y, como veremos, la latencia termina siendo el problema mayor de las terminales X.

3. El LBX

LBX -Low Bandwidth X- es una de las alternativas tradicionales para mejorar el rendimiento de X en enlaces de bajo ancho de banda y alta latencia. Está basado en el trabajo previo de Network Computing Devices -sistema Xremote- y Tektronix -con su Serial Xpress-. Ambos protocolos se desarrollaron antes de la implantación de protocolos como SLIP o PPP, y su idea pasaba por encapsular X para enviarlos dentro de enlaces RS-232 de una forma lo suficientemente rápida y eficiente como para hacerlo usable.

La idea de LBX, por lo tanto, es tomar las lecciones aprendidas con Xremote y Serial Xpress, y desarrollar un mecanismo para transmitir X por líneas de alta latencia. Esto supone cachear las comunicaciones más frecuentes, tales como la referencia a los píxeles, las propiedades de las ventanas, las fuentes, los mapas de teclado, y el arranque de la conexión. También es capaz de comprimir los mensajes entre el servidor de procesos y el servidor X. Finalmente, introdujo un concepto muy importante: las imágenes no se envían en formato de bitmap sino en formato comprimido, sin pérdidas.

LBX realiza toda esta mecánica empleando un proxy, denominado lbxproxy, para que la comunicación comprimida y cifrada sea transparente entre el servidor X y los procesos.

LBX lleva un tiempo en el mercado, y su implementación es popular: en 1996, de hecho, se incorporó a X11R6.3. Sin embargo, el incremento de rendimiento de LBX no ha sido tan grande como para permitir hacer utilizables los enlaces lentos, y las redes LAN ya eran lo suficientemente rápidas como para ejecutar X sin aceleración. El hecho de que, a pesar de que X sea asíncrono, las aplicaciones sobre X usen de forma masiva puntos de sincronía -algo que no se nota cuando trabajas en local, pero sí cuando el servidor es remoto- hacía inútiles muchas de las optimizaciones del protocolo LBX. Por ello, LBX está en vía muerta desde hace diez años.

4. DXPC

DXPC -Differential X Protocol Compression- es otro de los grandes perdedores dentro de la optimización del rendimiento de X.

También tiene más de diez años, tal y como LBX; y tampoco ha sido un éxito. Este, de hecho, ni se ha incorporado nunca a X11R6.

DXPC optimiza mediante la compresión de los mensajes del protocolo X. No todos los mensajes son comprimidos de la misma forma: algunos ocupan 10 veces menos tamaño, mientras que otros no se comprimen en absoluto. Entre las técnicas de compresión de DXPC, destacamos que elimina los campos innecesarios para un mensaje, que reduce los campos que tienen pocos valores diferentes posibles, referencia los pixels por coordenadas diferenciales, en lugar de coordenadas absolutas -recordemos que los pixels se suelen dibujar de forma consecutiva, o, al menos, cercana-; emplea una caché de comandos en ambos extremos del proxy, y, finalmente, comprime tanto textos como imágenes mediante el algoritmo LZO 2.0.

La idea es buena, y DXPC realmente reduce el ancho de banda necesario, de forma significativa. Pero tiene un problema importante: el uso de DXPC no mejora la respuesta ante latencia excesivamente alta. Y, casualmente, el problema en muchos enlaces es principalmente de latencia, no de ancho de banda. De hecho, muchas conexiones empresariales remotas de hoy en día tienen un ancho de banda similar al que existía en el mercado para redes locales cuando X nació; por lo que en algunos escenarios incluso el ancho de banda ya no es problema. Sí lo es, en todos los casos, la latencia. Esta es la que al final de cuentas más siente el humano y más le puede sacar de quicio al emplear la máquina: el redibujo no es lento, pero la máquina tarda en responder a las órdenes, hasta las que no producen redibujos, en un tiempo inaceptable.

5. El protocolo NX

Antes de que surgiera NX, parecía que estábamos en vía muerta, y que no había nada con una calidad suficiente como para permitir las deseadas conexiones remotas a través de X con enlaces de alta latencia. De hecho, Keith Packard, core developer de X desde los años 80, miembro del MIT X Consortium, de Xfree86, uno de los líderes del fork X.Org, y autor de LBX, se encargó de terminar de enterrar la idea; en su artículo “An LBX Postmortem”, afirmaba que no era posible la aceleración porque las aplicaciones se desarrollaban con semántica síncrona, a pesar de ser asíncrono el servidor; así como que se obtenían mayores mejoras de rendimiento rehaciendo aplicaciones de forma correcta que mediante el esquema seguido por LBX y proxies X equivalentes.

Entonces se paró en seco la optimización de X en accesos remotos; la gran latencia no parecía un problema resoluble para aplicaciones gráficas interactivas.

Durante los siguientes años, la gente se centró en una guerra de escritorios. No se volvió a hablar de acelerar sesiones remotas bajo X.

El 23 de Marzo del 2003, Gian Filippo Pinzari hizo un cosspost a varias listas de distribución de correo afirmando que había resuelto el problema. El protocolo que había desarrollado permitía encapsular tanto RDP -Microsoft Windows- como VNC, aunque el rendimiento estrella realmente lo tenía con X-Window. El protocolo era NX.

NX sigue la filosofía de los proyectos anteriores, es decir, es un proxy del protocolo X. Sin embargo, el rendimiento de NX es impresionante; simplemente funciona incluso con enlaces de modem. La razón de que funciona es que NX no solamente optimiza el ancho de banda transferido -y lo optimiza mucho-, sino también optimiza la latencia, obteniendo reducciones de latencia de dos órdenes de magnitud.

El protocolo NX ya nació con una implementación libre de referencia, bajo licencia GPL. La compañía de Gian Filippo Pinzari - NoMachine- liberó desde un principio tanto la biblioteca de comunicaciones NX que implementa el protocolo como las herramientas de línea de comandos que permite establecer el proxy a ambos lados de la conexión. Con estas herramientas es ya posible lanzar una conexión NX sin problemas mayores que la complejidad de levantar un proxy X desde línea de comandos, y sin ningún problema adicional.

El problema es que mucha gente no tiene el conocimiento necesario como para establecer una conexión X a través de un proxy. Por ello, desde 2003 han nacido gran cantidad de aplicaciones, libres y propietarias, para configurar un proxy X con protocolo NX con facilidad. Algunas son extremadamente complejas, potentes e intuitivas. Incluso hay otras que permiten abrir una conexión NX con un servidor X dentro del applet Java de un navegador web. O incluso abrirlas empotradas en un escritorio con MS-Windows. Las hay muy sencillas: por ejemplo, FreeNX es apenas un puñado de scripts en bash. Como dijo Gian Filippo Pinzari, hablando en nombre de su compañía, NoMachine, en su primer mensaje: “sabemos que hemos hecho un buen trabajo, y queremos reservar una ventaja competitiva, pero es nuestro interés tener competición. Queremos empujar X y Linux como una plataforma de computación en red. Si X gana, nosotros ganamos”.

¿Que hace NX tan eficiente? Fundamentalmente, que han entendido que el problema es la latencia; así como que el sistema de caché es increíblemente inteligente. NX permite además tener conexiones a cientos de kilómetros de distancia con un modem; y, desconectando el cifrado, supera en rendimiento a X en red local. Y todo empleando software libre, bajo licencia GPL, en todo momento.

5.1 NX: caché de paquetes X

Como hemos estudiado, todos los proxies de X han cacheado mensajes de alguna forma. Sin embargo, NX mejora el concepto de cacheo respecto a como se implementaba en los proxies anteriores.

El problema de los proxies aceleradores de X anteriores era que la práctica totalidad de los mensajes de X son ligeramente distintos.

Por ello, un mecanismo de caché no sirve, ya que es muy difícil que haya dos mensajes exactamente iguales en una comunicación.

Sin embargo, NX toma una aproximación alternativa: partir los mensajes en dos partes, una denominada “identidad” y la otra denominada “dato”. La identidad habla de cosas como “qué se va a hacer” y “donde se va a hacer en la pantalla”, mientras que “dato” contiene qué se va a hacer.

Por ejemplo, el icono de retroceder de un navegador con frecuencia se transmite como un mensaje X de “dibuja un pixmap” en un punto determinado de la pantalla. Si redimensionamos el navegador y lo movemos, el servidor de procesos ordenará el redibujo de la pantalla del navegador, lo que supone reenviar el pixmap, pero con la orden de dibujarlo en un lugar diferente. El mensaje no es el mismo -cambia el campo de posición, aunque todo lo demás sea distinto-, por lo que no es cacheable directamente; pero, como vemos, partiéndolo en dos partes, podemos cachear el dato -el pixmap, que casualmente es lo que “cuesta” transmitir-, y transmitir apenas la identidad. La identidad la enviamos en formato incremental, con una idea similar a la que ya empleaba DXPC; solo que DXPC mandaba el incremental sobre el mensaje completo, mientras que NX manda el incremental de la identidad, y una referencia a donde encontrar el dato en la caché.

Sobresimplificando, y apenas para entenderlo, en nuestro ejemplo NX no manda dos veces el comando de redibujo del pixmap, sino apenas el incremental de la posición y un índice sobre una tabla de datos cacheados, conocida e idéntica en servidor y en cliente. Hay una tabla distinta por cada conexión entre cliente y servidor. El índice indica dentro de dicha tabla cual es el dato.

Como NX es capaz de hacer esta operación con iconos, pixmaps, fuentes, botones, sliders, barras de menú y menús desplegables, entendemos como funciona NX: primero comienza lento en enlaces lentos; pero según lo utilizamos, se hace más rápido: por ejemplo, el primer despliegue de un menú será lento, pero posteriores despliegues serán extremadamente rápidos.

Cada mensaje lleva una optimización de cacheo del dato y codificación incremental de la identidad propia. Actualmente, NX optimiza casi 170 mensajes de X, que son la práctica totalidad de ellos, consiguiendo una tasa de aciertos de caché del 75%. Para los mensajes más pesados en aplicaciones ofimáticas, tales como menús, iconos, fuentes y pixmaps, entre otros, la tasa de aciertos de la caché a partir de los primeros cinco minutos de jornada laboral se aproxima al 100%.

5.2 NX: Comprimiendo paquetes

Ya vemos como ganamos con esta política de cache; pero vemos que parte del problema lo delega en el primer arranque, que tendrá que transferir gran cantidad de pixmaps y componentes. Este primer arranque lo soluciona mediante la compresión.

Lo primero que nos va a sorprender es que NX nos pregunta sobre la velocidad esperada del enlace. Esto es muy importante, ya que NX emplea distintos mecanismos de compresión según el tipo de enlace; y, además, incorpora un sistema de arbitraje de ancho de banda para priorizar el tráfico interactivo, tal y como veremos más adelante.

Conocido el rendimiento del enlace, entra en juego la filosofía NX: el compresor sabe qué tipo de dato es -lo pone en la cabecera del mensaje X-, y sabe la velocidad del enlace; por lo que escoge el algoritmo más apropiado para mandar el dato por el enlace con la velocidad necesaria para mantener la interactividad. Por ejemplo, un pixmap en un enlace tipo modem se transferirá como un jpeg con pérdida, aunque se veaborroso. Cuando haya caudal libre, ya irá mandando lo que falta de la imagen al servidor X hasta que se vea bien el pixmap. Esto permite compresiones espectaculares, a un coste computacional de la compresión que no suele superar el 10% de un ZLIB estándar.

5.3 NX: eliminando los “paseos” de los paquetes

NX se diseñó teniendo en mente latencias bajas y máquinas poco potentes. Por ello, el protocolo se basó en órdenes sencillas que esperaban respuestas sencillas tipo “vale... mándame la siguiente orden”, para asegurar que no se saturaba la máquina responsable de hacer los dibujos: el servidor X. Para que nos hagamos una idea de la granularidad de los mensajes, tenemos casi dos centenares de órdenes distintas, transmitiendo órdenes tan sencillas como “dibuja un punto”, “dibuja una línea”, o “dibuja un rectángulo relleno de tal color”. En una red local, con máquinas de muy poca potencia, esto es un escenario ideal: no saturamos la máquina que dibuja, y transmitimos las órdenes de una en una. Pero si tenemos un enlace de alta latencia, la cosa se complica: cada mensaje que enviamos, llega con retraso. Retraso que se acumula al retraso del paquete de vuelta. Y así sumamos, retraso más retraso, hasta las dos docenas de órdenes en X que tiene, como mínimo, desplegar un menú. Para hacernos una idea, la latencia en local es despreciable -mover unos bytes de memoria de una posición a otra es casi instantaneo-. En red local, la latencia de un mensaje no llega al milisegundo. Pero en ADSL en España tenemos latencias que oscilan entre los 75 milisegundos y los 250 milisegundos, para dos máquinas conectadas al mismo proveedor -probado mientras que escribo este documento-. Si las máquinas están conectadas a proveedores distintos, o si la conexión es a través de modem, la latencia puede llegar al segundo, o incluso ser superior. Si hacemos cuentas, vemos porqué a Packard no le funcionó su sistema. Lo más importante: vemos porqué si solamente comprimimos, no resolveremos el problema.

La idea de NX para eliminar paseos de paquetes es simple: hay muchos mensajes que no pueden producir error, y solamente van a recibir como contestación un “vale”, por lo que falsificamos el mensaje, le decimos al servidor de procesos el “vale”, y seguimos recibiendo mensajes y enviándolos, aprovechando la minimización de la latencia que produce el hecho que pasamos de trabajar con ventana de tamaño 1 a ventana del tamaño que queramos.

5.4 NX: Arbitraje de ancho de banda

Finalmente, hay enlaces que son demasiado lentos. Aquí entra la optimización final de NX: incorpora arbitraje de ancho de banda, priorizando el trafico de paquetes de la parte interactiva del protocolo X. Esto significa que en NX, aunque el enlace esté saturado y haya que traerse fondos que son imágenes pesadas, va a funcionar sin problemas. En el caso de la imagen en X, si hay que traer una imagen, la trae de una pieza, y después atiende a los siguientes mensajes. Si vemos lo que tardará en transmitir un fondo por la red, veremos el tiempo que perderemos el control de la terminal.

NX parte todos estos paquetes grandes en trozos pequeños, intercalando dentro de la transmisión de los grandes pixmaps aquellos mensajes pequeños que correspondan a la respuesta interactiva: movimientos de teclado y de ratón. Si unimos a esto la codificación incremental de las imágenes, tenemos un efecto inmenso de cara a la sensación del entorno. Entramos, y vemos que funciona el escritorio y podemos operar con él. Aunque si acercamos los ojos al monitor, veremos como tanto el fondo como los iconos tienen una pixelación muy fuerte, y le lleva un tiempo que se vean perfectos -le lleva lo que cueste traerse estas imágenes comprimidas por el enlace que tengamos-. Al poco tiempo de uso, todo se verá como en local.

5.5 NX: compatibilidad hacia atrás de aplicaciones

Como estamos viendo, NX es realmente un proxy sobre el protocolo X11 que acelera su función. El proxy se coloca a ambos lados de la comunicación, y se encarga de la compresión y el cacheo de los mensajes X. Esto significa que el hecho de emplear NX es completamente transparente a las aplicaciones, y que para ellas es indetectable si hay una capa intermedia de NX entre el servidor X local y el servidor remoto de procesos.

Desde el punto de vista del funcionamiento de NX, en el lado local del usuario, es decir, en el ordenador en el que se ejecuta el servidor de X - por lo tanto, desde el que se ven las imágenes- el proxy NX habla con el servidor X en protocolo X11, y envía la comunicación a través de la red al servidor de procesos. En el servidor e procesos, por otro lado, el proxy NX se hace pasar por un servidor X ante las aplicaciones, lo que permite hacer cosas tales como congelar sesiones de trabajo que luego se podrán recuperar.

La parte que ve la aplicación de NX -nxagent- es internamente un servidor Xnest modificado, para engañar a los procesos. Haciendo un poco de historia, el servidor Xnest era una de las arquitecturas disponibles de XFree86. Esta arquitectura tiene como característica que permite poner un servidor X completo dentro de una ventana de otro servidor X. En la actualidad, Xnest forma parte tanto de X.org como de XFree86, y es software libre. La modificación de nxagent sobre el código original de Xnest consiste en que, en lugar de dibujar las órdenes X como hace Xnest, nxagent las transmite por la red empleando el protocolo X. La compatibilidad con X, por lo tanto, es completa: en lugar de reimplementar un parser del protocolo X completo, toma un servidor X libre y lo emplea para conectarse con los procesos e implementar el protocolo.

Todo esto hace que cualquier aplicación que funcione en X, funciona en NX.

5.6 Sesiones persistentes en NX

El hecho de emplear para todas las conexiones unos procesos proxy del protocolo X11 a ambos lados permite que podamos desconectar el cliente NX del servidor NX y reconectarlo posteriormente manteniendo las aplicaciones abiertas y sin pérdida de datos. Esto con X11 no era posible: cada vez que queríamos apagar la máquina local, debíamos cerrar todos los programas remotos.

Además, en X11 con sesiones remotas una caída en la red suponía la pérdida de las aplicaciones remotas en las que estábamos trabajando. En el caso de NX, por el contrario, la caída de la conexión apenas provoca que las aplicaciones gráficas que visualizamos en el cliente pasen a suspendidas en el servidor; pudiendo reconectarnos y recuperar lo que estábamos haciendo cuando sea posible.

Esta característica de supervivencia ante un corte de red es crítica en entornos de producción reales: no es admisible, por ejemplo, que una sobrecarga en las comunicaciones haga que cientos de usuarios de entornos ofimáticos pierdan aquello en lo que estaban trabajando.

La desconexión nos permite no solamente recuperar la conectividad ante redes que caen y vuelven con frecuencia, sino que tiene también muchas más aplicaciones. Por ejemplo, podemos recuperar las sesiones entre un día y otro: cuando dejamos de necesitar el ordenador, ordenamos una desconexión, y cuando volvemos a necesitarlo, reconectamos. Esto tiene un uso mucho más importante de lo que pueda parecer: podemos emplear esta característica de NX para ahorrarnos el tiempo de arranque de las sesiones KDE o Gnome. Otro uso es con portátiles, ya que podemos desconectarnos de la sesión en una oficina; viajar a otra oficina, y reconectarnos a la misma sesión, con todos los programas abiertos tal y como lo dejamos en la primera oficina. Incluso podemos desconectarnos de una máquina, ir a una ubicación física distinta, y empleando una máquina distinta reconectarnos a la sesión que teníamos en la máquina original con todos los programas tal y como estaban en la primera sesión. La única restricción que tendremos es que si nos conectamos desde máquinas distintas, debemos tener en ellas la misma resolución de pantalla y la misma cantidad máxima de colores posibles. Pero dejando la definición de todas las máquinas a algo estándar -por ejemplo, 1024x768x24-, tendremos suficiente.

Esta característica no funcionaba adecuadamente en las primeras versiones de FreeNX -la implementación libre del servidor; pero en las últimas versiones de FreeNX ya funciona perfectamente.

El único problema que nos dará la persistencia de sesiones está en un servidor FreeNX mal configurado, en el que podamos dejar muchas sesiones suspendidas por cada usuario que se desconecte por la fuerza, y no se reconecte recuperando la sesión. Esto no consume procesador en el servidor NX, pero sí puede consumir memoria; y, de forma paulatina, causarnos un problema después de varias semanas de uso continuado del servidor.

5.7 NX y otros protocolos

NX también puede encapsular otros protocolos, además de X11.

Estos protocolos adicionales son el RDP -Remote Desktop Protocol-, empleado por los Window Terminal Servers, y el RFB -Remote Frame Buffer-, empleados por los servidores VNC -Virtual Network Computing-.

Como en el caso de los mensajes de X11, el truco está en que NX emplea un agente en el servidor de procesos que engaña al proceso y le hace creer que está comunicándose con el servidor apropiado.

Para el caso concreto del protocolo RFB -empleado por VNC-, el agente es el llamado nxviewer. Este daemon es una adaptación el código de vncviewer para que “hable” en VNC nativo con el proceso, y por otro lado emplee el protocolo NX para mandar los datos. Como emplea el propio código de vncviewer, es completamente transparente a las aplicaciones.

“nxviewer” incrementa el rendimiento de VNC, dado que cachea y manda incrementalmente las imágenes, algo que VNC no hace; aún así, el X11 encapsulado en NX es más rápido que VNC o que VNC encapsulado en NX en las pruebas experimentales desarrolladas. En las pruebas, VNC encapsulado en NX es entre tres y ocho veces más rápido que VNC sólo; y X11 encapsulado en NX es un orden de magnitud más rápido que VNC. Además, la experiencia del usuario con un enlace con la latencia de un ADSL y el ancho de banda de un modem es muy similar a la de un acceso local con X11 encapsulado en NX, algo que no se obtiene ni con VNC ni con VNC encapsulado en NX.

RDP también tiene su solución: emplea una modificación masiva a rdesktop para conseguir este efecto.

5.8 Exportando la impresión

NX nos permite ver la impresora local en la sesión remota. Esto significa que nuestro terminal puede tener conectada una impresora, que tendremos encima de nuestra mesa. Podemos establecer desde el terminal una conexión remota con un servidor NX que puede estar a cientos de kilómetros de nuestra ubicación; pero cuando queramos imprimir, veremos nuestra impresora local y podemos imprimir en ella con la misma comodidad y facilidad como si estuviéramos ejecutando una sesión local.

5.9 Pruebas de rendimiento de NX

Las pruebas de rendimiento de NX muestran que es capaz de reducir un escenario de arranque de KDE -que ya supera la transferencia de 5MB de datos- a apenas unos 40KB. Esto es una mejora de más de dos ordenes de magnitud en cantidad de datos transferidos, y en el peor escenario que hemos encontrado de comunicación de X con sus aplicaciones: el arranque de KDE.

Las pruebas realizadas de una máquina sobre un ADSL conectándose con otra a más de 250Km dan un tiempo de arranque de OpenOffice, de tres segundos, frente a nueve segundos de arranque de X en local. Esto se debe a la multitud de mensajes de X y de escenarios simples en este protocolo que establece OpenOffice al arrancar.

Empleando un teclista rápido, tecleando a la máxima velocidad que puede un texto sin parar de teclear en ningún momento, el ancho de banda empleado en NX es de 1,7kbytes por segundo de subida, frente a 34kbytes por segundo en X. El ancho de banda de bajada en este mismo escenario es de 1,8kbytes por segundo en NX, frente a los 66,5kbytes por segundo de X. Como vemos, ante un uso ofimático intensivo, NX emplea 20 veces menos ancho de banda que X.

Otra prueba interesante es la de desplegar el menú “Archivo” en el menú, y pasar el cursor de ida y vuelta, a suficiente velocidad como para que se rendericen todos los menús, entre “Archivo” y “Ayuda” y viceversa durante un tiempo. Esto permite verificar velocidades y latencias de desplegados de menús, y uso de la red para redibujar el menú desplegado. NX y X permiten la misma velocidad de desplegado de menús en este test -medido en número de vueltas completas-; por lo que la respuesta es la misma. Además, X envía 115,4Kbytes por segundo y recibe 72,7Kbytes por segundo, frente a los 54,5Kbytes por segundo de subida y 33,5Kbytes por segundo de bajada en NX.

NX mostró tener casi la misma respuesta en remoto a un centro a 250Km de distancia empleando un ADSL de la que tiene X en local, con una red de 100Mbps. La diferencia principal de respuesta está en la reproducción de vídeo en calidad DVD-algo evidente, puesto que llevar vídeo por un enlace ADSL, le pongas lo que le pongas por debajo, es vídeo en calidad DVD-. Además, el uso de ancho de banda de NX frente a X puede llegar a ser 20 veces menor. De hecho, el uso del ancho de banda en el escenario del teclista compulsivo está dentro de los parámetros normales de una comunicación por modem.

6. Otras Alternativas: AJAX

Actualmente se está popularizando el desarrollo de escritorios AJAX. La idea es, mediante tecnología AJAX y a través de un navegador, de ofrecer escritorios virtuales. Hay algunas experiencias de éxito al respecto, tales como Google Apps.

El AJAX cuenta como ventaja que es ejecutable en cualquier cliente desde un navegador, sin necesidad de instalar nada en cliente. Es una tecnología nada intrusiva en los ordenadores clientes -no hay que instalar nada-; por lo que está teniendo uso para realizar tareas simples -lectura/edición de correo, edición de texto simple-. Sin embargo, cuenta con desventajas importantes: la más importante es que hay que hacer desde cero todas y cada una de las aplicaciones.

Dadas las limitaciones técnicas del AJAX y que la gente que desarrolla con esta tecnología las asume, actualmente se está avanzando bastante; mediante el desarrollo de aplicaciones intencionadamente sencillas; o mediante el desarrollo de aplicaciones comunes con el mínimo de la funcionalidad.

7. Otras Alternativas: Escritorio Virtual Java

La idea del escritorio virtual Java es mediante tecnología Java hacer un escritorio remoto.

Esta idea comparte el principal problema con el escritorio remoto AJAX: es necesario rehacer desde cero todas las aplicaciones que queramos habilitar en el escritorio virtual. A diferencia de AJAX, sí requiere instalar aplicaciones -particularmente, la versión apropiada de la máquina virtual Java- en los ordenadores clientes.

Actualmente no existe ningún escritorio virtual en Java con una funcionalidad ni siquiera mínima; por lo tanto, frente a la solución NX que es plenamente funcional, ya está en producción en numerosos lugares, y hereda todas las aplicaciones preexistentes de Unix, y la de AJAX, que hay que rehacer aplicaciones pero ya cuenta con algunas aplicaciones sencillas, el desarrollo de un escritorio virtual Java supondría desarrollar un inventario de aplicaciones necesarias y las funcionalidades deseadas, y comenzar a implementar todas y cada una de dichas aplicaciones, en Java y desde cero. Independientemente de el coste que esto pueda suponer, el tiempo necesario para hacerlo sería, como mínimo, extremadamente grande, aun contando con generosos recursos.

Bibliografía

  • “El protocolo NX”, Todo Linux, Número 71
  • “Arquitectura del sistema NX”, Todo Linux, Número 72
  • “Configuración de un servidor FreeNX”, Todo Linux, Número 73
  • “Configurando un cliente de NX”, Todo Linux, Número 74

RevistaeSalud.com es una publicación electrónica que intenta promover el uso de TICs (Tecnologías de la Información y las Comunicaciones) con el propósito de mejorar o mantener la salud de las personas, sin importar quiénes sean o dónde estén.
Edita: FESALUD – Fundación para la eSalud
Correo-e: edicion@revistaesalud.com
ISSN 1698-7969		 Los textos publicados en esta revista, a menos que se indique lo contrario, están sujetos a una licencia de Reconocimiento-NoComercial-inObraDerivada 2.5 de Creative Commons. Pueden copiarse, distribuirse y comunicarse públicamente, siempre que se citen el autor y la revista digital donde se publican, RevistaeSalud.com. No se permite su uso comercial ni la generación de obras derivadas. Puede consultarse la licencia completa en http://creativecommons.org/licenses/by-nc-nd/2.5/deed.es

¿Cómo citar este artículo?