“Now is the applet of our discontent made glorious channel by this son of California”. ¡Demonios! No pude sustraerme a mancillar Ricardo III [1] con rematizados juegos de palabras (son/sun) y ambiciones gloucestéricas. Pero ¿quién no sucumbiría ante las dicotomías Eduardo IV-Bill Gates y George de Gloucester-James Gosling? ¿O ante las apuestas sobre la identidad final de Enrique VII? [2] Y es que la ambición campa por sus fueros en la arena de Internet (rebosante de ingentes cantidades de anuncios interludiadas por fragmentos de información sin clasificar) bajo el renovado lema “absorbe y extiende”: cualquier avance mercadotécnico se presenta como un humanístico intento de convergencia de técnica y voluntades, como un contenedor de un nivel superior de genericidad que habrá de contemplar y englobar cualquier capa previa. Cada nuevo (y esto sí es un eufemismo) modelo de componentes, cada flamante lenguaje de programación, cada educado método de análisis y/o diseño, cada despuntante postulado tecnológico quieren ser superconjuntos de la supuesta desgracia técnica anterior. La ambición, ese “estiércol de la gloria” según Aretino, anega por igual buenas intenciones y ridículos despropósitos, de forma que el usuario difícilmente puede elevar su criterio por encima de la mierda para dilucidar qué, cómo o cuándo. Claro que la tragedia de Ricardo III se sustenta, además de en la ambición, en el descontento desmedido. Y no me digan que esto les resuena shakespearianamente lejano en una época en que las versiones de producción no son sino efímeros estadios inestables entre versiones betas. Los usuarios se agolpan, presas de versionamiento compulsivo, ante versiones de validación de productos desconocidos:

“Pues, como te decía, acabo de cambiar la versión 3.0 de Netscape Navigator (NN) por la beta 2 de Netscape Communicator 4.0 (NC). Y es que la versión beta 2 de Microsoft Internet Explorer 4.0 (IE) me ocasiona problemas cuando uso la versión beta de Intel Internet Phone (IPhone), aunque, en realidad, me funciona muy bien con la versión alfa 1.1 de IBM Web Browser Intelligence (WBI). En cuanto al chat, dudo entre la versión beta 0.38 de Megalith’s Visual IRC ’96 (VIRC) o la beta 5 de OnLive’s Traveller. Y para el web-quasi-offline, ¿qué mejor que la última versión beta de PointCast News 3.0 ó la más reciente versión beta de FreeLoader 3.0? Claro que para visualizar los applets que he creado usando Java Workshop Beta Dev6... Por cierto, ¿qué versión de matrimonio estás evaluando actualmente? ¿Yo? Bueno, mi último divorcio me lo llevó un famoso abogado en pre-release, un poco menos caro de lo habitual pero con algunos tics nerviosos propios de los ensayos, así que... Sí, sí, estoy probando la nueva calefacción en versión gamma, aunque no me hacen mucha gracia las mutaciones que me empiezan a salpicar el torso y la cabeza... Bueno, claro, sí, mi inteligencia está aún en Confidential Field Test, pero espero llegar a la fase alpha en unos pocos años...”

He aquí, pues, cómo usuarios, profesionales y empresarios trocan los nichos del eterno descontento en nichos de mercado, de forma que se cumple la ecuación “Internet + desvergüenza = maraña de betas”. Se entiende así que la actualización de productos juegue tan importante papel en Internet y en la líbido de los internistas, usualmente atrapados por la angustia de encontrar su buzón de mensajes casi siempre vacío. Actualización es, pues, el concepto totémico, de forma que... ¿por qué no canalizarlo?

ACTUALIZACIÓN DE CANALES

