| Gu�a de Administraci�n de Redes con Linux | ||
|---|---|---|
| Anterior | Cap�tulo 16. Administraci�n deTaylor UUCP | Siguiente |
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�.