Para negociar el control de la sesión y las transferencias de ficheros con el sistema remoto, uucico usa un grupo de mensajes estándar. Esto es lo que se llama normalmente protocolo de alto nivel. Durante la fase de inicialización y la fase de desconexión éstos se envían simplemente como cadenas de caracteres. Sin embargo, durante la fase de transferencia, se usa también un protocolo de bajo nivel, que resulta transparente para los niveles superiores. De esta manera es posible comprobar errores cuando se usan líneas poco fiables, por ejemplo.
Dado que UUCP se usa sobre diferentes tipos de conexiones, como líneas serie, TCP, o incluso X.25, es preciso usar protocolos de bajo nivel específicos. Además, varias implementaciones de UUCP han introducido diferentes protocolos para hacer lo mismo.
Los protocolos se pueden dividir en dos categorías: de flujo streaming y por paquetes. La primera clase de protocolos transfiere un fichero entero, posiblemente calculando una suma de comprobación. Esto apenas supone un gasto extra de tiempo, pero precisa una conexión fiable, porque cualquier error causaría que todo el fichero tenga que volver a ser enviado. Estos protocolos se suelen usar sobre conexiones de TCP, pero no sobre líneas telefónicas. Aunque los modems modernos hacen un buen trabajo corrigiendo errores, no son perfectos, y tampoco lo es la detección de errores entre el ordenador y el módem.
Por otra parte, los protocolos por paquetes parten el fichero en varias partes de igual tamaño. Cada paquete se envía y recibe por separado, se realiza una suma de comprobación, y se devuelve al origen un paquete de confirmación. Para que sea más eficiente, se inventaron protocolos de ventanas deslizantes, que permiten un número limitado (una ventana) de paquetes sin esperar confirmación en un momento dado. Esto reduce considerablemente la cantidad de tiempo que uucico tiene que esperar durante una transmisión. Aún así, todos los cálculos extra necesarios en comparación a un protocolo de flujo hace que los protocolos de paquetes sean ineficientes sobre TCP pero ideales para las líneas telefónicas.
El caudal del flujo de datos también supone una diferencia. A veces enviar caracteres de 8 bits sobre una conexión serie puedes resultar imposible; por ejemplo, si la conexión atraviesa un estúpido servidor de terminales que se deshace del octavo bit. Cuando transmite caracteres de 8 bits sobre una conexión de 7 bits tienen que codificarse. En el peor caso posible, la codificación duplica la cantidad de datos a transmitir aunque la compresión por hardware pueda compensarlo. Las líneas por las que se pueden transmitir caracteres de 8 bits arbitrarios suelen llamarse preparadas para 8 bits. Éste es el caso de todas las conexiones por TCP, así como de la mayoría de las conexiones por módem.
Taylor UUCP 1.06 soporta una amplia variedad de protocolos UUCP. Los más comunes son éstos:
Éste es el protocolo más común y deberían entenderlo prácticamente todos los uucicos. Al estar dotado de una potente comprobación de errores resulta especialmente apropiado para conexiones telefónicas con interferencias. g requiere una conexión preparada para 8 bits. Es un protocolo orientado a paquetes que usa una técnica de ventana deslizante.
Éste es un protocolo de paquete bidireccionales por el que pueden enviar y recibirse ficheros al mismo tiempo. Requiere una conexión full-duplex y un flujo de datos preparado para 8 bits. Actualmente sólo lo entiende Taylor UUCP.
Este protocolo está pensado para usarse sobre una conexión TCP u otras redes realmente libres de errores. Usa paquetes de 1.024 bytes y requiere una conexión preparada para 8 bits.
Éste debería hacer básicamente lo mismo que t. La principal diferencia reside en que e es un protocolo de flujo por lo que está orientado únicamente a conexiones de red eficientes.
Este protocolo está orientado a conexiones X.25 eficientes. Es un protocolo de flujo y espera un flujo de datos de 7 bits. Los caracters de 8 bits tienen que codificarse, lo que puede hacerlo muy poco eficiente.
Ésta es la versión 4 System V del protocolo g. También lo entienden otras versiones de UUCP.
Este protocolo es similar al ZMODEM. Requiere una conexión de 8 bits pero codifica ciertos caracterse de control como XON y XOFF.
Todos los protocolos permiten alguna variación en el tamaño de los paquetes, el cronómetro y similares. Usualmente, los valores por omisión funcionan bien, pero puede no ser óptimo para su configuración. El protocolo g, por ejemplo, usa tamaños de ventanas de 1 a 7, y tamaños de paquetes en potencias de 2 desde 64 a 4096. Si su línea telefónica es tan ruidosa que ignora el 5 por ciento de los paquetes, probablemente debería disminuir el tamaño de los paquetes y de la ventana. Sin embargo, en líneas de teléfono muy buenas el hecho de enviar acuses de recibo por cada 128 bytes puede resultar un desperdicio, así que podría incrementar el tamaño de los paquetes a 512 o incluso 1024. La mayoría de los binarios que se incluyen en las distribuciones de Linux usan de manera predeterminada un tamaño de ventana 7 y paquetes de 128 bytes.
Taylor UUCP le permite ajustar los parámetros con la orden protocol-parameter en el fichero sys. Por ejemplo, para ajustar el tamaño de paquete a 512 en el protocolo g cuando se hable con pablo, tendrá que añadir:
system pablo
...
protocol-parameter g packet-size 512 |
Los parámetros configurables y sus nombres varian de un protocolo a otro. Para una lista completa de ellos acuda a la documentación que acompaña a las fuentes de Taylor UUCP.
No todas las implementaciones de uucico son capaces de comunicarse por medio de todos los protocolos, por lo que durante la fase de negociación inicial ambos procesos tienen que ponerse de acuerdo en la elección de un protocolo común. El uucico maestro proporciona al esclavo una lista de protocolos soportados enviándole Pprotlist, de la cual el esclavo elegirá uno.
Basándose en el tipo de puerto usado (módem, TCP o conexión directa) uucico compondrá una lista de protocolos predeterminados. Para la conexión directa o por módem esta lista suele constar de i, a, g, G y j. Para las conexiones por TCP la lista suele ser t, e, i, a, g, G, j y f. Puede sobreescribrir esta lista predeterminada con la orden protocols, que puede especificarse en una entrada de sistema así como en una entrada de puerto. Por ejemplo, puede editar la entrada de su módem en el fichero port de esta manera:
port serial1
...
protocols igG |
Esto requerirá que cualquier conexión entrante o saliente por este puerto use i, g o G. Si el sistema remoto no soporta ninguno de éstos la negociación fallará.