Almacenar y reenviar comunicación: UUCP y FidoNet

En la década de 1980, Internet / ARPANET seguía siendo principalmente
una red de investigación que conectaba universidades y grandes empresas
centradas en computadoras. Gran parte de la actividad de las redes de
consumidores se centró en cambio en BBS (Bulletin Board Systems) de
marcado telefónico, al que se accede marcando con un módem, revisando
el correo electrónico o leyendo foros de mensajes, y luego
desconectando.

Los BBS eran originalmente comunidades independientes, pero a medida
que su popularidad se extendió, los operadores de BBS comenzaron a
buscar formas de compartir correos electrónicos y grupos de discusión
entre sistemas. Si bien surgieron varios métodos de intercambio
patentados, FidoNet emergió como la red global de intercambio de
archivos, correo electrónico y noticias más popular. En su apogeo,
participaron alrededor de 30.000 sistemas constituyentes.

FidoNet funcionó haciendo que los nodos se conectaran entre sí
periódicamente para enviar y recibir mensajes. Estos mensajes se
reenviaron de forma almacenada y reenviada a través de la fidonet hasta
que llegaron a su destino. Estas conexiones de acceso telefónico se
establecieron periódicamente (una o dos veces al día) para amortizar el
costo de las costosas comunicaciones telefónicas de larga distancia. La
conectividad telefónica de larga distancia era comparativamente cara:
alrededor de $ 0,25 por minuto en dólares de 2005, en comparación con
las tasas de descuento actuales de $ 0,05 por minuto o menos. Muchos
sistemas BBS funcionaban con una sola línea telefónica, lo que
significa que los usuarios no podían marcar al mismo tiempo que el BBS
estaba conectado al resto de la red.

