Hispanopedia Wiki
Articulo de referencia

UUCP

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 elect...

Hispanopedia WikiContenido en espanolLectura gratuita

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 la red entre computadoras .

Un comando llamado uucpes uno de los programas del conjunto; proporciona una interfaz de usuario para solicitar operaciones de copia de archivos. El conjunto 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 del conjunto 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 se asocia más estrechamente con sistemas tipo Unix , existen implementaciones de UUCP para varios sistemas operativos que no son tipo Unix, incluidos DOS , OS/2 , OpenVMS (solo para hardware VAX), AmigaOS , [ 2 ] Mac OS clásico e incluso CP/M .

Historia

UUCP fue escrito originalmente en los Laboratorios Bell de AT&T por Mike Lesk . [ 3 ] Para 1978, se utilizaba en 82 máquinas UNIX dentro del sistema Bell, principalmente para la distribución de software. Fue lanzado en 1979 como parte de la versión 7 de Unix . [ 4 ]

Los primeros correos electrónicos UUCP procedentes 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. Esta reescritura se conoce como HDB o HoneyDanBer uucp, la cual fue posteriormente mejorada, se corrigieron errores y se reempaquetó 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 se publicó bajo la Licencia Pública General de GNU . Taylor UUCP solucionó las vulnerabilidades de seguridad que permitían a algunos de los gusanos de red originales ejecutar remotamente 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 usar formatos de archivo de configuración similares de otras versiones.

UUCP también se implementó para sistemas operativos que no eran UNIX , sobre todo para 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) llevaron la conectividad a Internet a las computadoras personales, expandiendo la red más allá de los sistemas universitarios interconectados. FSUUCP sirvió de 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 Usenet . Por ejemplo, UFGATE (John Galvin, Garry Paxinos, Tim Pozar) era un paquete que proporcionaba 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 con respecto al protocolo 'g' estándar utilizado por la mayoría de las implementaciones de UUCP.

Tecnología

Antes de la disponibilidad generalizada del acceso a Internet , los ordenadores solo se conectaban mediante pequeñas redes de área local dentro de una empresa u organización. Además, solían estar equipados con módems para poder utilizarlos de forma remota desde terminales de texto mediante líneas telefónicas de acceso telefónico . UUCP utilizaba los módems de los ordenadores para realizar llamadas salientes a otros ordenadores, estableciendo enlaces temporales punto a punto entre ellos. Cada sistema en una red UUCP tiene una lista de sistemas vecinos, con números de teléfono, nombres de usuario y contraseñas, etc. Cuando se pone en cola una tarea (transferencia de archivos o ejecución de comandos) para un sistema vecino, el programa normalmente llama a ese sistema para procesarla. El programa también puede consultar periódicamente a sus vecinos para comprobar si tienen tareas en cola; esto permite que participen los vecinos sin capacidad de llamada saliente.uucicouucico

Con el tiempo, las conexiones de acceso telefónico fueron reemplazadas por conexiones a Internet, y UUCP incorporó varios protocolos de capa de enlace nuevos . 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 sobre conexiones de acceso telefónico, pero ocasionalmente se utiliza sobre TCP/IP . [ 9 ] [ 10 ] A principios de 2006, el número de sistemas involucrados oscilaba entre 1500 y 2000 sitios en 60 empresas. La longevidad de UUCP se puede atribuir a su bajo costo, registro exhaustivo, conmutación por error nativa a acceso telefónico y gestión persistente de colas.

Sesiones

UUCP se inicia normalmente 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 utilizada para transferencias, cuyo shell de cuenta se ha configurado como uucico. Por lo tanto, para 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 uucico se ejecuta, espera recibir comandos de otro programa UUCP en la máquina del emisor e iniciar una sesión. La sesión tiene tres etapas distintas:

  1. primer apretón de manos
  2. Solicitud(es) de archivo
  3. apretón de manos final

primer apretón de manos