En su uso habitual, los sintonizadores/clientes, dependientes de la plataforma Java y, por tanto, independientes de algunas de las otras plataformas, requieren a servidores especializados llamados transmisores (o más usualmente a repetidores, como después veremos) la actualización de uno o más canales. Naturalmente este mecanismo de “tirar” (pull) de la información hacia la parte cliente encaja perfectamente con los sistemas protectores (firewalls) de las redes corporativas, puesto que la transacción no se inicia del lado servidor por difusión (broadcasting), sino del cliente por selectividad [3]. Pero la esencia del sistema es que no haya que descargar cada vez, como ocurre con los applets, el código entero representativo del aplicativo. Así que la actualización diferencial de canales es la ventaja estratégica que Marimba propone frente a la desventaja de una mayor demora en la carga inicial de los mismos (pues éstos, por su propia naturaleza, tienden a no ser pequeñas porciones de código, como los applets, sino más bien auténticas monstruosidades en tamaño). El mecanismo (patentado por Marimba) es como sigue: cuando un sintonizador requiere una actualización, envía a la vez al servidor una estructura de datos denominada índice (el esquema de “pulling” supone que el servidor desconoce el estado actual del canal en la parte cliente), que en realidad no es sino una estructura arbórea cuyos nodos representan cada uno de los ficheros asociados al canal. La representación o huella (fingerprint) de cada fichero se calcula mediante la aplicación del algoritmo MD5 al contenido del fichero mismo, de tal manera que con independencia de éste se genera siempre una huella de 128 bits. A su vez los directorios que albergan a cada conjunto de ficheros poseen una huella digital representativa de la agregación de las huellas de los ficheros que contienen. Cuando tal huella llega al transmisor (o repetidor), éste la compara con el índice más actualizado que mantiene del canal o canales correspondientes. Si alguna huella de fichero ha cambiado, el transmisor envía tal fichero al sintonizador/cliente. Naturalmente la comparación de las huellas de los directorios acelera sobremanera la comparación, de tal forma que si coinciden las huellas del directorio base del canal en sintonizador y transmisor, éste entenderá que no hay nada que actualizar, mientras que, en caso contrario, se procederá a la transferencia de ficheros mediante una única conexión TCP (en contraste con las diferentes conexiones necesitadas para cada fichero en la descarga convencional de applets).

CACHÉ Y VERSIONAMIENTO

El mecanismo de actualización resulta simple y convincente, pero he aquí que el atento lector habrá de objetar: “No parece, con todo, especialmente eficiente que cada vez haya que enviar la estructura completa de nodos”. Ciertamente. Y es por esto que los transmisores mantienen almacenada en sus cachés tablas de huellas de canales contra las que comparan la información enviada por el sintonizador, que se limita, en primera instancia, a la huella base (la correspondiente al directorio base del canal). El procedimiento de antememoria es simple y particularmente efectivo: aparte de mantener la huella base más actualizada de un canal dado, el transmisor también conserva en su caché los índices relativos a estados previos del canal, de forma que al enviar un sintonizador una huella base, el transmisor comprueba si tiene en su caché tal huella: si no la tiene, requiere al sintonizador que le envíe el índice completo; por el contrario, si la encuentra, no necesitará información adicional para remitir al cliente los ficheros que necesitan cambio para que el canal quede en su última versión. Naturalmente si el transmisor recién empieza a funcionar, o si se acabara de recuperar de un fallo, deberá requerir las primeras veces los índices completos a los sintonizadores para construir su tabla-caché. “Ya, ya: actualización diferencial –exclama el desconfiado lector-. ¿Y si se corta la comunicación antes de terminar la transmisión? ¿Se quedaría el canal en estado inestable?”. Por supuesto que no: la descarga de ficheros se encapsula en transacciones que preservarán el estado del canal, de forma que no se aplicará ningún cambio si la actualización finalmente no se completo. Historia distinta es si se podrá aprovechar el caché de lo correctamente transferido en la reconexión.

TRANSMISORES

Un transmisor es, en breve, un servidor de canales establecido bien como extensión de un servidor HTTP bien como un conjunto independiente de procesos. Claro que los transmisores no se limitan a emitir canales y procurar el servicio transaccional de versiones, sino que pueden ser personalizados mediante apósitos conectables (plug-ins), codificados bien en C++ bien en Java, para que procesen datos y peticiones de diversa índole provenientes de los sintonizadores. Y es que resulta que, aparte del índice necesario para la actualización de canales, el sintonizador se autoidentifica en el servidor mediante una secuencia pretendidamente única. El transmisor guarda tal identificador y puede, por tanto, efectuar distintos tipos de seguimiento o control del sintonizador y de los canales que el mismo controla en el equipo del cliente. Claro que el ingenuo usuario normalmente desconoce cuanto ocurre tras el telón de interfaces software tan profusamente coloreados. O sea, que un transmisor podría, por ejemplo, enviar una actualización a un cliente dado y a requerimientos de éste, almacenar después su identificador para, más adelante, almacenar información correspondiente sobre nuevas actualizaciones requeridas por el mismo sintonizador, sobre las claves de acceso del mismo a organismos secretos interestatales, sobre sus licencias pirateadas y, ¿por qué no?, sobre su masculina afición a probarse ropa interior femenina. ¿Se imaginan? El transmisor pasa la información al plug-in adecuado para que éste la procese, la almacene o la publique en un tabloide. Claro que –se asegura- el usuario puede permanecer anónimo por el simple procedimiento de instruir en tal sentido al sintonizador. Bien: superada la disgresión, la idea comercial que Marimba intenta comunicar es: “cuartos privados de disfrute (off-line), actualizaciones y nuevos productos, confidencialidad garantizada”. Aunque, claro, esto resuena a peep-show.

