El funcionamiento interno de uucico (manual administración de redes con Linux)

Para comprender por qué uucico necesita saber ciertas cosas, una rápida descripción de cómo se conecta realmente a un sistema remoto resultará de ayuda.
Cuando usted ejecuta uucico -s sistema desde la línea de órdenes, primero tiene que conectarse físicamente. Las acciones a tomar dependen del tipo de conexión a usar. Por ejemplo, cuando se usa una línea telefónica, tiene que encontrar un módem, y marcar un número de teléfono. Sobre TCP, tiene que llamar gethostbyname (3) para convertir el nombre a una dirección de red, averiguar qué puerto abrir, y conectar la dirección al puerto correspondiente.
Una vez que se ha establecido la conexión, hay que pasar un proceso de autorización. Normalmente consiste en que el sistema remoto pide un nombre de usuario y posiblemente una clave. Esto se llama el diálogo de entrada. El proceso de autorización se lleva a cabo mediante el usual getty/login, o en conexiones TCP por el propio uucico. Si la autorización es permitida, la parte remota de la conexión ejecuta uucico. La copia local de uucico que inició la conexión se denomina maestro, y la copia remota se denomina esclavo.
Ahora viene la fase de handshake : El maestro envía su nombre, ademas de varias opciones. El esclavo
comprueba el nombre para ver si tiene permiso para conectarse, para enviar y recibir ficheros, etc. Las opciones describen (entre otras cosas) el nivel máximo de ficheros de cola que hay que transferir. Si esta opción está activada, tiene lugar una cuenta de conversación, o comprobación de la secuencia de llamada. Con esta característica, ambos ordenadores mantienen una cuenta de conexiones exitosas, que se comparan. Si las cuentas no son iguales, la negociación de protocolos no tendrá lugar. Esto es útil para protegerse de impostores.
Finalmente los dos uucico tratan de ponerse de acuerdo en un protocolo de transferencia común. Este protocolo gobierna la manera en que los datos se transfieren, la manera en que se comprueba la consistencia de los datos, y la manera en que se retransmiten en caso de error. Hacen falta protocolos diferentes debido a los diferentes tipos de conexiones que se soportan. Por ejemplo, las líneas de telefono precisan un protocolo “seguro” que es pesimista respecto a errores, mientras que una transmisión de TCP es fiable y puede usar un protocolo más eficiente que carece de la mayoría de las comprobaciones de errores.
Una vez que las negociaciones se han completado, comienza la fase de la verdadera transmisión. Ambos extremos ponen en funcionamiento el controlador del protocolo elegido. Los controladores posiblemente lleven a cabo alguna secuencia específica del protocolo para la inicialización.
Primero el maestro envía todos los ficheros en la cola de este sistema remoto cuyo nivel de cola es suficientemente alto. Cuando ha finalizado, informa al esclavo que ha terminado, y que el esclavo puede ahora colgar. El esclavo puede entonces colgar, o tomar el control de la conversación. Esto es un cambio de papeles: ahora el sistema remoto se convierte en maestro y el local en esclavo. El nuevo maestro envía ahora sus ficheros. Cuando ha terminado, ambos uucico s intercambian mensajes de terminación, y cierran la comunicación.
Si necesita información adicional sobre UUCP acuda al código fuente. También hay un artículo bastante antiguo escrito por David A. Novitz pululando por la red en el que se proporciona una descripción detallada del protocolo UUCP. 2En las PUF sobre Taylor UUCP también se discuten algunos detalles de la implementación de UUCP. Se envía a comp.mail.uucp con relativa frecuencia.