Al iniciarse, uucico responderá enviando una cadena de identificación, , donde \20 ( octal , decimal 16) es el carácter de control-P y \0 es un carácter nulo final. El UUCP del emisor responde con , donde options es una cadena que contiene cero o más opciones de configuración tipo Unix. Estas pueden incluir tamaños de paquete y ventana, el tamaño máximo de archivo admitido, opciones de depuración y otras.\20Shere=hostname\0\20Scallernameoptions\0

Dependiendo de la configuración de ambos sistemas, la llamada puede finalizar aquí. Por ejemplo, si quien llama responde con el nombre de su sistema, el sistema receptor puede colgar si no reconoce a quien llama, enviando la RYou are unknown to me\0cadena de respuesta y luego desconectándose.

Solicitudes de archivos

Si los dos sistemas establecen la conexión correctamente, el emisor comenzará a enviar una serie de solicitudes de archivos. Hay cuatro tipos:

El comando S provoca el envío de un archivo desde el sistema emisor al sistema receptor (carga). Se proporcionan los nombres de origen y destino, lo que permite modificar el nombre del archivo en el receptor. Cuando el sistema receptor recibe el comando S, responde con SY si la operación se realizó correctamente y está listo para aceptar el archivo, o con SNx si falló, donde x es un código de error. Si el sistema emisor recibe SY, comienza a cargar el archivo utilizando el protocolo seleccionado durante el establecimiento de la conexión (véase más abajo). Una vez completada la transferencia, el sistema receptor responde con CY si recibió el archivo correctamente, o con CN5 si falló.
R es una solicitud para que el sistema llamado envíe un archivo al sistema que realizó la llamada (descarga). Por lo demás, es similar a S, utilizando RY y RN para indicar que el comando fue aceptado y comenzará a enviar datos o que hubo un problema, y ​​esperando CY y CN5 del sistema que realizó la llamada al finalizar la transferencia.
X carga comandos para ser ejecutados en el sistema llamado. Esto permite que dicho sistema llame a otro y le entregue archivos. El sistema llamado responde con XY si la operación se realiza correctamente o con XN si falla.
La letra H , de "Hangup" (colgar), indica que la persona que llama ha terminado. El sistema llamado responde con HY si la llamada se realizó correctamente o con HN si falló.

apretón de manos final

Tras enviar un comando H, el sistema que realiza la llamada envía un paquete final \20OOOOOO\0(control-P, seis 0, terminador nulo) y el sistema llamado responde con \20OOOOOO\0(control-P, siete 0, terminador nulo). Algunos sistemas simplemente cuelgan al recibir correctamente el comando H y no realizan el protocolo de enlace final.

protocolo g

Dentro del conjunto de protocolos de UUCP, el protocolo g subyacente se encarga de transferir información sin errores. Este 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 totalidad. 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 paquete y ventana durante la transmisión. Es posible que estas características adicionales no estén disponibles en algunas implementaciones de la pila UUCP. [ 11 ]

El formato del paquete consistía en una cabecera de 6 bytes y, a continuación, entre cero y 4096 bytes en la carga útil. El paquete comenzaba con un único \020 (control-P). A continuación, se encontraba un único byte, conocido como "K", con un valor entre 1 y 8 que indicaba un tamaño de paquete de entre 32 y 4096 bytes, o un 9 que indicaba 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 la cabecera. El siguiente byte era el tipo de datos y, finalmente, el último byte era el resultado de la operación XOR de la cabecera, lo que permitía comprobarla 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 serí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 gestionar las latencias potencialmente largas entre los puntos finales. El protocolo permite que los paquetes tengan un tamaño de entre 32 y 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 (4096  ×  7) ofrecería un rendimiento igual o superior al de los mejores protocolos de transferencia de archivos como ZMODEM . En la práctica, muchas implementaciones iniciales 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 los paquetes y las ventanas dio lugar al protocolo G, que se diferenciaba únicamente en que siempre utilizaba 4096x3. Taylor UUCP no admitía G, pero sí admitía cualquier tamaño de ventana o paquete válido solicitado, por lo que los sistemas remotos que iniciaban G funcionaban bien con el g de Taylor, mientras que dos sistemas Taylor podí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 enviados al sistema remoto e inmediatamente enviando 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 en el ordenador local 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 mediante un protocolo propietario basado en MNP que funcionaba sobre 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 ACKmensajes que desbordaría el canal de retorno de baja velocidad. Combinado con las velocidades de datos naturalmente más altas del módem, de hasta 23  kbps, mejoraban enormemente el rendimiento general y, por lo general, alcanzaban una velocidad aproximadamente siete veces superior a la de un módem de 2400 bit/s. [ 12 ] Se usaban ampliamente en hosts UUCP ya que podían amortizarse rápidamente gracias a la reducción de los cargos por llamadas de larga distancia.