REPETIDORES

Una misma máquina podría utilizar distintos transmisores de canales en un intento de manejar más adecuadamente la creciente progresión de peticiones de sintonizadores, pero esta estrategia creará finalmente un peligroso cuello de botella en la entrada de peticiones al servidor. A fin de evitar estos inconvenientes y garantizar a la vez la escalabilidad de la arquitectura de distribución, Castanet provee “repetidores”, que son por un lado transmisores (pues sirven canales a sintonizadores) y por otro sintonizadores (pues requieren a servidores dados, de forma automáticamente programada, la actualización de las copias de los distintos canales que conservan). El repetidor puede estar geográficamente cerca o enormemente distanciado de sus transmisores asociados (a los que se suscribe en su también calidad de sintonizador, por lo que necesitará, como éstos, un disco duro para almacenar los canales), y su comportamiento respecto de sintonizadores y transmisores es como sigue: cuando un sintonizador conecta por vez primera con un transmisor, éste instruye al sintonizador para que redirija sus peticiones de carga/actualización a un repetidor, bien cercano bien poco sobrecargado, de forma que el sintonizador toma nota y las sucesivas llamadas las realizará al repetidor. El sintonizador no olvida, con todo, la dirección del transmisor primero, de forma que si acaso desapareciera el repetidor asociado o se mostrara temporalmente inaccesible, el sintonizador accedería de nuevo al transmisor primero para requerirle la dirección de un repetidor sustitutivo de aquél. Se trata, de nuevo, de la educación responsable unida a la memoria reclamante: vamos, lo mismo que ocurre cuando recomiendas un restaurante a tu vecino del quinto: en adelante acudirá sin avisarte, hasta que el cierre vacacional o definitivo del establecimiento le obligue de nuevo a pedirte consejo. Lo mejor del enfoque de Castanet es que resulta transparente para el cliente, de forma que éste no habrá de notar (es la esperanza de Marimba) redirecciones automáticas a distintos repetidores por parte de sus servidores de canales. Para el creador/programador/desarrollador de canales el esquema también posee su enjundia, pues inmediatamente de insertar en un transmisor la última versión de un canal dado, aquél lo transmitirá en cascada a su red de repetidores, probablemente locales en primer lugar para que éstos después contacten con repetidores lejanos, y, en consecuencia, el canal actualizado resultará inmediatamente accesible por los sintonizadores afectados.

MECANISMOS PROTECTORES EN INTRANETS

La necesidad de proteger los datos interiores a una corporación (valiosos o no) genera la necesidad de establecer barreras protectoras (firewalls) que impidan la entrada no autorizada desde el exterior (usual, pero no únicamente, desde Internet), permitiendo, no obstante, el uso de recursos externos por personal de la corporación. Tal uso se sustancia sobremanera en el acceso al WWW, de forma que es habitual que las empresas dispongan de proxies HTTP que encaminen y cacheen los accesos, lo que suele generar no pocos cuellos de botella. Aunque, como puede verse en la figura, el sintonizador admite tal tipo de proxies, la solución optimizada de Marimba consiste en un proxy transmisor especializado en canales, de forma que puedan requerirse múltiples actualizaciones en la misma conexión. El mecanismo es sencillo: el proxy mantiene en su caché los ficheros constitutivos de los canales asociados a las peticiones de los sintonizadores interiores a la corporación. Cuando el proxy recibe un requerimiento de un sintonizador comprueba si cuenta en su caché con los ficheros necesarios para satisfacerlo (mediante un procedimiento similar al que utilizan los transmisores para comparar índices): si falta algún fichero utiliza la conexión abierta con el transmisor/repetidor para a su vez requerirlo e inmediatamente guardarlo en su antememoria, para finalmente transmitir los ficheros adecuados al sintonizador. El hecho de mantener abierta la conexión TCP con el transmisor evita la creación de una conexión distinta para cada petición de un distinto sintonizador, de forma que se evita la innecesaria repetición y se facilita enormemente la gestión corporativa de actualizaciones.