Algo antes del desarrollo de FidoNet, el sistema UUCP ("Protocolo de
copia de Unix a Unix") fue desarrollado por Mike Lesk en AT&T. UUCP es
otro protocolo de distribución de archivo, comando, correo electrónico,
noticias, etc. de almacenamiento y reenvío que puede comunicarse a
través de conexiones de módem de acceso telefónico, conexiones
cableadas o Internet. Una de las principales características del
sistema UUCP inicial era el uso de enrutamiento explícito, conocido
como rutas UUCP "bang" (!). Las direcciones de correo electrónico se
parecían a duke! Research! Ucbvax! User @ mit-ai (es decir, envíe el
correo primero a duke, luego a su máquina de "investigación", luego a
la vax en Berkeley, luego a través de ARPANET a la inteligencia
artificial de user @ mit laboratorio).

Las ventajas de estas redes de almacenamiento y reenvío fue su
resistencia a la desconexión extrema. Tanto en fidonet como en UUCP,
los mensajes y archivos podrían avanzar a través del sistema en la
ausencia total de una ruta de trabajo de un extremo a otro entre el
nodo del remitente y el del receptor. Esto contrasta radicalmente con
la forma en que la mayoría de los sistemas de correo de Internet están
configurados en la actualidad, en los que el correo se entrega a través
de una conexión TCP directamente desde el nodo de correo del remitente
al nodo de correo del receptor. Sin embargo, hubo muchas desventajas:
el direccionamiento explícito en UUCP escalado deficientemente (ver el
artículo de pathalias) y era bastante poco amigable para el usuario.
Los nodos de FidoNet necesitaban tener una copia de toda la lista de
nodos para saber cómo comunicarse entre sí; ¡imagínese tratando de
escalar eso a los millones de hosts de envío de correo que existen en
la actualidad!

Hay pocos artículos que brinden una descripción general de este estilo
de comunicación y estos sistemas, por lo que las lecturas de esta
conferencia consisten en varios indicadores web sobre especificaciones
y artículos informales. Capas

Tanto UUCP como FidoNet sufren de un modelo de capas algo turbio y la
ausencia de una "cintura estrecha" como IP como una forma de fomentar
la extensibilidad. UUCP define una serie de protocolos subyacentes para
transferir datos; Estos protocolos proporcionan cosas como canales
corregidos de errores controlados por flujo basados ​​en paquetes (por
ejemplo, el protocolo UUCP 'g'). Varios protocolos están diseñados para
manejar enlaces semidúplex y dúplex completo con diferentes capacidades
para manejar datos limpios de ocho bits, control de flujo, etc. En
general, esta disposición de protocolo es complicada y varios de los
protocolos parecen inútiles.

FidoNet define, además de direccionamiento y enrutamiento, un protocolo
de capa de aplicación para direccionamiento de correo. FidoNet usó más
comúnmente el protocolo XMODEM para realizar transferencias de datos.
Nombrar FidoNet

FidoNet utiliza un esquema de direccionamiento geográficamente
jerárquico. Las direcciones constan de una zona, una red, un nodo y un
punto. La zona corresponde aproximadamente a un continente, y la Zona 1
representa a los EE. UU., Canadá y el Caribe. Una red es una región
geográfica dentro de una zona. Un nodo es un sistema que puede recibir
llamadas telefónicas. Un punto es un "subnodo" al que solo se puede
llegar a través de un nodo en particular.

Una dirección FidoNet parece 1: 512 / 666.0 en la zona 1, net 512, nodo
666.

UUCP

Cada host en UUCP tiene un nombre de host único a nivel mundial. La red
UUCP original constaba de hosts como ucbvax y mit-ai. Enrutamiento
FidoNet

El enrutamiento de FidoNet también se basó en la proximidad geográfica,
con el objetivo principal de reducir los cargos de larga distancia. La
forma estándar de enrutamiento era ir del nodo a un "concentrador" que
conectaba varios nodos, a un coordinador de región, a un coordinador de
zona, y luego retroceder por la jerarquía adecuada para llegar al
destinatario. El objetivo detrás de este enrutamiento era lograr el
máximo de lotes de mensajes para una mejor compresión y un uso más
eficiente del tiempo telefónico.

Cada sistema FidoNet debe mantener una lista de nodos que identifique a
todos los demás sistemas miembros. La lista de nodos se mantuvo de una
manera jerárquica similar, con los centros manteniendo la información
de membresía local, y así sucesivamente. UUCP

El enrutamiento en UUCP se realiza a través de una forma de
enrutamiento de origen, lo que lleva al bang-path de UUCP: "foo! Bar!
Ucbvax! User". Con el tiempo, a medida que crecía la complejidad de la
red, este direccionamiento se volvió extremadamente inconveniente para
los usuarios. Sin embargo, tenga en cuenta que en algunas vistas del
mundo, los nombres de host de UUCP son absolutos, no relativos: foo!
Bar! Ucbvax! User especifica exactamente el mismo usuario que ucbvax!
User. Por lo tanto, es posible separar el identificador visible para
humanos del cálculo de la ruta. Esta distinción tiene claros
inconvenientes en cuanto a que requiere una coordinación global antes
de poder conectarse a la red UUCP. El debate absoluto versus relativo
se prolongó durante varios años, antes de que el direccionamiento UUCP
fuera borrado por el direccionamiento al estilo de Internet.

Como muchas formas de enrutamiento de origen puro, el uso de pathalias
requería que todos los hosts tuvieran un mapa actualizado de la red, o
al menos la mayor parte de la red con la que quisieran hablar.
Planificación

FidoNet maneja la programación requiriendo que los nodos estén
disponibles para transferencias Fido durante la "Hora del correo de
zona". La mayoría de los sistemas aceptarían correo en otros momentos,
pero el tiempo reservado garantizaba que, independientemente de la
actividad del usuario, los nodos pudieran transmitir y aceptar tráfico
de red.

La red UUCP especificó la programación solo por pares. Las
configuraciones de los nodos individuales podían especificar cuándo
intentar llamar a un vecino en particular, pero no había coordinación
global. En general, UUCP se usó en hosts con conexiones más ricas.
Construcción de servicios de nivel superior UUCP es un protocolo
genérico de ejecución de comandos y copia de archivos. Para ejecutar
comandos, copia en un archivo 'X. *', que es un archivo de texto que le
dice al sistema remoto qué ejecutar. El archivo 'X' puede hacer
referencia a otro archivo que también se copió en el sistema remoto. El
correo, por ejemplo, se maneja emitiendo una ejecución remota para el
comando rmail. UUCP "moderno"

UUCP todavía se utiliza, aunque cada vez con menos frecuencia, en
Internet de hoy. Su utilidad principal es permitir que un dominio que
está frecuentemente fuera de línea maneje su propio correo electrónico.
En este modelo, UUCP se usa principalmente para conectar una sola red
de stub a un núcleo bien conectado.

{Internet} ---- {Puerta de enlace} - | uucp | --- talón

En esta configuración, el dominio example.com tendría su DNS alojado en
su puerta de enlace ISP. La puerta de enlace publicaría un registro MX
para example.com apuntando al propio servidor de correo de la puerta de
enlace. El servidor de correo estaría configurado para retransmitir
correo a example.com a través de UUCP. El servidor de correo UUCP de
Example iniciaría sesión en la puerta de enlace periódicamente y
descargaría todo su correo electrónico en cola, y cargaría cualquier
mensaje que necesitara enviar.

Esta funcionalidad está disponible de una manera algo menos robusta
usando el comando ETRN (relativamente) nuevo en sendmail, que hace que
un servidor de correo comience a enviar correo en cola.
Direccionamiento, denominación y enrutamiento

Las direcciones de correo electrónico al estilo UUCP originalmente
combinaban direcciones, nombres y enrutamiento, todo en uno, lo que
conducía a direcciones de correo electrónico desafortunadas que eran
tanto complejas (¡hosta! Hostb! Hostc! Usuario) como relativas al
remitente (por ejemplo, otra persona podría ver esa dirección como
hostx ! hosty! hostc! usuario).

La aparición de pathalias redujo esta restricción, transformando las
direcciones de correo electrónico de UUCP en una combinación de
dirección de usuario y host (hostc! Usuario), dejando que el programa
de correo calcule la ruta al destino. Las direcciones FidoNet también
entran en esta categoría, por ejemplo, un usuario en el host 1: 170 /
918.42.

Las direcciones de Internet, por el contrario, agregan otra capa de
direccionamiento indirecto, enviando correo al usuario @ dominio. En
este caso, el dominio es un nombre, no una dirección; no tiene
importancia topológica, pero es amigable para los humanos. Mediante una
búsqueda en el DNS, el dominio se resuelve en una dirección y el correo
se envía directamente a esa dirección. Mientras tanto, los cálculos de
enrutamiento ocurren en una capa muy por debajo de la transferencia de
correo.

En general, muchas de las características "feas" de UUCP y FidoNet
tienen poco que ver con su funcionamiento como redes de almacenamiento
y reenvío, pero tienen más que ver con varios problemas arquitectónicos
(p. Ej., Rutas explosivas) que finalmente se eliminaron de su Primos de
Internet. Algunas de estas abstracciones más limpias, como una mejor
separación de nomenclatura, direccionamiento y enrutamiento, se ven
facilitadas por la noción de un núcleo constantemente bien conectado,
pero de ninguna manera dependen de él. Por ejemplo, un ejercicio
interesante sería diseñar un sistema de mensajería de almacenamiento y
reenvío que se ejecute sobre los protocolos de Internet, no asuma una
conectividad constante, pero que aún permita una denominación indirecta
y amigable para los humanos que abstraiga la identidad de la topología.