Berknet

La red Berkeley , o Berknet , fue una de las primeras redes de área amplia , desarrollada en la Universidad de California, Berkeley en 1978, principalmente por Eric Schmidt como parte de su trabajo de tesis de maestría . ^[1] La red conectaba continuamente alrededor de una docena de computadoras que ejecutaban BSD ^[2] y brindaba servicios de correo electrónico , transferencia de archivos , impresión y ejecución remota de comandos a sus usuarios, y se conectaba a las otras dos redes principales en uso en ese momento, ARPANET y UUCPNET . ^[3]

La red funcionaba utilizando lo que entonces eran enlaces seriales de alta velocidad , 1200 bit/s en el sistema inicial. Su implementación de software se envió con la distribución de software de Berkeley a partir de la versión 2.0. ^[1] Consistía en una disciplina de línea dentro del núcleo Unix , ^[4] un conjunto de daemons que administraban colas de comandos que se enviarían a través de las máquinas y un conjunto de programas de nivel de usuario que ponían en cola los comandos reales. La red Berkeley introdujo el archivo .netrc .

El lanzamiento de UUCP como parte de la versión 7 de Unix en 1979 generó poco interés externo en el sistema; Mary Ann Horton señaló en 1984 que "los Berknets ya no existen". ^{[5] El soporte para el esquema} de direcciones de correo electrónico personalizado de Berknet se proporcionó en el programa Sendmail hasta 1993. ^[4]

El desarrollo de lo que se convirtió en Berknet comenzó con un concepto inicial desarrollado por Bob Fabry , el asesor de Eric Schmidt . Schmidt desarrolló el sistema hasta que se tomó un descanso en mayo. El sistema fue diseñado inicialmente para conectar solo dos máquinas, conocidas como A y Q, ambas máquinas PDP-11 que ejecutaban Unix . ^[6] El desarrollo se prolongó hasta el final del semestre en mayo. Para el 1 de mayo, el sistema inicial, que conectaba dos máquinas, A y Q, estaba operativo. Como el desarrollo se llevó a cabo principalmente en la máquina A, el sistema también se utilizó para distribuir el código a Q. La tarea servil de mover el código a Q condujo a los primeros esfuerzos para automatizar el sistema. ^[6]

A medida que el código empezó a funcionar, también empezó a ser utilizado por otros usuarios, lo que llevó a que A se conectara a una nueva máquina, C. Esto presentó el nuevo problema de que la implementación original requería el mismo inicio de sesión de usuario en ambas máquinas, y tratar de mantener esto sincronizado entre varias máquinas llevó a que el archivo de contraseñas de A se volviera demasiado grande. La solución inicial para este problema fue tener cuentas "gratuitas" dedicadas en ambas máquinas que usaba Berknet, junto con el uso del archivo .netrc para iniciar sesión automáticamente en ellas cuando fuera necesario. ^[6]

Luego se agregó una tercera máquina, Cory. ^[6] Para lidiar con el problema de la cuenta y manejar el enrutamiento físico, A se convirtió en un centro responsable de almacenar y reenviar cualquier mensaje entre C y Cory. Se introdujo un mapa de enrutamiento basado en tablas para controlar esto. Estaba en este estado cuando Schmidt completó la primera versión en mayo. Mientras estaba fuera, el Centro de Cómputo realizó varios cambios en el sistema, y ​​esto llevó a que surgieran varias versiones incompatibles de Berknet y a fallas periódicas del sistema, incluido el sistema sendmail que no funcionaba. ^[7]

Cuando Schmidt regresó al sistema en octubre, se había añadido una máquina VAX 11/780 , lo que elevó el total a tres versiones diferentes de Unix admitidas. Luego se utilizó make para compilar y distribuir el código a las máquinas, incluido el uso de la versión anterior del código para iniciar la máquina Cory, que ejecutaba Unix versión 6 mientras que las otras ejecutaban la 7. Otros cambios llevaron a una versión estable y comenzó la documentación, y se agregaron varios sitios adicionales. El rendimiento se convirtió en un problema, especialmente para las máquinas encargadas del reenvío, y requirió mantenimiento manual para mantener el sistema en funcionamiento. ^[8]

