Protocolos de enlace de datos: Xmodem 1.- Motivación y Objetivos. Un protocolo de enlace de datos es un programa que permite la transferencia fiable de datos entre dos máquinas. La utilidad de un programa de estas características es obvia, por lo que existe una amplia colección de estos protocolos para prácticamente todo tipo de máquinas y sistemas operativos. A pesar de esto, consideramos que es muy importante, no sólo “saber” cómo es uno de estos protocolos, sino también “saber hacer”, poder desarrollar un protocolo de enlace que pueda estar personalizado a las necesidades específicas de un entorno o de un nuevo equipo/dispositivo microprocesador. Piénsese, por ejemplo, en un diseño a medida de un dispositivo sensor a microprocesador que mida temperatura, presión, peso o cualquier otro parámetro, y que tenga que transmitir la información de forma fiable a una central de proceso de datos. Es un ejemplo, entre miles, en que se necesita dotar al nuevo dispositivo de un protocolo de enlace. De ahí el interés de este capítulo, donde se explica como implementar ( y se da implementado) el, posiblemente, más sencillo, común y veterano de los protocolos de enlace, el Xmodem. Organización del capítulo. El punto 2 es una introducción muy simplista, pero entendemos que clarificadora, de cuales son las funciones de todo nivel de enlace de datos y como pueden llevarse a cabo. El punto 3 explica como funciona Xmodem. 2.- Introducción a los protocolos de enlace de datos La función de este nivel es corregir los errores de transmisión de los datos que puedan producirse en el nivel físico. La manera como abordamos este problema es estableciendo un protocolo de enlace de datos entre emisor y receptor. ¿Qué es un protocolo? Según el diccionario de la Real Academia Española es una “regla ceremonial diplomática establecida por decreto o costumbre”. Adaptando esta definición al mundo de los computadores diremos que es “el conjunto de acciones preestablecidas que regulan el dialogo entre emisor y receptor”. O dicho en Román Paladino, que cuando el ordenador A transmita tal cosa, el ordenador B deberá responder de tal y tal manera. ¿Cómo se plantea un protocolo de enlace de datos?. Imagínese que usted utiliza el correo ordinario para mandar a un colega un libro que está escribiendo. Usted manda un capítulo tras otro a medida que los va escribiendo. Evidentemente ningún servicio de correos es perfecto (¡el español no lo es!) y existe la posibilidad de que se dañe (se pierda alguna hoja o quede ilegible) o extravíe una o varias cartas. No obstante, éste no es un problema indetectable ni tampoco insalvable. Quiere decirse que usando unas medidas de control lógicas, como puede ser numerar los capítulos, numerar las páginas, saber a priori que se mandará un capítulo por semana (p.e.), etc., cualquiera de los dos corresponsales puede fácilmente darse cuenta si no llega bien un capítulo y si es necesario que se vuelva a mandar (esperando una mejor suerte en el reenvío). Un protocolo de enlace de datos no es muy distinto del comportamiento lógico de nuestros dos corresponsales. Podemos razonar, paso a paso, las pautas ól gicas que debe seguir cualquier Protocolos de enlace de datos - 1 protocolo de este estilo. Denominaremos A al computador que transmite los datos y B al que los recibe. Paso 1: ¿ Cómo puede saber el receptor que los datos que ha recibido están o no dañados, alterados? Un protocolo de enlace de datos transmite bloques de información de un tamaño máximo X al que va asociado algún mecanismo de detección de errores. El más potente es el código redundante cíclico (CRC) que se estudiará en capítulo aparte. En cualquier caso, utilizado el CRC u otro, todos los métodos de detección de errores se basan en dar al bloque una propiedad conocida a priori por ambos computadores. Si se altera el contenido del bloque en la transmisión se pierde la propiedad y esto permite decidir al receptor que el contenido difiere del original transmitido, esto es, que el bloque es erróneo y hay que descartarlo. En conclusión: Un protocolo de enlace debe utilizar una transmisión por bloques (a nivel de enlace los bloques tienen nombre propio: tramas), y todas las tramas con su CRC, o método alternativo, para poder detectar errores. Paso 2: ¿Cómo saber si la trama que ha llegado es la primera ( o la n-ésima)? Secuenciando las tramas. Es decir, además de transmitir datos y CRC se transmite un campo (por ejemplo un octeto) que permita secuenciar las tramas ( cíclicamente, p.e. 0, 1, 2, ..., 254, 255, 0, 1, ...). Paso 3: ¿Qué se debe hacer si se detecta que ha llegado correctamente el (p.e.) bloque 2 y el primero no? Una estrategia ampliamente utilizada es mandar al emisor de las tramas de datos (A), tramas de “reconocimiento positivo” en caso de recepción correcta (una especie de acuse de recibo) y tramas de “reconocimiento negativo” en caso de haber detectado un error de recepción (una especie de reclamación por trama dañada). Los reconocimientos normalmente indican el número de secuencia de la trama de datos a la que aluden. Es claro que si A recibe un reconocimiento negativo de un trama, deberá retransmitirla. Paso 4: Obsérvese que si el emisor transmite una trama de datos y se pierde completamente (un fallo temporal en la línea de transmisión p.e.) el receptor es incapaz de detectar este tipo de error. Lo mismo puede ocurrir para los “reconocimientos positivos y negativos” antes mencionados que se pueden perder completamente. ¿Cómo debe actuar la máquina A en ausencia de contestación al envió de una trama? La estrategia conservadora es repetir las tramas de las que no reciba un reconocimiento positivo pasado un tiempo prudencial de respuesta (tiempo que se le denomina de “Time Out”). Simplemente siguiendo estas cuatro reglas tenemos el 90% de prácticamente cualquier protocolo conocido de enlace de datos. Existen factores que pueden simplificar o complicar un protocolo. Por ejemplo, una medida simplificadora es hacer que el computador emisor A no mande una nueva trama hasta que le hayan reconocido positivamente la actual (protocolos tipo Stop & Wait). Pero esta estrategia puede ser menos eficiente que permitir que A pueda mandar varias tramas a la vez sin esperar los reconocimientos (protocolos tipo Pipeline). Protocolos de enlace de datos - 2 3.- Protocolo Xmodem Xmodem es un protocolo del tipo Stop & Wait, es decir, el transmisor transmitirá una trama de datos y esperará un reconocimiento del receptor para mandar la siguiente trama (reconocimiento positivo) o repetir la transmisión (reconocimiento negativo). El formato de las tramas de datos que transmite el transmisor es: donde: SOH = Comienza la cabecera (Start Of Header), ASCII 1 (0x01) BLK = Número de bloque (BLocK number), 0 a 255 BLC = Complemento a 1 de BLK (BLock Complement) CHK = Suma módulo 256 del campo de 128 datos (CHecKsum) El transmisor también transmite una trama de control, que es un único carácter: donde: EOT = Fin de transmisión (End Of Transmission), ASCII 4 (0x04) El receptor sólo transmite tramas de control, formadas por un único carácter: donde: ACK = Reconocimiento positivo (ACKnowledge), ASCII 5 (0x05) NAK = Reconocimiento negativo (Negative AcK.), ASCII 21 (0x15) CAN = Cancelar (CANcel), ASCII 24 (0x18) Protocolos de enlace de datos - 3 Funcionamiento. Las tramas de datos empiezan siempre por el carácter ASCII SOH (0x01). La secuencia de las tramas se identifica mediante el campo BLK. BLK es un octeto, luego los valores posibles son [0..255]. La primera trama se numera con BLK=1 (no como BLK=0). BLK se incrementa en 1 módulo 256 a cada nueva trama. (Obsérvese que detrás de la trama 255 va la trama 0, no la 1). Ante la importancia de este campo, el campo BLC se manda para poder detectar errores de transmisión que pudieran haber alterado el valor de BLK. Si el complemento a 1 del BLK recibido no coincide con el valor de BLC se entenderá que ha habido un error de transmisión y se pedirá una retransmisión de la trama. El campo de datos es siempre fijo de 128 octetos. Esto implica que si el fichero a transmitir no es de tamaño múltiplo de 128 octetos, habrá una última trama que tendrá que ser rellenada con ceros hasta completar los 128 octetos. Una curiosidad de este protocolo es que el receptor interpretará este relleno como parte del fichero, escribiendo en disco un fichero de tamaño múltiplo de 128. Esto no es un problema, tanto si el fichero es de contenido ASCII (p.e. texto) como si es un fichero binario (p.e. ejecutable), no le molestará tener un añadido de ceros al final del fichero. El campo CHK es el checksum de los 128 octetos de datos. Se calcula como la suma módulo 256 de los 128 octetos. Emisor y receptor realizan la operación. El receptor decide que ha habido un error de transmisión si el checksum que calcula no coincide con el transmitido en el campo CHK, entonces solicitará una retransmisión de la trama. Si la recepción de la trama de datos es correcta, el receptor solicita la siguiente mandando ACK. Si ha habido algún error de recepción, el receptor manda NAK solicitando una retransmisión. Si el error en recepción es reiterado (10 veces consecutivas la misma trama errónea) entonces el receptor manda CAN para cancelar la transmisión del fichero. Protocolos de enlace de datos - 4 El pseudo código (sin entrar en detalles) del emisor y del receptor es el siguiente: EMISOR:--------------------------------------------------------------------------------------Abrir fichero a transmitir Inicializar la rs232/modem/...el canal a utilizar Esperar a recibir NAK MIENTRAS (todavía hay bloques para transmitir){ REPETIR{ Mandar SOH que corresponda Mandar BLK Mandar BLC /* 255-BLK */ Mandar datos y calcular el checksum Mandar CHK Esperar respuesta con TimeOut }HASTA (la respuesta sea ACK o 10 intentos consecutivos) } Mandar EOT Esperar por ACK Cerrar fichero RECEPTOR:--------------------------------------------Crear un fichero nuevo Inicializar la RS232/modem/... Mandar NAK para indicar al emisor empiece a transmitir REPETIR{ Esperar por SOH, EOT o TimeOut SI (es SOH){ Tomar el número de bloque BLK Tomar el complemento BLC Tomar los datos e ir calculando checksum Tomar el CHK SI ( no errores ) Mandar ACK SINO Mandar NAK } SI (es EOT){ Cerrar el nuevo fichero Mandar ACK } SI (TimeOut) Mandar NAK }HASTA (EOT) Protocolos de enlace de datos - 5 A continuación se nuestra un ejemplo del flujo de datos que puede ayudar a comprender el funcionamiento de este sencillo protocolo. EMISOR <SOH> 01 FE -datos- <xx> <SOH> 02 FD -datos- <xx> <SOH> 02 FD -datos- <xx> <SOH> 03 FC -datos- <xx> (no llega, o llega erroneo) <SOH> 03 FC -datos- <xx> <EOT> Cierra <-----> <-----> <-----> <-----> RECEPTOR TimeOuts de 10 segundos <NAK> <ACK> (llega dañada) <NAK> <ACK> <ACK> <-----> <-----> <--- TimeOut, <NAK> entonces manda <ACK> <ACK> Cierra Protocolos de enlace de datos - 6