Otros protocolos

Las implementaciones de UUCP también incluyen otros protocolos de transferencia para su uso en determinados enlaces.

El protocolo f está diseñado para funcionar sobre enlaces con corrección de errores de 7 bits. Originalmente, se concibió para su uso en enlaces X.25 , que fueron populares durante un tiempo en la década de 1980. No empaqueta los datos; en su lugar, el archivo completo se envía como una única cadena larga seguida de una suma de verificación de archivo completo. El protocolo x, similar al anterior , parece haber tenido poco o ningún uso. El protocolo d era similar al x, pero estaba destinado a su uso 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 otros protocolos similares, está diseñado para funcionar sobre enlaces TCP/IP de 8 bits sin errores . No cuenta con corrección de errores y consiste simplemente en dividir los datos de comandos y archivos en paquetes de 512 o 1024 bytes para que quepan fácilmente dentro de las tramas TCP típicas.

El protocolo e ("e" de Ethernet) fue desarrollado por Clem Cole en MASSCOMP y ampliamente difundido por Brian Redman en las versiones posteriores de HoneyDanBer. Fue desarrollado y publicado antes que el protocolo t, pero este último se utilizó con mayor frecuencia debido a que la versión BSD de UUCP era la implementación dominante. El protocolo e se diferencia del protocolo t únicamente en que los comandos no se empaquetan, sino que se envían como cadenas normales, mientras que los archivos se rellenan hasta los 20 bytes más cercanos. [ 11 ] [ 13 ]

Enrutamiento de correo

Tarjeta de presentación con dirección de correo electrónico de UUCP

Las uucpcapacidades uuxqtpodrían utilizarse para enviar correo electrónico entre máquinas, con interfaces de usuario de correo y programas de agente 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 como "bang" ), seguido del nombre de usuario en la máquina adyacente. Por ejemplo, la dirección barbox!user se referiría al usuario user en la máquina adyacente barbox . [ 14 ]

Además, el correo podía enrutarse a través de la red, pasando por varios nodos intermedios antes de llegar a su destino. Inicialmente, esto debía 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 para enviar correo sería foovax!barbox!usuario .

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 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 sería inútil, porque sería diferente, dependiendo de dónde se encuentre 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!user ). Muchos usuarios sugerirían múltiples rutas desde varios sitios grandes y conocidos, proporcionando un servicio de conexión aún mejor y quizás más rápido por parte del remitente del correo.

Ruta de golpe

Una dirección de correo electrónico de este tipo se conocía como ruta de salto . Las rutas de salto de ocho a diez máquinas (o saltos ) eran comunes en 1981, y las conexiones UUCP de acceso telefónico nocturno podían causar tiempos de transmisión de hasta una semana. Las rutas de salto se elegían a menudo en función del tiempo de transmisión y la fiabilidad, ya que los mensajes solían perderse. Algunos servidores llegaron incluso a intentar " reescribir " la ruta, enviando el correo a través de rutas "más rápidas"; esta práctica solía ser mal vista.

El "pseudodominio" con la terminación .uucp se utilizaba a veces para indicar que un nombre de host era accesible mediante la red UUCP, aunque nunca se registró formalmente en el sistema de nombres de dominio (DNS) como un dominio de nivel superior . La comunidad uucp se autogestionaba y no se integraba bien con los métodos y regulaciones de administración del DNS; .uucp funciona donde debe ; algunos hosts desvían 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.