DISCO SÍ, DISCO NO

La estrategia de Sun se basa en que la red es el ordenador, o en que el ordenador es la red (nunca recuerdo el orden exacto , pues me parece que la intención del lema es reflejar que los conceptos red y ordenador están delicada e inexorablemente conectados, pero que puestos a elegir ... ¿para qué demonios sirve un ordenador?), de forma que tiene poco sentido la capacidad de almacenamiento en la débil parte cliente. El direccionamiento de Microsoft se sostiene, por otra parte, en espacios de almacenamiento dedicados a sostener el kernel del imperio. Castanet, por último, requiere de almacenamiento local nada leve, capaz de soportar Mbs y Mbs de información cualificada como programas, datos, páginas HTML, etc. pues, como ya hemos visto, transmisor, repetidor, proxy y sintonizador lo necesitan para poder operar off-line con las aplicaciones software provistas por los canales, aparte del importante hecho de la eficacia en la ejecución del código y la disponibilidad inmediata de las aplicaciones. Claro que no se trata únicamente del disco duro, sino posiblemente también de RAM estática o de tecnologías parejas. La cuestión es “¿Cómo enfrentar las tres visiones?”. A van Hoff le parece impensable que pueda eliminarse el disco duro de las estaciones de trabajo, toda vez que el ancho de banda ni es gratuito ni es siquiera “ancho”, sobre todo si se trabaja con equipos portátiles y módems de conexión telefónica, y es evidente que la mayoría de aplicativos necesitan caché local. Van Hoff finalmente expone que, si bien los discos duros tienen dos grandes pegas (primera: son componentes con partes móviles que acortan sustancialmente la vida de los equipos; segunda: el usuario tiene que administrarlos), Castanet soluciona totalmente la segunda: esto es, el usuario no tendrá que preocuparse en absoluto por la gestión de su disco duro, ya que las cuitas de distribución de ficheros serán asumidas por administradores remotos o por los creadores/desarrolladores de los canales, que asumirán el control por medio del sintonizador. Claro que consentir en la administración remota de nuestro disco duro puede conllevar importantes implicaciones legales y de seguridad, que trataremos con más detalle en un futuro capítulo.

BONGO, BONGO

or supuesto que son importantes los productos: la película, el libro, los canales, etc., pero.. ¿qué me dicen del merchadising? ¿Cuál es la forma idónea de crear aplicativos que encajen perfectamente en el esquema arquitectónico provisto por Marimba? ¡Mediante una herramienta Marimba, naturalmente! Claro que algún lector descreído podría mentar que “Bongo, como el gorila Bing-Bong, no es sino una acumulación de efectos especiales y fuegos de artificio en un entorno fílmico en el que no falta ni la heroína (Kim Polese)”. Humm, ciertamente el lector es un tanto cáustico, pero confieso que me gusta la idea: imaginen a Bongo subido en las Torres Gemelas y siendo bombardeado con applets desde aviones propulsados con una única máquina virtual Java, mientras sostiene en sus garras a... bueno, ciertamente continuaremos en el próximo capítulo dedicado -¿cómo no?- a King Bing-Bongo.

[1] Esta obra de Shakespeare es asignatura obligatoria en la carrera de los prebostes informáticos, pues versa sobre asesinato, traición e impostura con una intensidad solo imaginable en ciertos entornos tecnológicos y organismos de estandarización. Ciertamente el tullido Ricardo es el actual Larry Hagman de los círculos empresariales.

[2] Si esto no es acicate y motivo para que el lector lea, no sé qué puede serlo. Claro que he de confesar que en Ricardo III se encuentra mi Shakespeare preferido, y después en Macbeth.

[3] En el esquema sexual los machos han operado tradicionalmente mediante “broadcasting” y “multicast flirting”, difundiendo sudores y deseos por doquier, mientras que las hembras han utilizado selectivos procesos de “pulling” y “picking” compatibles con sus “firewalls” (violaciones y “hacking” aparte). Claro que... “things change”.