Hoy, el mundo pertenece al protocolo TCP/IP. Estos dos protocolos -
junto al UDP - gobiernan la mayoría de las comunicaciones remotas entre
sistemas de cómputo. Pero pienso que es maravilloso poder encontrar, aún
ocultos entre las alcantarillas de la Internet, secciones de otras
cañerías anteriores, casi extintas, con un nombre evocativo. ¿Qué era la
Red del Caos? ¿Y porqué está metida en el asfalto telemático, como esos
viejos rieles vestigiales del tranvía porteño?
Usemos el comando dig y interroguemos al DNS sobre texto-plano.xyz. Nos
responderá crípticamente algo como:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;texto-plano.xyz. IN A
;; ANSWER SECTION:
texto-plano.xyz. 300 IN A 207.246.69.54
;; Query time: 3 msec
;; SERVER: 108.61.10.10#53(108.61.10.10)
;; WHEN: Sat Jan 15 12:05:50 UTC 2022
;; MSG SIZE rcvd: 60
Como vemos, la devolución nos presenta una sección que decribe la
"pregunta" que le hicimos (¿cuál es la dirección IP de texto-plano.xyz?)
y una sección a continuación que nos describe la respuesta que nos da
dig. En la sección de respuesta, vemos que encontró un único registro
con lo que parecen ser cinco campos. El tipo de registro se indica por
la A en el cuarto campo desde la izquierda, este es el registro de la
"dirección". A la derecha de la A, en el quinto campo, se puede ver la
dirección IP de texto-plano, que es 108.61.10.10. El valor 300 en el
segundo campo especifica cuanto tiempo puede ser cacheado este registro
en particular (en segundos).
¿Qué nos dice el campo IN? Por un tiempo bastante largo, pensé que el
campo IN funcionaba como una preposición, y que cada registro DNS decía
algo como "exto-plano.xyz está en A y tiene una IP de 108.61.10.10".
Resulta que el IN realmente significa "Internet". La parte de IN en un
registro DNS nos especifica la Clase del registro.
¿Porqué entonces el registro de DNS tendría una clase distinta que la
"internet"? ¿Qué otra cosa podría haber? ¿Como iba a buscar un huésped
que no estuviese hospedado en la internet? Parecería obvio que el único
valor almacenado en el registro tendría que ser IN y que hay otro. De
hecho, cuando le intentamos interrogar por la dirección de
texto-plano.xyz mientras que le especificamos una clase distinta a IN,
el servidor DNS probablmente se queje. Por ejemplo, cuando intentamos
preguntar la IP de texto-plano pidiendole una clase HS, el nombre del
servidor en 8.8.8.8 (el DNS público de Góogle) nos devuelve una REFUSED:
``` $ dig -c HS texto-plano.xyz
;; Query time: 0 msec
;; SERVER: 108.61.10.10#53(108.61.10.10)
;; WHEN: Sat Jan 15 12:15:22 UTC 2022
;; MSG SIZE rcvd: 44
De modo tal que otras clases distintas a IN no son bastante soportadas.
Pero existen. Además de IN, los registros del DNS pueden tener clase HS
(como vimos) o la clase CH. La clase HS está reservada para el uso por
un sistema llamado Hesiod, que almacena y reenvia datos textuales
simples usando el sistema DNS. Se lo usa típicamente en ambientes
locales como un reemplazo para un stack LDAP. La clase CH en cambio se
reservaba para algo llamado "La red del Caos".
La sala de máquinas del MIT
ChaosNET fue desarrollada en la década de 1970 por los investigadores
del Laboratorio de Inteligencia Artificial del MIT. Fue creada como
parte de un proyecto destinado a diseñar y construir una máquina capaz
de correr el lenguaje de programación LISP de una manera más eficiente
que en un mainframe de propósito general.
LISP era la creación del profesor John McCarthy, precursor
estadounidense del campo de la inteligencia artificial. Lo describió por
vez primera en un paper de 1960, y para 1962 ya existían un intérprete y
un compilador. El novedoso lenguaje introducía muchísimas caracterísicas
que hoy consideraríamos estándares en programación. Fue el primer
lenguaje en contar con recolector de basura, un REPL, y primero en dar
soporte al tecleo dinámico. Como resultado, fue muy bien recibido por
los investigadores del campo de la inteligencia artificial, quienes -
por nombrar un ejemplo - lo usaron definir la famosa demostración
SHRDLU, en la cual podía controlarse un robot computarizado que
manipulaba bloques de juguete siguiendo acciones mediante órdenes
dictadas en lenguaje natural. Todo un logro de finales de los 60s.
LISP tendía a ser lento y esto era un problema. Las operaciones simples
solían tardar el doble de tiempo en ejecutarse ya que las variables de
LISP se sometían también a revosión de tipeado tanto al momento de
ejecución como en el de compilación. El recolector de basura de LISP es
recordado por tardar un segundo entero en el mainframe IBM 7090 del MIT.
Estos desempeño maculado no podía dejar de ser muy criticado, ya que los
investigadores de IA se concentraban en programar aplicaciones que
debían ser capaces de interactuar con sus usuarios en tiempo real. Para
finales de la década de 1970, un grupo de investigadores del laboratorio
de IA del MIT decidió abocarse a enmendar estos problemas mediante la
construcción de máquinas diseñadas específicamente para correr programas
LISP. Estas "máquinas LISP" contarían con más memoria y un conjunto de
instrucciones más circunspecto, lo que las haría especialmente aptas
para funcionar con LISP. La revisión de tipeo se haría en una
circuitería dedicada, acelerando el funcionamiento en varios órdenes de
magnitud.
A diferencia de la mayoría de los sistemas de cómputo del momento, las
máquinas LISP no podrían operar a tiempo compartido, ya que los
ambiciosos programas de LISP solían requerir todos los recursos de la
computadora. Cada usuario recibiría su propia CPU. En un memo, el Grupo
de Máquinas LISP en el MIT describe como esto haría que la programación
de LISP fuese mucho más sencilla:
La máquina LISP es una computadora personal. El cómputo personal
significa que el procesador y la memoria principal evitan ser
multiplexados en tiempo real, sino que cada persona recibe la
suya propia. El sistema de computación personal consiste en una
lista de reserva de procesadores, cada cual con su propio banco
de memoria asociado, y su propio disco para tareas de
intercambio. Cuando un usuario abre su sesión remota, recibe la
asignación un procesador, que cuenta como uso exclusivo por la
duración de la sesión. Cuando cierra la sesión, el procesador
vuelve a la lista de reserva, para suplir a la siguiente persona
que desee utilizarlo. De esta forma desaparece la competencia
entre usuarios por el uso del banco de memoria; las páginas a
las que los usuarios refieren con frecuencia permanecen
almacenadas en núcleo, de modo tal que la realización de
almacenaje de intercambio se reduce considerablemente. Por
tanto, la máquina LISP resuelve el problema básico del sistema
LISP de tiempo compartido.
La máquina LISP sería una computadora personal en un sentido distinto al
que consideramos actualmente. Los usuarios previstos por el Grupo de
Máquinas LISP se sentarían en sus oficinas no frente da su propia
máquina LISP, sino frente a terminales remotas. Las terminales estarían
conectadas a la máquina LISP real, localizada en otra premisa. Cada
usuario apropiaría un procesador de la CPU, y ésta se encontraría
"alejada, en una sala de máquinas", ya que se preveía que dichos
mainframes fuesen ruidosos y voluminosos, y por tanto "no serían
bienvenidos como compañeros de oficina". Los procesadores compartirían
acceso al sistema de archivado y a dispositivos tales como las
impresoras, a través de una red de datos local de alta velocidad "con un
control completamente distribuido". Esa red era la Red del Caos
(ChaosNET).
ChaosNET consistía tanto en un estándar de hardware como un protocolo (o
acuerdo) de software de comunicaciones. El estándar de hardware recuerda
al de Ethernet, y de hecho el protocolo de software de Chaosnet podía
operar sobre Ethernet de forma eventual. En tanto, el protocolo de
software - que escifica tanto la interacción de la capa de red como la
capa de transporte - estaba pensado para gobernar siempre una red de
tipo LOCAL (a diferencia de TCP). En otro memo publicado por el
Laboratorio de Inteligencia Artifical del MIT, David Moon - miembro del
Grupo de Máquinas LISP - explica que ChaosNET "no continene provisiones
especiales para enlaces de baja velocidad, enlaces ruidosos, ruteos
múltiples, ni enlaces de larga distancia con retrasos de tránsito
significativos". El foco est6aba puesto en diseñar un protocolo que
superara a otros en lo referente a redes pequeñas.
Lo importante para el Caos era la velocidad, ya que ChaosNET residiría
entre cada procesador LISP y el sistema de archivado. Los retrasos en la
red de datos podían dificultar incluso las operaciones más
rudimentarias, tales como ver el contenido de documentos de texto. Para
lograr velocidad meteórica de 3 Megabits por segundo, la red del caos
incorporaba ciertas mejoras sobre el NCP (el Programa de Control de Red
en boga en la ARPAnet). Según Moon, "es importante degollar los cuellos
de botella que plagan la ARPAnet, por ejemplo el control de enlace
compartido entre múltiples conexiones y del cual se requiere acusar
recibo antes de autorizar el envío subsiguiente". El protocolo ChaosNET
lotea los acuses de recibo con similitud al TCP actual, y manera de
reducir a un tercio el número de paquetes requeridos para transmitir.
ChaosNET podía utilizar también un algoritmo de ruteo relativamente
simplón, donde la mayoría de los huéspedes de la red de máquinas LISP se
imaginaban enlazados a través de un único cable corto. Moon escribió que
el esquema de ruteo de Chaosnet "se predica en asumir una geometría de
red simple, donde existen múltiples rutas y que la longitud de estas es
lo suficientemente corta. Esto hace innecesario esquemas más
sofisticados". La simplicidad del algoritmo hacía que implementarlo
fuese trivial. El programa de implementación ocupababa la mitad que el
NCP de la Arpanet.
El protocolo Chaosnet contaba con otras idiosincrasias. La dirección de
Chaosnet sólo cuenta con 16 bits, la mitad que una dirección IPv4 (lo
que tiene sentido ya que Chaosnet sólo estaba pensado para funcionar
como una red local). Chaosnet carece de números de puerto. En lugar de
ellos, realiza solicitudes de conexión siguiendo un proceso de solicitud
de conexión especificando un "nombre de contacto". Este nombre de
contacto a menudo consistía unicamente de un nombre de servicio pelado.
Por ejemplo, el huésped podía intentar conectarse a otro usando el
nombre de contacto "TELNET". En la práctica esto opera de forma mas o
menos parecida que TCP, ya que un pedido de servicio a Puerto 80, podría
- por lo conocido - recibir un "nombre de contacto" específico como
HTTP...
La Clase de DNS para CHAOSNET fue agregada al sistema DNS en el
documento RFC 973 de 1986. Reemplazaba a la Clase CSNET, anterior, que
estaba definida para dar soporte un protocolo de red de la Red de Datos
de Ciencias del Cómputo. No queda claro porqué ChaosNET terminó
recibiendo este tratamiento especial dentro del protocolo DNS...
existieron otras clases de que podrían haber sido agregados pero nunca
lo fueron. Por ejemplo, Paul Mockapetris, principal arquitectosdel DNS,
escribió que originalmente imaginó incluir una clase para el protocolo
de red de datos de Xerox. Ese, muy usado en PARC, jamás se incluyó.
Puede que se haya agregado a Chaosnet simplemente porque los años
formativos de la ARPAnet se llevaron a cambio en la compañía de software
BBN (de Bolt, Beranek y Newman) en Cambridge, Massachussetts, cuyos
ingenieros eran "insiders" del MIT, y primigenios en el desarrollo del
TENEX, que aún usaban con devoción. Se dice que este grupo relativamente
pequeño - pero muy influyente en el desarrollo de las redes de datos -
hacían uso de la Red del Caos y su velocidad del rayo.
Pero el uso de Chaosnet se fue apagando conforme las máquinas LISP
fueron desconectándose. Si bien a principios de los 80s las máquinas
LISP eran equipos viables comercialmente - las vendían en EE.UU.
compañías formadas por ex-MITs tales como Symbolics y LISP Machines Inc
- lo cierto es que terminaron desplazadas por microcomputadoras de
fabricación masiva y más baratas capaces de correr LISP de forma
relativamente veloz sin necesitar carísima circuitería específica. El
TCP/IP terminó resolviendo muchos de los problemas del protocolo
original de la ARPAnet, a los cuales se había esperado resolvere con la
Red del Caos.
Ghost in the Shell
Desafortunadamente no existen gran información sobre la Red del Caos. El
RFC 675 - escencialmente el documento borrador del protocolo TCP/IP -
fue publicado en 1974. Chaosnet fue desarrollada por primera vez en
1975. TCP/IP terminaría conquistando el mundo, mientras la Red del Caos
resultó cincuscripta a una vía muerta.
Pero la vía existe. Existen grupos de retrocómputo encargados de
utilizar el protocolo y desarrollar hardware casero capaz de utilizar
Chaosnet para lograr los infernales y ya devaluados "tres megas por
segundo".
El único remanente realmente visible de la Red del Caos es la clase CH
en el protocolo DNS, que lo hace factible de puentear con TCP. Es algo
que la encuentro fascinante. La clase CH es un fantasma vestigio de un
protocolo de red alternativo para un mundo que ya se decantó por TCP/IP.
No puede dejar de ser excitante pensar que al igual que los rieles de
los tramways porteños, las últimas trazas de la Red del Caos se
encuentran embutidas allí abajo bajo el asfalto de las autopistas de la
sociedad digital. La clase CH del DNS es un divertido artefacto de
digi-arqueología. Pero también es un recordatorio viviente de que la
internet no nació ya formada, que TCP/IP no es la única forma de hacer
amar entre sí a las computadoras, y que a "la internet" le sacaron una
vuelta en eso de tener el nombre más épico del sistema de comunicación
global.