El tráfico de Usenet se transmitía originalmente mediante el protocolo UUCP, generalmente a través de módems de acceso telefónico. En cada nodo receptor, la línea de encabezado Path de cada artículo de Usenet tenía el nombre del nodo actual antepuesto a la ruta, separado por "!". Por ejemplo, un artículo que llegaba del nodo utzoo al nodo decvax con Path: utzoo!henry tendría esa línea cambiando a Path: decvax!utzoo!henry . El software de Usenet enviaba entonces una copia de cada artículo a cada nodo vecino que hubiera sido configurado para recibir los grupos de noticias en los que se había publicado el artículo, a menos que ese vecino ya estuviera en la línea Path . Estas rutas se utilizaban, por lo tanto, para asegurar que los artículos no volvieran a un nodo que ya los tuviera.

En general, al igual que otros formatos de direcciones de correo electrónico más antiguos , las rutas con signo de exclamación han sido reemplazadas por la notación "@ ", incluso en sitios que aún utilizan UUCP. Un sitio que solo utiliza UUCP puede registrar un nombre de dominio DNS y hacer que el servidor DNS que administra ese dominio proporcione registros MX que hagan que el correo de Internet dirigido a ese sitio se entregue a un host UUCP en Internet, que luego puede entregar el correo al sitio UUCP.

UUCPNET y mapeo

UUCPNET era el nombre que recibía la totalidad de la red de ordenadores conectados mediante UUCP. Esta red era muy informal y se mantenía con un espíritu de cooperación mutua entre sistemas pertenecientes a 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 estaba en constante evolución, ya que se añadían nuevos sistemas y enlaces de acceso telefónico, se eliminaban otros, etc.

El Proyecto de Mapeo UUCP fue una iniciativa voluntaria, en gran medida exitosa, para crear un mapa de las conexiones entre máquinas que funcionaban como repetidores 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 conectaba el suyo, junto con una clasificación para cada conexión. 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 de la red. Estos archivos se publicaban mensualmente en un grupo de noticias dedicado a este fin. Los archivos de mapa UUCP podían ser utilizados por software como "pathalias" para calcular la mejor ruta de correo entre máquinas y proporcionarla automáticamente. Los mapas UUCP también incluían información de contacto de los sitios, lo que facilitaba a los sitios que buscaban unirse a UUCPNET la búsqueda de posibles vecinos.

Conexiones con Internet

Muchos servidores UUCP, especialmente los de las universidades, también estaban conectados a Internet en sus inicios, 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 sortear gran parte 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 principal ventaja de UUCP radicaba en que permitía a un sitio acceder a correo electrónico y conectividad Usenet mediante una simple conexión por módem telefónico a otro ordenador colaborador. Esto ocurría en una época en la que el acceso real a Internet requería una línea de datos alquilada que proporcionaba una conexión a un punto de presencia en Internet (PPP ), ambas opciones costosas y difíciles de conseguir. En cambio, la conexión a la red UUCP solía establecerse con unas pocas llamadas telefónicas a los administradores de los sistemas vecinos. Estos sistemas solían estar lo suficientemente cerca como para evitar prácticamente todos los gastos de las llamadas telefónicas.

Comandos remotos

uux permite 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 en el sistema local mediante archivos de sistemas remotos. El comando es ejecutado por el uucicodemonio, que gestiona las solicitudes de ejecución remota como si fueran simplemente otro tipo de archivo que se envía por lotes al sistema remoto cuando hay un nodo de salto siguiente disponible. 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 al ejecutar un comando en un vecino siempre disponible, uux no es instantáneo.

Rechazar

El uso de UUCP comenzó a desaparecer con el auge de los proveedores de servicios de Internet que ofrecían servicios SLIP y PPP económicos . El Proyecto de Mapeo de UUCP se clausuró formalmente a finales del año 2000.

El protocolo UUCP ha sido reemplazado en gran medida por los protocolos basados ​​en TCP/IP de Internet, SMTP para correo electrónico 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 aún lo ofrecía"; en ese momento solo tenía 13 usuarios (antes de su cierre había rechazado solicitudes de nuevos usuarios durante varios años). [ 15 ]

Usos actuales y legado

