UUCP ( Copia Unix-to-Unix ) [1] es un conjunto de programas y protocolos informáticos que permiten la ejecución remota de comandos y la transferencia de archivos , correo electrónico y noticias de red entre computadoras .
Un comando nombrado uucpes uno de los programas de la suite; proporciona una interfaz de usuario para solicitar operaciones de copia de archivos. La suite UUCP también incluye uux(interfaz de usuario para la ejecución remota de comandos), uucico(el programa de comunicación que realiza las transferencias de archivos), uustat(informa estadísticas sobre la actividad reciente), uuxqt(ejecuta comandos enviados desde máquinas remotas) y uuname(informa el nombre UUCP del sistema local). Algunas versiones de la suite incluyen uuencode/ uudecode(convierte archivos binarios de 8 bits a formato de texto de 7 bits y viceversa).
Aunque UUCP se desarrolló originalmente en Unix en las décadas de 1970 y 1980, y está más estrechamente asociado con sistemas similares a Unix , existen implementaciones de UUCP para varios sistemas operativos no similares a Unix, incluidos DOS , OS/2 , OpenVMS (solo para hardware VAX). ), AmigaOS , [2] Mac OS clásico e incluso CP/M .
UUCP fue escrito originalmente en AT&T Bell Laboratories por Mike Lesk . [3] En 1978 estaba en uso en 82 máquinas UNIX dentro del sistema Bell, principalmente para distribución de software. Fue lanzado en 1979 como parte de la Versión 7 de Unix . [4]
Los primeros correos electrónicos UUCP de EE. UU. llegaron al Reino Unido en 1979 y el correo electrónico entre el Reino Unido, los Países Bajos y Dinamarca comenzó en 1980, convirtiéndose en un servicio regular a través de EUnet en 1982. [5] [6]
El UUCP original fue reescrito por los investigadores de AT&T Peter Honeyman, David A. Nowitz y Brian E. Redman alrededor de 1983. La reescritura se conoce como HDB o HoneyDanBer uucp, que luego fue mejorada, corregida de errores y reempaquetada como BNU UUCP (" Utilidades básicas de red"). [7]
Cada una de estas versiones se distribuyó como software propietario, lo que inspiró a Ian Lance Taylor a escribir una nueva versión de software libre desde cero en 1991. [8] Taylor UUCP fue lanzado bajo la Licencia Pública General GNU . Taylor UUCP solucionó los agujeros de seguridad que permitían a algunos de los gusanos de red originales ejecutar de forma remota comandos de shell inesperados. Taylor UUCP también incorporó características de todas las versiones anteriores de UUCP, lo que le permite comunicarse con cualquier otra versión e incluso utilizar formatos de archivos de configuración similares de otras versiones.
UUCP también se implementó para sistemas operativos que no son UNIX , sobre todo sistemas DOS . Paquetes como UUSLAVE/GNUUCP ( John Gilmore , Garry Paxinos, Tim Pozar), UUPC/extended (Drew Derbyshire de Kendra Electronic Wonderworks) y FSUUCP (Christopher Ambler de IODesign), trajeron la conectividad temprana de Internet a las computadoras personales, expandiendo la red más allá del Sistemas universitarios interconectados. FSUUCP formó la base para muchos paquetes de sistemas de tablón de anuncios (BBS), como Major BBS de Galacticomm y Wildcat de Mustang Software . BBS para conectarse a la red UUCP e intercambiar correo electrónico y tráfico de Usenet . Como ejemplo, UFGATE (John Galvin, Garry Paxinos, Tim Pozar) era un paquete que proporcionaba una puerta de enlace entre redes que ejecutaban protocolos Fidonet y UUCP.
FSUUCP fue la única otra implementación del protocolo 'i' mejorado de Taylor, una mejora significativa con respecto al protocolo 'g' estándar utilizado por la mayoría de las implementaciones UUCP. [ cita necesaria ]
Antes de la disponibilidad generalizada del acceso a Internet , las computadoras solo estaban conectadas mediante redes de área local más pequeñas dentro de una empresa u organización. A menudo también estaban equipados con módems para poder utilizarlos de forma remota desde terminales en modo de caracteres a través de líneas telefónicas de acceso telefónico . UUCP utilizó los módems de las computadoras para marcar a otras computadoras, estableciendo enlaces temporales punto a punto entre ellas. Cada sistema en una red UUCP tiene una lista de sistemas vecinos, con números de teléfono, nombres de inicio de sesión y contraseñas, etc. Cuando el trabajo (transferencia de archivos o solicitudes de ejecución de comandos) está en cola para un sistema vecino, el programa normalmente llama a ese sistema para procesar el trabajar. El programa también puede sondear periódicamente a sus vecinos para comprobar si hay trabajos en cola de su lado; esto permite que participen los vecinos sin capacidad de llamadas salientes.uucicouucico
Con el tiempo, los enlaces de acceso telefónico fueron reemplazados por conexiones a Internet y UUCP agregó una serie de nuevos protocolos de capa de enlace . Estas nuevas conexiones también redujeron la necesidad de UUCP, ya que se desarrollaron nuevos protocolos de aplicación para aprovechar las nuevas redes. Hoy en día, UUCP rara vez se utiliza en enlaces de acceso telefónico, pero ocasionalmente se utiliza en TCP/IP . [9] [10] El número de sistemas implicados, a principios de 2006, funcionaba entre 1.500 y 2.000 sitios en 60 empresas. La longevidad de UUCP se puede atribuir a su bajo costo, registro extenso, conmutación por error nativa para acceso telefónico y administración de colas persistentes.
UUCP normalmente se inicia haciendo que un usuario inicie sesión en el sistema de destino y luego ejecute el programa UUCP. En la mayoría de los casos, esto se automatiza iniciando sesión en una cuenta de usuario conocida utilizada para transferencias, cuyo shell de cuenta se ha configurado en uucico. Por lo tanto, para transferencias automáticas, otra máquina simplemente tiene que abrir una conexión de módem a la máquina llamada e iniciar sesión en la cuenta conocida.
Cuando se ejecuta uucico, esperará recibir comandos de otro programa UUCP en la máquina de la persona que llama e iniciar una sesión. La sesión tiene tres etapas diferenciadas:
Al iniciar, uucico responderá enviando una cadena de identificación, donde \20 es el carácter de control-P y \0 es un nulo final. El UUCP de la persona que llama responde con , donde opciones es una cadena que contiene cero o más opciones tipo Unix. Estos pueden incluir tamaños de paquetes y ventanas, el tamaño máximo de archivo admitido, opciones de depuración y otros.\20Shere=hostname\0\20Scallername options\0
Dependiendo de la configuración de los dos sistemas, la llamada puede finalizar aquí. Por ejemplo, cuando la persona que llama responde con el nombre de su sistema, el sistema llamado puede colgar opcionalmente si no reconoce a la persona que llama, enviando la RYou are unknown to me\0cadena de respuesta y luego desconectándose.
Si los dos sistemas se conectan con éxito, la persona que llama ahora comenzará a enviar una serie de solicitudes de archivos. Hay cuatro tipos:
Después de enviar un comando H, el sistema que llama envía un paquete final \20OOOOOO\0(control-P, seis ohs, terminador nulo) y el sistema llamado responde con \20OOOOOO\0(control-P, siete ohs, terminador nulo). Algunos sistemas simplemente colgarán al recibir exitosamente el comando H y no se molestarán con el apretón de manos final.
Dentro del conjunto de protocolos de UUCP, el protocolo g subyacente es responsable de transferir información sin errores. El protocolo se originó como un sistema de propósito general para la entrega de paquetes y, por lo tanto, ofrece una serie de características que no utiliza el paquete UUCP en su conjunto. Estos incluyen un canal secundario que puede enviar datos de comando intercalados con una transferencia de archivos y la capacidad de renegociar los tamaños de paquete y ventana durante la transmisión. Es posible que estas funciones adicionales no estén disponibles en algunas implementaciones de la pila UUCP. [11]
El formato del paquete constaba de un encabezado de 6 bytes y luego entre cero y 4096 bytes en la carga útil. El paquete comienza con un único \020 (control-P). A esto le sigue un único byte, conocido como "K", que contiene un valor de 1 a 8 que indica un tamaño de paquete de 32 a 4096 bytes, o un 9 que indica un paquete de control. Muchos sistemas sólo admitían K=2, es decir, 64 bytes. Los dos bytes siguientes eran una suma de comprobación de 16 bits de la carga útil, sin incluir el encabezado. El siguiente byte es el tipo de datos y, finalmente, el último byte es el XOR del encabezado, lo que permite verificarlo por separado de la carga útil. [11]
El byte de control consta de tres campos de bits con el formato TTXXXYYY. TT es el tipo de paquete, 0 para paquetes de control (que también requiere que K=9 sea válido), 1 para datos alternativos (no utilizados en UUCP), 2 para datos y 3 indica un paquete corto que redefine el significado de K. En un paquete de datos, XXX es el número de paquete para este paquete del 0 al 7, y YYY es el último que se recibió correctamente. Esto proporciona hasta 8 paquetes en una ventana. En un paquete de control, XXX indica el comando y YYY se utiliza para varios parámetros. Por ejemplo, las transferencias se inician enviando un paquete de control corto con TT=0 (control), XXX=7 e YYY el número de paquetes en una ventana, luego enviando otro paquete con XXX=6 e YYY como la longitud del paquete (codificado como estaría en K) y luego un tercer paquete que es idéntico al primero pero XXX=5. [11]
El protocolo g utiliza un sistema de ventana deslizante simple para lidiar con latencias potencialmente largas entre puntos finales. El protocolo permite que los paquetes tengan un tamaño de 64 a 4096 bytes de 8 bits y ventanas que incluyan de 1 a 7 paquetes. En teoría, un sistema que utilice paquetes de 4k y ventanas de 7 paquetes (4096x7) ofrecería un rendimiento equivalente o superior a los mejores protocolos de transferencia de archivos como ZMODEM . En la práctica, muchas implementaciones solo admitían una configuración única de 64x3. Como resultado, el protocolo g tiene una reputación inmerecida por su bajo rendimiento. La confusión sobre los tamaños de paquetes y ventanas llevó al protocolo G, que se diferenciaba únicamente en que siempre usaba 4096x3. Taylor UUCP no admitía G, pero sí admitía cualquier ventana o tamaño de paquete solicitado válido, por lo que los sistemas remotos que iniciaban G funcionarían bien con el g de Taylor, mientras que dos sistemas Taylor podrían negociar conexiones aún más rápidas. [11]
Los módems Telebit utilizaron la suplantación de protocolo para mejorar el rendimiento de las transferencias del protocolo g al detectar marcadores de fin de paquete que se envían al sistema remoto y enviar inmediatamente un mensaje ACKde vuelta al host local, pretendiendo que el sistema remoto ya había recibido el paquete y lo había decodificado. correctamente. Esto provocó que la pila de software enviara el siguiente paquete, tan rápidamente que la transferencia se volvió casi continua. Los datos entre los dos módems se corrigieron mediante un protocolo propietario basado en MNP que se ejecutaba en las conexiones semidúplex de Telebit mucho mejor que el protocolo g normalmente, [11] porque en el caso común de 64x3 el sistema remoto estaría enviando un flujo constante de ACKs que desbordaría el canal de retorno de baja velocidad. Combinados con las velocidades de datos naturalmente más altas del módem, mejoraron enormemente el rendimiento general y, en general, alcanzaron una velocidad siete veces mayor que la de un módem de 2400 bit/s. [12] Fueron ampliamente utilizados en hosts UUCP ya que podían amortizarse rápidamente con cargos reducidos de larga distancia.
Las implementaciones de UUCP también incluyen otros protocolos de transferencia para su uso en ciertos enlaces.
El protocolo f está diseñado para ejecutarse en enlaces de 7 bits con corrección de errores. Originalmente estaba pensado para su uso en enlaces X.25 , que fueron populares durante un tiempo en la década de 1980. No empaqueta datos; en cambio, el archivo completo se envía como una única cadena larga seguida de una suma de verificación de todo el archivo. El protocolo x similar parece haber tenido poca o ninguna utilidad. El protocolo d era similar a x, pero estaba destinado a usarse en redes Datakit que conectaban muchas de las oficinas de Bell Labs . [11]
El protocolo t se originó en las versiones BSD de UUCP y, al igual que algunos similares, está diseñado para ejecutarse en enlaces TCP/IP de 8 bits sin errores . No tiene ninguna corrección de errores y el protocolo consiste simplemente en dividir los datos de archivos y comandos en paquetes de 512 o 1024 bytes para que quepan fácilmente dentro de las tramas TCP típicas.
El protocolo electrónico ("e" para Ethernet) fue desarrollado por Clem Cole en MASSCOMP y Brian Redman lo lanzó ampliamente en las versiones posteriores de HoneyDanBer. Fue desarrollado y lanzado antes del protocolo t, pero el protocolo t se usaba más comúnmente porque la versión BSD de UUCP era la implementación dominante. El protocolo e se diferencia del protocolo t sólo en que los comandos no se empaquetan y, en cambio, se envían como cadenas normales, mientras que los archivos se rellenan hasta los 20 bytes más cercanos. [11] [13]
Las capacidades uucpy uuxqtpodrían usarse para enviar correo electrónico entre máquinas, con interfaces de usuario de correo y programas de agentes de entrega adecuados. Una dirección de correo UUCP simple se formaba a partir del nombre de la máquina adyacente, un signo de exclamación (a menudo pronunciado bang ), seguido del nombre de usuario en la máquina adyacente. Por ejemplo, la dirección barbox!user se referiría al usuario usuario en la máquina adyacente barbox . [14]
Además, el correo podría encaminarse a través de la red, atravesando cualquier número de nodos intermedios antes de llegar a su destino. Inicialmente, esto tenía que hacerse especificando la ruta completa, con una lista de nombres de host intermedios separados por bangs. Por ejemplo, si la máquina barbox no está conectada a la máquina local, pero se sabe que barbox está conectada a la máquina foovax que sí se comunica con la máquina local, la dirección apropiada para enviar correo sería foovax!barbox!user .
El usuario barbox!user generalmente publicaría su dirección de correo electrónico UUCP en un formulario como …!bigsite!foovax!barbox!user . Esto dirige a las personas a enrutar su correo a la máquina bigsite (presumiblemente una máquina bien conocida y bien conectada accesible para todos) y desde allí a través de la máquina foovax a la cuenta del usuario en barbox . Publicar una ruta completa no tendría sentido, porque sería diferente dependiendo de dónde estuviera el remitente. (por ejemplo, Ann en un sitio puede tener que enviar a través de la ruta gway!tcol!canty!uoh!bigsite!foovax!barbox!user , mientras que desde otro lugar, Bill tiene que enviar a través de la ruta pdp10!router22!bigsite!foovax!barbox! usuario ). Muchos usuarios sugerirían múltiples rutas desde varios sitios importantes y conocidos, proporcionando un servicio de conexión aún mejor y quizás más rápido por parte del remitente del correo.
Una dirección de correo electrónico de este tipo se conocía como ruta bang . Las rutas de explosión de ocho a diez máquinas (o saltos ) no eran infrecuentes en 1981, y los enlaces UUCP de acceso telefónico nocturno podían provocar tiempos de transmisión de una semana de duración. Las rutas de explosión a menudo se seleccionaban tanto por el tiempo de transmisión como por la confiabilidad, ya que los mensajes a menudo se perdían. Algunos anfitriones llegaron incluso a intentar " reescribir " la ruta, enviando correo a través de rutas "más rápidas"; esta práctica solía estar mal vista.
La terminación de "pseudodominio" .uucp se usaba a veces para designar un nombre de host al que podían acceder las redes UUCP, aunque nunca se registró formalmente en el sistema de nombres de dominio (DNS) como dominio de nivel superior . La comunidad uucp se administraba a sí misma y no encajaba bien con los métodos de administración y las regulaciones que rigen el DNS; .uucp funciona donde necesita [ ¿dónde? ] ; algunos anfitriones [ ¿cuáles? ] saca el correo de la cola SMTP a las colas uucp en las máquinas de puerta de enlace si se reconoce una dirección .uucp en una conexión SMTP entrante. [ cita necesaria ]
El tráfico de Usenet se transmitía originalmente a través del protocolo UUCP utilizando rutas bang. Estos todavía están en uso dentro de las líneas de encabezado de ruta del formato de mensaje de Usenet . Ahora tienen sólo un propósito informativo y no se utilizan para enrutamiento, aunque pueden usarse para garantizar que no se produzcan bucles.
En general, al igual que otros formatos de direcciones de correo electrónico más antiguos , las rutas bang ahora han sido reemplazadas por la notación "@ ", incluso en sitios que todavía usan UUCP. Un sitio solo UUCP puede registrar un nombre de dominio DNS y hacer que el servidor DNS que maneja ese dominio proporcione registros MX que hacen que el correo de Internet a ese sitio se entregue a un host UUCP en Internet que luego puede entregar el correo al UUCP. sitio.
UUCPNET era el nombre para la totalidad de la red de computadoras conectadas a través de UUCP. Esta red era muy informal y se mantenía con un espíritu de cooperación mutua entre sistemas propiedad de miles de empresas privadas, universidades, etc. A menudo, particularmente en el sector privado, los vínculos UUCP se establecieron sin la aprobación oficial de la alta dirección de las empresas. La red UUCP cambiaba constantemente a medida que se agregaban nuevos sistemas y enlaces de acceso telefónico, se eliminaban otros, etc.
El Proyecto de Mapeo UUCP fue un esfuerzo voluntario, en gran medida exitoso, para construir un mapa de las conexiones entre máquinas que eran retransmisiones de correo abiertas y establecer un espacio de nombres administrado. Cada administrador del sistema enviaría, por correo electrónico, una lista de los sistemas a los que se conectaría, junto con una clasificación para cada conexión. Estas entradas de mapas enviadas fueron procesadas por un programa automático que las combinó en un único conjunto de archivos que describían todas las conexiones en la red. Estos archivos luego se publicaban mensualmente en un grupo de noticias dedicado a este fin. Los archivos de mapas UUCP podrían luego ser utilizados por software como "pathalias" para calcular la mejor ruta de una máquina a otra para el correo y proporcionar esta ruta automáticamente. Los mapas de UUCP también incluían información de contacto de los sitios, por lo que brindaron a los sitios que buscaban unirse a UUCPNET una manera fácil de encontrar posibles vecinos.
Muchos hosts UUCP, particularmente los de las universidades, también estaban conectados a Internet en sus primeros años, y se desarrollaron puertas de enlace de correo electrónico entre el correo basado en SMTP de Internet y el correo UUCP. De este modo, un usuario de un sistema con conexiones UUCP podría intercambiar correo con usuarios de Internet, y los enlaces de Internet podrían utilizarse para evitar grandes porciones de la lenta red UUCP. Se definió una "zona UUCP" dentro del espacio de nombres del dominio de Internet para facilitar estas interfaces.
Con esta infraestructura implementada, la fortaleza de UUCP fue que permitió que un sitio obtuviera correo electrónico de Internet y conectividad Usenet con solo un enlace de módem de acceso telefónico a otra computadora que cooperara. Esto fue en un momento en que el verdadero acceso a Internet requería una línea de datos alquilada que proporcionara una conexión a un Punto de Presencia de Internet , ambos costos y difíciles de conseguir. Por el contrario, normalmente se podría establecer un enlace a la red UUCP con unas pocas llamadas telefónicas a los administradores de los posibles sistemas vecinos. Los sistemas vecinos a menudo estaban lo suficientemente cerca como para evitar todos los cargos, excepto los más básicos, por las llamadas telefónicas.
uux es la ejecución remota de comandos a través de UUCP. El comando uux se utiliza para ejecutar un comando en un sistema remoto o para ejecutar un comando en el sistema local utilizando archivos de sistemas remotos. El comando lo ejecuta el uucicodemonio, que maneja las solicitudes de ejecución remota simplemente como otro tipo de archivo para enviar por lotes al sistema remoto siempre que haya un nodo de siguiente salto disponible. Luego, el sistema remoto ejecutará el comando solicitado y devolverá el resultado cuando el sistema original esté disponible. Ambas transferencias pueden ser indirectas, a través de rutas de múltiples saltos, con ventanas de disponibilidad arbitrarias. Incluso cuando se ejecuta un comando en un vecino siempre disponible, uux no es instantáneo.
El uso de UUCP comenzó a desaparecer con el aumento de proveedores de servicios de Internet que ofrecen servicios SLIP y PPP económicos . El Proyecto de Cartografía UUCP se cerró formalmente a finales de 2000.
El protocolo UUCP ahora ha sido reemplazado en su mayor parte por los protocolos de Internet basados en TCP/IP, SMTP para correo y NNTP para noticias de Usenet.
En julio de 2012, el proveedor de Internet holandés XS4ALL cerró su servicio UUCP, alegando que era "probablemente uno de los últimos proveedores del mundo que todavía lo ofrecía"; En ese momento sólo tenía 13 usuarios (antes de su cierre había rechazado solicitudes de nuevos usuarios durante varios años). [15]
Una característica que sobrevive de UUCP es el formato de archivo de chat, heredado en gran medida por el paquete de software Expect .
El UUCP se utilizaba en enlaces de alto coste para fines especiales (por ejemplo, enlaces marítimos por satélite) mucho después de su desaparición en otros lugares [16] y todavía se sigue utilizando. [ cita necesaria ] Además del uso heredado, en 2021 están creciendo los usos nuevos e innovadores de UUCP, especialmente para las telecomunicaciones en la banda HF , por ejemplo, para las comunidades de la selva amazónica para el intercambio de correo electrónico y otros usos. Se contribuyó con un parche para el UUCP de Ian al paquete UUCP Debian Linux [17] para adaptarlo al proyecto HERMES (Sistema de intercambio multimedia rural y de emergencia de alta frecuencia), que proporciona conectividad UUCP HF. [18]
A mediados de la década de 2000, se propuso UUCP sobre TCP/IP (a menudo cifrado, utilizando el protocolo SSH [10] ) [¿ según quién? ] para usar cuando una computadora no tiene direcciones IP fijas pero aún está dispuesta a ejecutar un agente de transferencia de correo (MTA) estándar como Sendmail o Postfix .
Las rutas tipo Bang todavía se utilizan dentro de la red Usenet , aunque no para enrutamiento; se utilizan para registrar, en el encabezado de un mensaje, los nodos a través de los cuales ha pasado ese mensaje, en lugar de indicar hacia dónde irá a continuación. [19] "Ruta de explosión" también se utiliza como expresión para cualquier ruta de enrutamiento especificada explícitamente entre hosts de red. Ese uso no se limita necesariamente a UUCP, enrutamiento IP, mensajería de correo electrónico o Usenet.
El concepto de protocolos de red tolerantes a retrasos se revisó a principios de la década de 2000. [20] Técnicas similares a las utilizadas por UUCP pueden aplicarse a otras redes que experimentan retrasos o interrupciones significativas.
El rendimiento real es de alrededor de 14400 bps.