UUCP ( Unix-to-Unix Copy ) [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 Internet entre ordenadores .
Un comando llamado 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) e 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 los años 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, ya se utilizaba 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, se corrigieron errores y se volvió a empaquetar como BNU UUCP ("Basic Network Utilities"). [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 se publicó bajo la Licencia Pública General GNU . Taylor UUCP solucionó los agujeros de seguridad que permitían que algunos de los gusanos de red originales ejecutaran de forma remota comandos de shell inesperados. Taylor UUCP también incorporó características de todas las versiones anteriores de UUCP, lo que le permitió comunicarse con cualquier otra versión e incluso utilizar formatos de archivo de configuración similares a los de otras versiones.
UUCP también se implementó para sistemas operativos no UNIX , especialmente 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 a Internet a las computadoras personales, expandiendo la red más allá de los 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! BBS de Mustang Software 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) fue un paquete que proporcionó una puerta de enlace entre redes que ejecutaban los protocolos Fidonet y UUCP.
FSUUCP fue la única otra implementación del protocolo 'i' mejorado de Taylor, una mejora significativa sobre el protocolo 'g' estándar utilizado por la mayoría de las implementaciones de UUCP. [ cita requerida ]
Antes de la amplia disponibilidad del acceso a Internet , las computadoras solo estaban conectadas por redes de área local más pequeñas dentro de una empresa u organización. También solían estar equipadas con módems para que pudieran usarse de forma remota desde terminales en modo carácter a través de líneas telefónicas de acceso telefónico . UUCP usaba los módems de las computadoras para llamar 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) se pone en cola para un sistema vecino, el programa generalmente llama a ese sistema para procesar el trabajo. El programa también puede sondear a sus vecinos periódicamente para verificar si hay trabajo en cola en su lado; esto permite que los vecinos sin capacidad de acceso telefónico participen.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 conexiones más nuevas también redujeron la necesidad de UUCP, ya que se desarrollaron protocolos de aplicación más nuevos para aprovechar las nuevas redes. Hoy en día, UUCP rara vez se utiliza en enlaces de acceso telefónico, pero ocasionalmente se usa en TCP/IP . [9] [10] La cantidad de sistemas involucrados, a principios de 2006, operaba entre 1500 y 2000 sitios en 60 empresas. La longevidad de UUCP se puede atribuir a su bajo costo, amplio registro, conmutación por error nativa a acceso telefónico y administración de colas persistente.
UUCP normalmente se inicia cuando un usuario inicia sesión en el sistema de destino y luego ejecuta el programa UUCP. En la mayoría de los casos, esto se automatiza iniciando sesión en una cuenta de usuario conocida que se utiliza para transferencias, cuyo shell de cuenta se ha configurado como uucico. Por lo tanto, para las transferencias automatizadas, 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 del autor de la llamada y comenzará una sesión. La sesión tiene tres etapas distintas:
Al iniciarse, uucico responderá enviando una cadena de identificación, , donde \20 es el carácter de control-P y \0 es un valor nulo final. El UUCP del llamador responde con , donde options es una cadena que contiene cero o más opciones de conmutación similares a Unix. Estas pueden incluir tamaños de paquetes y ventanas, el tamaño máximo de archivo admitido, opciones de depuración y otras.\20Shere=hostname\0\20Scallername options\0
Según la configuración de los dos sistemas, la llamada puede finalizar aquí. Por ejemplo, cuando el interlocutor responde con el nombre de su sistema, el sistema al que se llama puede colgar opcionalmente si no reconoce al interlocutor, enviar la RYou are unknown to me\0cadena de respuesta y luego desconectarse.
Si los dos sistemas se conectan correctamente, el interlocutor 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, terminación nula) y el sistema llamado responde con \20OOOOOO\0(control-P, siete ohs, terminación nula). Algunos sistemas simplemente cuelgan tras la recepción exitosa del comando H y no se molestan en realizar el protocolo de enlace final.
Dentro del conjunto de protocolos de UUCP, el protocolo g subyacente es responsable de transferir información de forma libre de 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 son utilizadas por el paquete UUCP en su conjunto. Estas incluyen un canal secundario que puede enviar datos de comandos intercalados con una transferencia de archivos y la capacidad de renegociar los tamaños de los paquetes y las ventanas durante la transmisión. Estas características adicionales pueden no estar 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 solo \020 (control-P). A esto le sigue un solo 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 solo 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 comprobarlo por separado de la carga útil. [11]
El byte de control consta de tres campos de bits en el formato TTXXXYYY. TT es el tipo de paquete, 0 para paquetes de control (que también requieren K=9 para ser válidos), 1 para datos alternativos (no se utilizan 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 de 0 a 7, e 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 e 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 que igualaría o superaría a los mejores protocolos de transferencia de archivos como ZMODEM . En la práctica, muchas implementaciones solo admitían una única configuración de 64x3. Como resultado, el protocolo g tiene una reputación inmerecida de bajo rendimiento. La confusión sobre los tamaños de paquetes y ventanas condujo al protocolo G, que solo se diferenciaba en que siempre usaba 4096x3. El UUCP de Taylor no admitía G, pero sí admitía cualquier tamaño de paquete o ventana solicitado válido, por lo que los sistemas remotos que iniciaran 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 utilizaban la suplantación de protocolo para mejorar el rendimiento de las transferencias del protocolo g, detectando los marcadores de fin de paquete que se enviaban al sistema remoto y enviando inmediatamente un ACKmensaje de vuelta al host local, simulando que el sistema remoto ya había recibido el paquete y lo había decodificado correctamente. Esto activaba la pila de software para enviar el siguiente paquete, tan rápidamente que la transferencia se volvía casi continua. Los datos entre los dos módems se corregían en caso de error utilizando un protocolo propietario basado en MNP que se ejecutaba sobre las conexiones half-duplex de Telebit mucho mejor de lo que lo haría normalmente el protocolo g, [11] porque en el caso común de 64x3 el sistema remoto estaría enviando un flujo constante de ACKmensajes que desbordarían 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, funcionaban aproximadamente siete veces la velocidad de un módem de 2400 bit/s. [12] Se usaban ampliamente 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 funcionar en enlaces de 7 bits con corrección de errores. En un principio, estaba pensado para usarse en enlaces X.25 , que fueron populares durante un tiempo en la década de 1980. No empaqueta los datos, sino que envía el archivo completo como una única cadena larga seguida de una suma de comprobación de todo el archivo. El protocolo x, que es similar, parece haber tenido poco o ningún uso. El protocolo d era similar a x, pero estaba pensado para 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, como algunos similares, está diseñado para funcionar en enlaces TCP/IP de 8 bits sin errores . No tiene corrección de errores y el protocolo consiste simplemente en dividir los datos de comandos y archivos en paquetes de 512 o 1024 bytes para que quepan fácilmente en los marcos TCP típicos.
El protocolo e ("e" de Ethernet) fue desarrollado por Clem Cole en MASSCOMP y fue ampliamente distribuido por Brian Redman en las versiones posteriores de HoneyDanBer. Fue desarrollado y distribuido antes que el protocolo t, pero el protocolo t se usó más comúnmente porque la versión BSD de UUCP era la implementación dominante. El protocolo e difiere del protocolo t solo en que los comandos no están empaquetados y en su lugar se envían como cadenas normales, mientras que los archivos se rellenan hasta los 20 bytes más cercanos. [11] [13]
Las capacidades uucpy uuxqtse podrían utilizar para enviar correo electrónico entre máquinas, con interfaces de usuario de correo adecuadas y programas de agente de entrega. Se formó una dirección de correo UUCP simple a partir del nombre de la máquina adyacente, un signo de exclamación (que a menudo se pronuncia bang ), seguido del nombre de usuario en la máquina adyacente. Por ejemplo, la dirección barbox!user haría referencia al usuario user en la máquina adyacente barbox . [14]
Además, el correo podría enrutarse 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 signos de exclamación. 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 a la que enviar el correo sería foovax!barbox!user .
El usuario barbox!user generalmente publicaría su dirección de correo electrónico UUCP en un formato 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 user 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 algún otro lugar, Bill tiene que enviar a través de la ruta pdp10!router22!bigsite!foovax!barbox!user ). Muchos usuarios sugerirían múltiples rutas desde varios sitios grandes y conocidos, proporcionando un servicio de conexión incluso mejor y quizás más rápido desde el remitente del correo.
Una dirección de correo electrónico de este formato se conocía como ruta bang . Las rutas bang de ocho a diez máquinas (o saltos ) no eran poco comunes en 1981, y los enlaces UUCP de acceso telefónico nocturno podían causar tiempos de transmisión de una semana. Las rutas bang se seleccionaban a menudo tanto por el tiempo de transmisión como por la confiabilidad, ya que los mensajes se perdían con frecuencia. Algunos hosts llegaron al extremo de intentar " reescribir " la ruta, enviando correo a través de rutas "más rápidas", una práctica que tendía a ser mal vista.
La terminación de "pseudodominio" .uucp se utilizó a veces para designar un nombre de host como accesible mediante redes UUCP, aunque nunca se registró formalmente en el sistema de nombres de dominio (DNS) como un 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 regían el DNS; .uucp funciona donde debe hacerlo [ ¿dónde? ] ; algunos hosts [ ¿cuáles? ] envían correo desde la cola SMTP a las colas uucp en las máquinas de enlace si se reconoce una dirección .uucp en una conexión SMTP entrante. [ cita requerida ]
El tráfico de Usenet se transmitía originalmente a través del protocolo UUCP utilizando rutas de bang. Estas rutas todavía se utilizan en las líneas de encabezado Path del formato de mensajes de Usenet . Actualmente tienen un propósito meramente informativo y no se utilizan para el enrutamiento, aunque se pueden utilizar 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 de bang han sido reemplazadas por la notación "@ ", incluso por sitios que aún utilizan UUCP. Un sitio que sólo utiliza UUCP puede registrar un nombre de dominio DNS y hacer que el servidor DNS que maneja ese dominio proporcione registros MX que hagan que el correo de Internet a ese sitio se envíe a un host UUCP en Internet que luego puede enviar el correo al sitio UUCP.
UUCPNET era el nombre que se le daba a la totalidad de la red de computadoras conectadas a través de UUCP. Esta red era muy informal, mantenida en un espíritu de cooperación mutua entre sistemas propiedad de miles de empresas privadas, universidades, etc. A menudo, sobre todo en el sector privado, los enlaces UUCP se establecían sin la aprobación oficial de la alta dirección de las empresas. La red UUCP cambiaba constantemente a medida que se añadían 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 retransmisores de correo abiertos y establecer un espacio de nombres administrado. Cada administrador de sistema enviaba, por correo electrónico, una lista de los sistemas a los que se conectaría el suyo, junto con una clasificación para cada una de esas conexiones. Estas entradas de mapa enviadas eran procesadas por un programa automático que las combinaba 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 propósito. Los archivos de mapa UUCP podían ser utilizados por software como "pathalias" para calcular la mejor ruta de una máquina a otra para el correo, y para proporcionar esta ruta automáticamente. Los mapas UUCP también incluían información de contacto para los sitios, y así brindaban 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 pasarelas 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 podía intercambiar correo con usuarios de Internet, y los enlaces de Internet podían utilizarse para evitar grandes porciones de la lenta red UUCP. Se definió una "zona UUCP" dentro del espacio de nombres de dominio de Internet para facilitar estas interfaces.
Con esta infraestructura, la fortaleza de UUCP era que permitía a un sitio obtener correo electrónico de Internet y conectividad Usenet con sólo un enlace de módem de acceso telefónico a otro ordenador que cooperara. Esto ocurría en una época en la 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 , dos sistemas caros y difíciles de organizar. Por el contrario, un enlace a la red UUCP podía establecerse normalmente con unas cuantas 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, salvo los más básicos, de las llamadas telefónicas.
uux es una 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 es ejecutado por el uucicodemonio, que maneja las solicitudes de ejecución remota simplemente como otro tipo de archivo para enviar por lotes al sistema remoto cada vez que un nodo de siguiente salto esté disponible. El sistema remoto ejecutará entonces 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 arbitrarias de disponibilidad. Incluso cuando se ejecuta un comando en un vecino siempre disponible, uux no es instantáneo.
El uso del UUCP comenzó a desaparecer con el surgimiento de proveedores de servicios de Internet que ofrecían servicios SLIP y PPP económicos . El Proyecto de Mapeo del UUCP se cerró formalmente a fines de 2000.
El protocolo UUCP ha sido reemplazado en su mayor parte por los protocolos basados en Internet 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"; tenía sólo 13 usuarios en ese momento (antes de su cierre había rechazado solicitudes de nuevos usuarios durante varios años). [15]
Una característica sobreviviente de UUCP es el formato de archivo de chat, heredado en gran medida por el paquete de software Expect .
UUCP se utilizó en enlaces de alto costo para propósitos especiales (por ejemplo, enlaces satelitales marinos) mucho después de su desaparición en otros lugares, [16] y todavía permanece en uso heredado. [ cita requerida ] Además del uso heredado, en 2021 están creciendo nuevos e innovadores usos de UUCP, especialmente para telecomunicaciones en la banda de HF , por ejemplo, para comunidades en la selva amazónica para intercambio de correo electrónico y otros usos. Se contribuyó con un parche para 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 [ ¿según quién? ] UUCP sobre TCP/IP (a menudo cifrado, utilizando el protocolo SSH [10] ) para su uso cuando una computadora no tiene ninguna dirección IP fija pero aún está dispuesta a ejecutar un agente de transferencia de correo (MTA) estándar como Sendmail o Postfix .
Las rutas de tipo Bang todavía se utilizan en la red Usenet , aunque no para enrutamiento; se utilizan para registrar, en el encabezado de un mensaje, los nodos por los que ha pasado ese mensaje, en lugar de indicar a dónde irá a continuación. [19] "Ruta Bang" también se utiliza como expresión para cualquier ruta de enrutamiento explícitamente especificada 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 fue revisado 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.