Una característica que se conserva 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 fines especiales (por ejemplo, enlaces satelitales marinos) mucho después de su desaparición en otros lugares, [ 16 ] y aún se mantiene en uso heredado. Además del uso heredado, en 2021 están creciendo nuevos e innovadores usos de UUCP, especialmente para telecomunicaciones en la banda HF , por ejemplo, para comunidades en la selva amazónica para intercambio de correo electrónico y otros usos. Se contribuyó con un parche al UUCP de Ian para el 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, Fabien Penso y Yann Hirou propusieron UUCP sobre TCP/IP (a menudo cifrado, utilizando el protocolo SSH [ 10 ] ) para su uso cuando un ordenador no tiene direcciones IP fijas pero está dispuesto a ejecutar un agente de transferencia de correo (MTA) estándar como Sendmail o Postfix .

Las rutas tipo "Bang" todavía se utilizan en la red Usenet , aunque no para enrutamiento; se usan para registrar, en la cabecera de un mensaje, los nodos por los que ha pasado, en lugar de indicar a dónde irá después. [ 19 ] "Ruta Bang" también se usa como expresión para cualquier ruta de enrutamiento especificada explícitamente entre hosts de red. Este 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 la latencia se retomó a principios de la década de 2000. [ 20 ] Técnicas similares a las utilizadas por UUCP pueden aplicarse a otras redes que experimentan latencia o interrupciones significativas.

Véase también