El sistema tenía cierta similitud con UUCP en el sentido de que utilizaba un sistema de transferencia de archivos en modo por lotes basado en un demonio Unix que realizaba las transferencias reales, así como la definición de un protocolo de red simple adecuado para mover los datos a través de los enlaces telefónicos. El protocolo está integrado en la aplicación net , que vigila la aparición de nuevos archivos en una serie de ubicaciones definidas que representan colas. ^[8] Cuando aparece un archivo, net inicia una conexión de terminal con la máquina remota seleccionada, emite comandos y realiza transferencias de archivos, y luego desconecta y elimina el archivo local si fue un éxito. ^[9]

Desde la perspectiva del usuario, hay varias aplicaciones independientes que componen el sistema: unas para leer y escribir correo, otra para mover archivos entre máquinas, etc. Todas ellas funcionan colocando archivos en las colas adecuadas que luego mueven automáticamente los datos a la máquina de destino, donde se vuelven a ensamblar y se vuelven a mover a los directorios del usuario para su uso. ^[8] La aplicación más utilizada era netcp , que copiaba archivos a través de la red. Se le proporcionaban dos nombres de archivo: el primero, la ruta al archivo existente, y el segundo, la ruta a la ubicación final deseada. Las rutas eran una combinación de un nombre de máquina seguido de dos puntos y, a continuación, una ruta normal de Unix separada por barras. Por ejemplo:

  archivo de prueba netcp.txt Cory:/usr/pascal/sh

copiaría el archivo testfile.txt a la ruta /usr/pascal/sh en la máquina Cory . ^[9]

De la misma manera, la aplicación de correo existente fue modificada para que entendiera el mismo esquema de direcciones y fue respaldada por la utilidad mmail , que agregó automáticamente encabezados para indicar dónde se originó el mensaje. En el lado de recepción, la nueva aplicación netmail usa net para iniciar sesión en una máquina remota nombrada y leer cualquier correo que encuentre allí. Cuando esto se completa, prmail copia los mensajes en el correo local del usuario , donde pueden leerse y responderse de manera normal. La automatización de estas tareas separadas se introdujo rápidamente. ^[10]

El protocolo de transferencia subyacente se organizó en tres capas. La superior era el protocolo de comandos, que definía la estructura general del archivo; debajo de este se encontraba el protocolo de flujo, que dividía el archivo en múltiples paquetes, y en la parte inferior se encontraba la capa de hardware que utilizaba los puertos seriales . ^[11]

La capa de comandos consistía principalmente en un formato de archivo que comenzaba con un indicador de longitud, seguido de un encabezado, un comando para ejecutar en la máquina remota y luego los datos necesarios. El comando net ensamblaba los archivos, anteponía el indicador de longitud y luego colocaba el archivo resultante en la cola adecuada. El encabezado contiene los nombres de las máquinas de origen y destino, los nombres de inicio de sesión para usar en ambas, un número de versión, marcas de tiempo y luego el "pseudocomando". Los datos del encabezado se escriben como texto ASCII normal con los campos separados por dos puntos. ^[11]

Durante una transferencia, el archivo se divide en paquetes para fines de corrección de errores . Los paquetes tienen un encabezado que consiste en un byte de longitud que permite hasta 255 bytes en un paquete, seguido de un número de paquete de dos bytes, un indicador de tipo de un byte, una suma de comprobación de un byte y luego los datos. ^[11] La suma de comprobación se coloca al frente porque los paquetes tienen una longitud variable y esto simplifica el código. Hay varios tipos de paquetes, que contienen información de comando o datos. Entre ellos se encuentra el paquete "reset", que indica el inicio de una nueva transferencia desde una máquina remota. El protocolo era muy similar a XMODEM en complejidad, carecía de ventanas deslizantes o reconocimiento de transmisión, características que se consideraron importantes para agregar en versiones futuras. ^[12]

A nivel de hardware, el sistema era simplemente un puerto serie que conectaba dos máquinas. Sin embargo, los sistemas Unix existentes no podían procesar directamente datos ASCII de 8 bits sin una sobrecarga considerable, por lo que los datos que se enviaban se codificaban con tres bytes de 8 bits empaquetados en cuatro caracteres de 6 bits en el rango imprimible. Esto introduce una sobrecarga del 33%, que también se consideró un área importante para una posible mejora. ^[12]

• Schmidt, Eric (1983) [1979]. "La red Berkeley: una retrospectiva" (PDF) . Manual del programador de UNIX, 4.2 Berkeley Software Distribution, volumen 2c .