Referencias

  1. ↑ SISTEMA DE TIEMPO COMPARTIDO UNIX(TM): MANUAL DEL PROGRAMADOR UNIX, Séptima edición, Volumen 1 (PDF) . Murray Hill, Nueva Jersey: Bell Telephone Laboratories, Incorporated. Enero de 1979. Archivado (PDF) del original el 29 de abril de 2016. Consultado el 20 de febrero de 2018 .
  2. ↑ "Aminet - Buscar" .
  3. ↑ McIlroy, MD (1987). Un lector de Research Unix: extractos anotados del Manual del programador, 1971–1986 (PDF) (Informe técnico). CSTR. Bell Labs. 139. Archivado (PDF) del original el 11/11/2017 . Recuperado el 01/02/2015 .
  4. ↑ "Manual de Unix versión 7: "Descripción de la implementación de UUCP" por DA Nowitz y "Una red de acceso telefónico de sistemas UNIX" por DA Nowitz y ME Lesk" (PDF) . Archivado (PDF) del original el 21/02/2018 . Recuperado el 21/02/2018 .
  5. ↑ Houlder, Peter (19 de enero de 2007). "Inicio de Internet comercial en el Reino Unido" (PDF) . 6.º Foro de Operadores de Redes del Reino Unido . Consultado el 12 de febrero de 2020 .
  6. ↑ Reid, Jim (3 de abril de 2007). "Redes en la academia del Reino Unido hace unos 25 años" (PDF) . 7.º Foro de Operadores de Redes del Reino Unido . Archivado del original (PDF) el 20 de agosto de 2007. Consultado el 12 de febrero de 2020 .
  7. ↑ Gary J. Murakami (24 de septiembre de 1988). "La historia de ihnp4 y el crecimiento de la red de correo electrónico" . Archivado del original el 11 de septiembre de 2013. Recuperado el 7 de junio de 2013 .
  8. ↑ Ian Lance Taylor (septiembre de 1991). "Versión beta del nuevo paquete UUCP disponible" . Consultado el 19 de enero de 2009 .
  9. ↑ Ian Lance Taylor (junio de 2003). "Protocolo UUCP 'f'" . Archivado del original el 18 de julio de 2008. Consultado el 4 de agosto de 2008 .
  10. 1 2 Fabien Penso. "UUCPssh" . Archivado del original el 30-09-2009 . Recuperado el 09-08-2009 .
  11. 1 2 3 4 5 6 7 Taylor, Ian Lance (8 de marzo de 1996). "UUCP Internals Preguntas frecuentes" . Archivado del original el 6 de noviembre de 2019. Recuperado el 29 de agosto de 2020 .
  12. ↑ Kirksey, Kenneth (25 de diciembre de 1991). "Lo que necesitas saber sobre los módems" . Archivado del original el 24 de octubre de 2020. Recuperado el 29 de agosto de 2020. El rendimiento real es de alrededor de 14400 bps.
  13. ↑ Talbot, Stephen (febrero de 1988). Guía de administración de UUCP, Rev. C. Manuales de usuario. Massachusetts Computer Corporation.
  14. ↑ Cerf, Vint (20 de marzo de 2022). " [ Política de Internet ] Por qué el mundo debe resistir los llamamientos a socavar Internet" . IETF-Discussion (Lista de correo) . Recuperado el 24 de marzo de 2022 .
  15. ^ Huijbregts, Niels (30 de julio de 2012). "Weblog XS4ALL: Afscheid van UUCP (Adiós a UUCP)" (en holandés). XS4ALL . Archivado desde el original el 31 de julio de 2013.
  16. ↑ Randolph Bentson (agosto de 1995). "Linux se hace a la mar" . Archivado del original el 26 de febrero de 2008. Consultado el 21 de febrero de 2009 .
  17. ↑ Rafael Diniz (enero de 2021). "UUCP 1.07.27-changelog" . Archivado del original el 12 de agosto de 2020. Recuperado el 10 de enero de 2021 .
  18. ↑ Rafael Diniz (enero de 2021). "Sistema de intercambio multimedia rural y de emergencia de alta frecuencia" . Recuperado el 10 de enero de 2021 .
  19. ↑ K. Murchison; C. Lindsey; D. Kohn (noviembre de 2009). "Path" . Formato de artículo de Netnews . IETF . pág. 14-16. sec. 3.1.5. doi : 10.17487/RFC5536 . RFC 5536 .   
  20. ↑ Kevin Fall (agosto de 2003). "Una arquitectura de red tolerante a la latencia para redes de Internet con limitaciones". Actas de la conferencia de 2003 sobre aplicaciones, tecnologías, arquitecturas y protocolos para comunicaciones informáticas - SIGCOMM '03 . Conferencia de 2003 sobre aplicaciones, tecnologías, arquitecturas y protocolos para comunicaciones informáticas. ACM SIGCOMM . págs. 27–34 . doi : 10.1145/863955.863960 . ISBN  978-1-58113-735-4.
  • Uso y gestión de UUCP . Ed Ravin, Tim O'Reilly, Dale Doughtery y Grace Todino. 1996, O'Reilly & Associates, Inc. ISBN 1-56592-153-4
  • Mark Horton (1986). RFC 976 : Estándar de formato de intercambio de correo UUCP . Solicitudes de comentarios del Grupo de Trabajo de Ingeniería de Internet . 
  • Documentación de Taylor sobre UUCP : información útil sobre UUCP en general y sobre diversos protocolos UUCP.
  • El proyecto UUCP: Historia en la Wayback Machine (archivado el 6 de enero de 2014)
Lecturas relacionadas
6 articulos
Figura 2. Protocolos en relación con el esquema de capas de Internet.Protocolo de comunicaciónUn protocolo de comunicación es un sistema de reglas que permite que dos o más entidades de un sistema de comunicaciones transmitan información a t...Programa de computadoraPrograma de computadoraUn programa informático es una secuencia o conjunto de instrucciones en un lenguaje de programación que un ordenador debe ejecutar . Es un componen...Archivo de computadoraArchivo de computadoraEn informática , un archivo informático es un recurso para registrar datos en un dispositivo de almacenamiento informático , identificado principal...Correo electrónicoCorreo electrónicoEl correo electrónico (abreviatura de correo electrónico ; también escrito e-mail ) es un método de transmisión y recepción de mensajes mediante di...UsenetUsenetUsenet ( / ˈ j uː z n ɛ t / ), [ 1 ] abreviatura de User's Network , [ 1 ] es un sistema de discusión distribuido mundial disponible en computadora...Una computadora humana.ComputadoraComputadoras y dispositivos informáticos de diferentes épocas, de izquierda a derecha y de arriba a abajo: Computadora de tubo de vacío temprana ( ...