PROTOCOLOS. ESTÁNDARES.
ÍNDICE
1. INTRODUCCIÓN
2. NIVEL DE SESIÓN
2.1. Servicios
2.2. Funciones
3. NIVEL DE PRESENTACIÓN
3.1. Servicios
3.2. Funciones
4. NIVEL DE APLICACIÓN
4.1. Servicios
5. PROTOCOLOS DE ALTO NIVEL
5.1. Definición
5.2. Protocolos para el soporte de terminales
5.3. Protocolos para la transferencia de ficheros
6. BIBLIOGRAFÍA
1. INTRODUCCIÓN
Las funciones básicas y los estándares ISO para los siete niveles se ilustran en la figura 66.1.
Figura 66.1. Niveles y funciones básicas ¡SO
Los niveles 1 a 3 proporcionan los protocolos de bajo nivel, principalmente Í” implementados en hardware o mediante controladores dedicados, mientras que los niveles 4 a 7 proporcionan los protocolos de aplicación de más alto nivel, que normalmente se implementan en el software del host (dispositivo de proceso de datos de gran tamaño o controlador de red).
– Nivel 5, el nivel se sesión
El nivel de sesión establece y termina la relación de comunicación (sesión o diálogo) de una forma ordenada, sincronizando la comunicación y determinando qué conexión de transporte se asociará a la sesión. El control de la sesión incluye la cesión del derecho a transmitir en el caso de sistemas half- duplex.
– Nivel 6, el nivel de presentación
El nivel 6 (presentación) adapta el formato de los datos de una aplicación a un formato adecuado para los sistemas de comunicación.
Los protocolos de presentación definen las reglas relativas a cómo se presentarán e intercambiarán los datos en un lenguaje común neutral, es decir, puede ser necesario traducir los datos expresados en caracteres ASCII a EBCDIC, o de formato de punto fijo a formato de punto flotante.
Nivel 7, el nivel de aplicación
El nivel 7 lleva los servicios de red al usuario final, definiendo cómo deben funcionar dos wsuarios de] sistema de comunicaciones. Esta es el nivel mas alto y el único que no es completamente transparente para el usuario.
El software de aplicación en el host no es parte del nivel de aplicación pero los elementos comunes de servicio, como FTAM (File Transfer, Access and Management; transferencia, acceso y gestión de ficheros) y los estándares de X.400 para co-reo electrónico se incluyen en el nivel 7.
Los servicios de red pueden incluir comprobación de passwords, bases de dados distribuidas, transferencias de documentos o ficheros, conexión al sistema y comprobación de derechos de acceso a ficheros.
2. NIVEL DE SESION
El nivel de sesión proporciona los medios necesarios para la cooperación de las entidades de presentación, para organizar y sincronizar su diálogo, y para gestionar su intercambio de datos.
Para ello, el nivel de sesión proporciona los servicios para establecer una sesión cada vez que se desee establecer una comunicación entre entidades de presentación. Esta conexión de sesión se corresponde con, y utiliza a su vez, una conexión de transporte.
No hay multiplexación en este nivel aunque, sin embargo, es posible que varias conexiones de sesión usen la misma conexión de transporte una después de otra en el tiempo. Esto es, una vez terminada una conexión de sesión, se puede establecer otra, utilizando la misma conexión de transporte.
Esto también puede suceder al revés: una conexión de transporte puede terminar y otra ser establecida para servir a la misma conexión de sesión sin que tengan noticia de ello las entidades de presentación. Esto puede ocurrir cuando, por ejemplo, una conexión de transporte debe finalizar por problemas del servicio de red que la soporta. Se puede establecer entonces otra conexión de transporte. El nivel de sesión se encargará de gestionar completamente la resincronización de la conversación.
2.1. SERVICIOS DEL NIVEL DE SESIÓN
– Establecimiento de la conexión de sesión
Este servicio permite a dos entidades de presentación establecer una conexión de sesión entre ellas. Las entidades de presentación se identifican mediante las direcciones de sesiór-pcorrespondientes. Utilizan el elemento de servicio S-CONNECT, de tipo confirmado.
– Liberación de la conexión de sesión
Este servicio permite a los usuarios (entidades de presentación) liberar una conexión de sesión de un modo ordenado sin pérdida de información; utiliza el elemento de servicio confirmado S-RELEASE.
También permite a cualquiera de los usuarios solicitar en cualquier momento que una conexión de sesión sea abortada; en este caso puede haber pérdida de información. El elemento de servicio utilizado para ello es S-U-ABORT, de tipo no confirmado.
La liberación de la conexión también puede ser iniciada por el proveedor del servicio de sesión. El elemento de servicio utilizado es S-P-ABORT.
– Intercambio de datos normales
Permite a las entidades de presentación asociadas por la conexión de sesión, transferir unidades de datos de servicio de sesión (SSDUS) con diálogo usual y/o control de flujo. Consta del elemento de servicio no confirmado S-DATA.
– Intercambio de datos expeditos
Esta facilidad permite a los usuarios del servicio de sesión un intercambio de datos que no está íi,,Cii’ta-úo poc @: cor-itrol del diálogo o el control de ‘.lujo de los a –
les; en algunos casos los datos expeditos pueden adelantar los datos normales transmitidos previamente.
Consta de¡ elemento de servicio S-EXPEDI-TED-DATA, de tipo no confirmado. Puede ser utilizado por cualquiera de las entidades de presentación en cualquier momento de la existencia de la conexión de sesión, si se tiene el servicio de transferencia expedita en el nivel de transporte.
– Gestión de interacciones
Este servicio permite gestionar la interacción entre las entidades de presentación. Hay tres formas de interacción definidas:
1) TWS: Two-Way-Simultaneaus: las dos entidades de presentación pueden enviar y recibir al mismo tiempo,
2) TWA: Two-Way-Alternate: sólo una de las entidades de presentación, la que tenga el turno, puede enviar datos a la otra, que únicamente puede recibir. 3) One-Way: durante toda la conexión de sesión sólo una entidad de presentación puede enviar, y la otra recibe.
Los elementos de servicio S-TOKEN-PLEASE y S_TOKEN-GIVEN respectivamente en una conexión
TWA.
– Sincronización y mantenimiento de la sesión
Para proporcionar un intercambio ordenado de los datos de las entidades de presentación, el nivel de sesión proporciona servicios para:
1) Sincronizar el diálogo, permitiendo que las entidades de sesión puedan reiniciarlo en un estado dado en un punto anterior de¡ diálogo reconocido por ambas partes. Para ello se requiere:
a) Definir e identificar puntos de sincronización pueden ser de dos tipos:
– Marcas principales: permiten a los usuarios de¡ servicio de sesión estructurar el intercambio de información en una serie de unidades de diálogo independientes entre sí. Utiliza el elemento de servicio confirmado S-SYNC-MAJOR.
– Marcas secundarias: se utilizan para estructurar el intercambio de información dentro de unidad de diálogo. La confirmación de cada punto de sincronización secundario es opcional. Utiliza el elemento de servicio S-SYNC-MINOR.
b) Reiniciar la conexión de sesión en un estado definido, en uno de los puntos de resincronización. Permite a los usuarios de¡ servicio de sesión volver atrás en el flujo del diálogo. Utiliza el elemento de servicio S-RESINCRONIZE, de tipo confirmado.
2) mantener las unidades de datos hasta asegurarse de que han sido correctamente transferidas. Para ello, las unidades de datos no son liberadas del nivel de Presentación hasta que las libere explícitamente la entidad emisora. Este servicio se denomina “de cuarentena”.
– Información de excepciones
Este servicio permite a las entidades de presentación notificar o ser notificadas de situaciones excepcionales no cubiertas por otras facilidades, tales como funcionamientos defectuosos de sesión no recuperables. Utiliza los elementos de servicio S – P – EXCEPTION – REPORT, iniciado por proveedor y S_U-EXCEPTION-REPORT, no confirmado.
2.2. FUNCIONES DEL NIVEL SESIÓN Las funciones del nivel de sesión incluyen:
a) Asociación de sesiones con conexiones de transporte. b) Control de flujo para la sesión.
c) Intercambio de datos entre tareas.
d) Apertura, terminación y restablecimiento de las conexiones de sesión. e) Gestión del nivel de sesión y comunicación con las capas adyacentes. f) Control del diálogo (quién, cuándo, duración, half o fui¡-duplex).
g) Recuperación frente a problemas de comunicación durante una sesión sin pérdida de datos.
3. NIVEL DE PRESENTACIÓN
Es responsable de la transferencia concreta de la información contenida en los protocolos de aplicación.
El nivel de aplicación está relacionado con la semántica (el significado de la información intercambiada), mientras que el de presentación se ocupa de los aspectos sintácticos (representación de la información que se intercambia). Esto es, al nivel de aplicación le concierne la semántica de las unidades de protocolo de aplicación enviadas entre
procesos de aplicación, y al nivel de presentación le concierne la representación concreta de esta información.
Así, el propósito de¡ nivel de presentación es proporcionar independencia a los procesos de aplicación de las diferencias en la representación de los datos, esto es, su sintaxis.
Figura 66.2. Relación entre los niveles de aplicación y sesión
En la figura, se observan tres representaciones sintácticas de los datos transferidos entre las entidades aplicación:
1) La sintaxis usada por la entidad que origina los datos.
2) La sintaxis usada por la entidad que los recibe, y
3) La sintaxis usada por el proceso de transferencia.
Un ejemplo similar sería la comunicación entre una persona que sólo hable japonés y otra que únicamente hable español. La sintaxis local en ambas seria el japonés y el español, respectivamente. La sintaxis de transferencia sería japonés, español, o incluso fran-
cés, inglés o cualquier lenguaje que fuera entendido por las entidades de presentación (los traductores) en ambos lados.
3.1. SERVICIOS DEL NIVEL DE PRESENTACIÓN Los servicios que proporciona el nivel de presentación son:
– Facilidad de conexión.
Proporciona la capacidad de establecer una conexión de presentación, utilizando el elemento de servicio
P-CONNECT.
– Facilidad de contexto.
Permite al nivel de presentación gestionar su entorno de transferencia de información de usuario (contexto). El contexto está formado por la sintaxis de transferencia activa y la información de estado de¡ nivel de presentación.
Facilidad de transferencia de información.
Es el medio que utiliza el nivel de aplicación para enviar información entre sus entidades asociadas.
– Facilidades de gestión de¡ dialogo y de sincronización.
Son funciones de paso directo de las facilidades de gestión de¡ diálogo y sincronización de¡ nivel de sesión.
Hacen visibles los servicios de¡ nivel de sesión al nivel de aplicación.
– Facilidad de interrupción.
Proporciona un medio que permita la suspensión y la reanudación de las comunicaciones entre sistemas.
– Facilidad de terminación.
Proporciona el medio de suspender una conexión previamente establecida.
3.2. FUNCIONES DEL NIVEL DE PRESENTACIÓN
1-in con:unto, e!. -,¡ve! d,– rcaliza las siguientes func,;,-res:
a) Funciones generales:
– Solicitud de establecimiento de sesión.
– Negociación y renegociación de la sintaxis de presentación.
– Formateado y transformación de los datos.
– Transformaciones de propósito especial.
– Solicitud de terminación de sesión. b) Direccionamiento y multiplexación. c) Gestión del nivel de presentación.
4. NIVEL DE APLICACIÓN
Es el nivel superior de la arquitectura OS¡ y su propósito es proporcionar un medio para que los procesos de aplicación puedan acceder al entorno OS¡.
Procesos de aplicación
Un proceso de aplicación es un elemento lógico de un sistema que realiza el procesamiento de información requerido para una aplicación específica.
Cuando una aplicación es distribuida, cada parte distribuida de la aplicación constituye un proceso de aplicación.
Los procesos de aplicación distribuidos se comunican entre si por medio de las entidades de aplicación a las que están asociadas, las cuales ejecutan los protocolos de aplicación, y utilizan los servicios de presentación.
Básicamente se pueden distinguir tres categorías específicas de procesos de aplicación:
1) Procesos de aplicación de gestión del sistema: Ejecutan las funciones del sistema necesarias para controlar y supervisar la operación de los sistemas participantes.
2) Procesos de aplicación de gestión de las aplicaciones: Controlan y supervisan la duración de los procesos de aplicación.
3) Procesos de aplicación de usuario: Realizan el procesamiento de la información real para el usuario final,
Aun cuando parte de los recursos del sistema se gestionan localmente, esto es, sin involucrar la cooperación de los distintos sistemas, existen algunas funciones de gestión que sí requieren de la colaboración de distintos sistemas, tales como:
– Información de configuración.
– Arranque/terminación de un sistema remoto.
– Monitorización.
– Diagnósticos.
– Reconfiguración, etc.
La arquitectura OSI considera las funciones de gestión como aplicaciones de un tipo específico. Las entidades de gestión, localizadas en el nivel superior de la arquitectura, pueden usar el conjunto de servicios ofrecido a todas las aplicaciones para realizar las funciones de gestión.
Estas funciones de gestión está organizadas dentro de la arquitectura OS¡ tal como se muestra en la figura.
Figuia 66.3. de las funciones de gestión
En esta figura se ven las tres categorías de procesos de aplicación ya mencionados.
En todo sistema abierto, el nivel de aplicación consta de un conjunto de elementos de servicio, cada de los cuales acepta o procesa peticiones para proporcionar algunas de las capacidades de OS¡ o proporcionar a los procesos de aplicación alguna respuesta como resultado de un estímulo del “entorno de OS¡” (OS¡ Environment- OSIE).
Cualquier subconjunto dado de tales elementos de servicio constituye un único tipo de entidad de aplicación.
Entre los conjuntos de elementos de servicio proporcionados por los diferentes tipos de entidades de aplicación están: el servicio de transferencia de ficheros, el servicio de termina¡ virtual, o el servicio de transferencia y manipulación de tareas.
Por su parte, CCITT ha desarrollado la serie de recomendaciones X.400, que describe el servicio de gestión de mensajes (Message Handling Systems – MHS) [CCITT841.
– Entidades de aplicación
Una entidad de aplicación es la parte de un “proceso de aplicación” que ejecuta los protocolos del nivel de aplicación y proporciona los elementos del servicio de aplicación; son, por tanto, los aspectos de un proceso de aplicación pertenecientes al OSIE los que constituyen una entidad de aplicación.
Cada proceso de aplicación se representa cara a su “par” mediante la entidad de aplicación.
En la estructura de una entidad de aplicación se reconocen dos categorías de elementos de servicio:
1) CASE: Elementos de Servicio de Aplicación Común, y
2) SASE: Elementos de Servicio de Aplicación Específica.
Los CASE proporcionan las capacidades requeridas por los procesos de aplicación para la transferencia de información independientemente de la naturaleza de la aplicación (por ejemplo, estableciendo o terminando una asociación entre procesos de aplicación).
Los SASE proporcionan las capacidades de transferencia de información (por ejemplo, transferencia de ficheros, acceso a base de datos, etc.) o las capacidades para satisfacer las necesidades de procesos de aplicación particulares.
Cada entidad de aplicación puede constar de elementos de servicio de ambas categorías.
Figura 66.4. Estructura de una entidad de aplicación
El elemento de usuario (UE) representa las capacidades necesarias para hacer la interfase entre el resto de los procesos de aplicación y los elementos de servicio del nivel de aplicación.
4.1. SERVICIOS DEL NIVEL DEL APLICACIÓN
El nivel de aplicación proporciona todos los servicios de OS¡ que son directamente utilizados por los procesos de aplicación, ya que es el único nivel del Modelo de Referencia que proporciona servicios directamente a los procesos de aplicación.
Además de la transferencia de información, tales servicios pueden incluir, entre otros, los siguientes:
– Identificación de los usuarios con que se puede establecer comunicación (por un nombre, una dirección o una descripción).
– Determinación de la disponibilidad actual de estos usuarios.
– Establecimiento de autoridad para comunicarse.
– Acuerdo sobre los mecanismo de privacidad.
– Determinación de la metodología de asignación de costes.
– Determinación de la suficiencia de los recursos.
– Determinación de la calidad de servicio aceptable (por ejemplo, tiempos de respuestas, tasa de errores tolerable, etc.).
– Selección de la disciplina de diálogo, incluyendo los procedimientos de iniciación y liberación.
– Acuerdo sobre la responsabilidad en la recuperación de errores.
– Acuerdo en los procedimientos de control de la integridad de los datos.
– Identificación de las restricciones en la sintaxis de los datos (conjuntos de caracteres, estructura datos).
5. PROTOCOLOS DE ALTO NIVEL
5.1. DEFINICION
Un protocolo de transporte ofrece un servicio que permite la transferencia de datos entre dos procesos en forma fiable y controlada. Este servicio es utilizado por otros protocolos para ofrecer a los usuarios de una red un servicio más ajustado a sus necesidades, como por ejemplo, acceso remoto vía termina¡, transferencia de ficheros, entrada remota de trabajos, transferencia de voz digitalizada, etc.
Estos protocolos situados por encima de¡ de transporte se denominan protocolos de alto nivel.
Si bien sus exigencias varían bastante en relación al servicio del protocolo de transporte subyacente, existen algunas que son comunes a la gran mayoría.
Dentro de estos requisitos, destacamos:
– La existencia de direcciones que permiten al usuario acceder al servicio ofrecido por el protocolo de alto nivel a través de un nombre que el nivel de transporte transforma en una dirección.
Disponibilidad de un canal fuera-de-banda, en general de baja capacidad, cuyos datos no están sujetos al control de flujo normalmente impuesto a los datos por el protocolo de transporte. Este canal es necesario para la implementación de una función con las características de una interrupción.
Los protocolos de alto nivel difieren en sus objetivos; sin embargo, también exhiben una serie de características comunes, o por lo menos ciertos aspectos funcionales que deben ser observados por cualquiera de ellos.
Primeramente las unidades de datos intercambiadas entre las entidades participantes son bastante más complejas que las encontradas en los niveles anteriores, incluso el de transporte.
Otro aspecto inherente a los protocolos de alto nivel es la mayor complejidad de los regímenes de control de ejecución entre las entidades participantes. Es decir, su mayor sofisticación permite a las entidades participantes disponer de más posibles alternativas de procedimientos. El protocolo debe procurar que las entidades decidan entre sí, durante el tiempo de ejecución, cuál o cuáles de las posibles alternativas de sincronización serán utilizadas para aquel intercambio específico de información.
5.2. PROTOCOLOS PARA EL SOPORTE DE TERMINALES
Actualmente, los terminales son el modo más frecuente de acceder a un computador. En el contexto de una red, existe gran cantidad de tipos y modelos diferente de sistemas operativos. Por lo tanto, la probabilidad de que un determinado sistema no ofrezca soporte a cierto tipo de termina¡ es bastante alta. Esto disminuye la utilidad de la red ante usuarios potenciales. Los protocolos para el soporte de terminales apuntan a resolver este problema.
Básicamente hay tres formas de acceso remoto vía-terminales, en el contexto de una red.
La primera se produce a través de un computador central. En este caso, se accede localmente al computador vía un termina¡ y se utiliza el computador como intermediario para acceder a un computador remoto a través de la red.
La segunda forma es a través de un “minicomputador central” que hace las veces de un concentrador de terminales.
La tercera forma consiste en acceder a la red directamente.
En la mayor parte de los sistemas operativos, existe un programa para dar soporte a cada tipo de termina¡. Este enfoque no puede extenderse a todo el ámbito de la red, pues si hay m tipos de sistemas operativos y n tipos diferentes de terminales, serían necesarios m X n programas diferentes, para permitir la adaptación de todos los computadores a todos los tipos de terminales.
Para centrar este problema se propusieron dos formas básicas para el soporte de terminales:
a) Parametrización: Todas las diferencias entre los terminales son vistas como pos¡bles parámetros; a través de la selección apropiada de los valores de los diversos parámetros, se consigue dar un soporte adecuado para cada tipo de terminal.
b) Termina¡ Virtual: Define un modelo abstracto de un terminal, llamado Termina¡ Virtual, y cada computador en la red será capaz de dar soporte a este tipo de terminal. Por otro lado, se debe escribir un programa para mapear cada tipo de terminal en el terminal virtual. De este modo, se tendrían que escribir m + n programas en lugar de m X n (m tipos de terminal, n sistemas operativos).
La primera forma fue escogida por el CCITT, en las recomendaciones X.3, X.28 y X.29 CITT 80), adoptadas por varias redes públicas. A continuación describiremos estas recomendaciones.
5.2.1. Recomendaciones X.3, X.28 y X.29 (triple X)
La visión de¡ CCITT sobre cómo un terminal accede a una red se resume en la figura.
Figura 66.5. Acceso a la red vía terminales
Así, un terminal está conectado a la red a través de un PAD (Ensamblador-Desambiador de Paquetes). La recomendación X.3 define los parámetros de¡ PAD. Para comunicarse con el PAD, el terminal (llamado ETD de modo “arranque-parada” por el CCITT) utiliza una interfase definida en la recomendación X.28.
Análogamente, el computador (llamado ETD de modo paquete, PETD) se comunica con el PAD a través de la interfase definida en la recomendación X.29.
Según la recomendación X.3, el PAD realiza ciertas funciones básicas y puede ejecutar otras adicionales, de acuerdo con una selección realizada por el usuario.
Las funciones básicas ofrecidas son: transformación de caracteres en paquetes para el DTE; transformación de campos de paquetes en caracteres para el termina¡; establecimiento, interrupción “reset” y finalización de circuitos virtuales; generación de señales de servicio para el termina¡; envío de paquetes siempre que sea necesario (por ej., “buffer” lleno); transmisión de bits start-stop hacia el terminal; reconocimiento e interpretación de las señales de atención procedentes del termina¡.
5.2.2. Protocolos para el soporte de terminales virtuales
Como fue dicho, este enfoque define un tipo abstracto de termina¡, es decir una abstracción de los diferentes tipos de terminales llamado Termina¡ Virtual (TV).
Dada la gran diversidad de terminales existentes en la práctica, se pueden clasificar en tres categorías principales:
a) Modo continuo (“Scroll mode”): es el tipo más simple de termina¡ y corresponde a los del género teletipo, que no posee capacidad de edición local; a cada tecla apretada, el carácter correspondiente es enviado a la línea.
b) Página: corresponde a los terminales de vídeo, cuyo cursor es capaz de moverse en la pantalla mediante control del programa y del usuario. Frecuentemente, estos terminales poseen capacidad de edición local siendo además posible la transmisión de pantallas enteras de una sola vez.
c) Modo Especial: son terminales del género entrada de datos altamente sofisticados. En general, un formulario especial es exhibido en la pantalla, donde el usuario llena ciertos campos del formulario. Suele tener la capacidad de poder hacer localmente validación de datos.
5.2.2.1. Protocolo TELNET
Históricamente, el primer protocolo que introdujo la idea de un termina¡ virtual fue el
TELNET (Davidson 77), usado en la red ARPA, que se rige por tres principios básicos: (i) La noción de terminal virtual.
(ii) Tratamiento simétrico de terminal y proceso ligado al mismo. (iii) Negociación de opciones.
Una conexión TELNET es concebida como compuesta por dos terminales virtuales ligados de¡ tipo modo continuo, como aparece en la figura.
Figura 66.6. Una conexión TELNET
Cada TV está compuesta de un teclado y de una unidad de presentación; el teclado de uno es conectado a la unidad de presentación de¡ otro, y viceversa.
Este modelo hace que cada lado crea estar conectado a un TV, de manera que este protocolo puede ser usado para conectar dos terminales o dos procesos entre sí, además de la conexión usual entre un terminal y un proceso.
Los comandos TELNET se distinguen de los datos a través de un carácter de escape especial (cuando se desea enviar este carácter como dato se duplica). Después de este carácter, viene otro carácter que codifica el comando propiamente dicho; y, en el caso de negociación de opciones, un tercer carácter indicando cuál es la opción negociada.
5.2.2.2. Protocolos de terminal virtual europeos
Apartir de la propuesta del TELNET, varios investigadores europeos (Schiker 78, Bauwens 78) desarrollaron protocolos para el soporte de terminales virtuales. Su objetivo era considerar una clase más amplia de tipos de terminal (y no sólo los terminales del tipo transmisión continuos, como en el TELNET); inicialmente, no se prestó mucha atención a la simetría del protocolo.
Los protocolos propuestos definen una estructura de datos representando la información que está disponible para el usuario de¡ termina¡. Por ello, esta estructura refleja tanto la estructura de¡ termina¡ como su estado en cada instante. Una consecuencia de esta observación es que la complejidad de la estructura de datos varía conforme a la clase de terminal que utiliza el protocolo (transmisión continua, página, formulario especial). Por ejemplo, la estructura puede ser:
1) Un vector de caracteres (modo continuo).
2) Una matriz de líneas (página).
3) Una matriz de campos de tamaños diferentes (formulario especial).
En el caso (1), la edición de líneas puede hacerse en el local y la línea es enviada al computador. En el caso (2), lo mismo ocurre con las páginas y en el caso (3) con los campos.
Podemos comprobar que se aprovecha la mayor sofisticación del terminal (ya que la unidad de transferencia es mayor y generalmente intercambiada con menor frecuencia si se trata de un terminal más sofisticado) permitiendo una mejor utilización de la capacidad de la red.
5.3. PROTOCOLOS PARA LA TRANSFERENCIA DE FICHEROS
En una red, con una gran cantidad de sistemas operativos diferentes, es bastante común que los usuarios deseen acceder a ficheros de diversos sistemas, generalmente remotos e incluso que transfieran ficheros de un sistema a otro, través de la red.
En un contexto más amplio, el protocolo de transferencia de ficheros (PTA) ofrece un sistema virtual de ficheros (SVA), es decir, un sistema que es uniforme (estándar) para la red. Por lo tanto, el PTA debe proveer funciones que permitan:
1) Convertir formatos de ficheros, generalmente de un formato virtual a un formato local.
2) Manejar ficheros, es decir, crear, eliminar, (re)nombrar, copiar, etc.
Desde el punto de vista del PTA, un fichero es sólo un recipiente de informaciones. En otras palabras: el PTA no se preocupa de la semántica de los datos almacenados en el fichero, en contraste con el sistema de administración de base de datos.
Para la transferencia de ficheros el PTA debe trabajar con tres aspectos básicos:
1) Identificación de¡ fichero.
2) Representación de los datos de¡ fichero.
3) Mecanismos de transferencia de datos.
5.3.1. Los protocolos EFTP y TFTP
Los protocolos EFTP (Easy File Transfer Protocol) (Boggs 80), utilizados en las redes de Xerox y TFTP (Trivial File Transfer Protocol) (Sollins 80) empleados en la red ARPA, son muy sencillos y difieren de la mayoría de los PTAs por asumir que el nivel de transporte ofrece un servicio de datagramas (y no de circuitos virtuales). –
Según estos protocolos, se intercambian datagramas entre pares de direcciones de transporte; estas direcciones se obtienen en el momento de la transmisión del primer datagrama en forma bastante simple. Los datagramas correspondientes a una misma transferencia son siempre numerados a partir de 0 (EFTP) o de 1 (TFTP).
Para describir el funcionamiento de los protocolos, vamos a presentar el contexto normal de operación de cada uno.
La secuencia de eventos para el EFTP es:
1) El usuario envía hacia el puerto 20 el primer paquete de datos del fichero, con el número 0. La identificación del fichero (su nombre) no forma parte del protocolo; el receptor debe ser capaz de identificar el fichero de alguna forma, posiblemente a través de informaciones contenidas en los datos.
2) Cada paquete es confirmado independientemente. El transmisor no puede mandar el paquete n +
1 hasta que el paquete n no haya sido confirmado (ventana l). Si la confirmación no fue recibida después de un cierto tiempo, el paquete es restransmitido. Como la confirmación se puede perder, el receptor debe poder recibir (y detectar) una copia de un paquete ya recibido, ignorando su contenido pero volviendo a enviar una segunda confirmación.
3) Después de la transmisión y confirmación del último paquete de datos se envía un paquete de fin de fichero con el siguiente número de secuencia.
4) El receptor, al recibir este último paquete, debe confirmarlo. Para permitir que el transmisor pueda terminar correctamente, el receptor debe continuar en espera por un período de tiempo adicional, en caso de que la confirmación de este último paquete se
haya perdido. De ser así y como cortesía, el transmisor envía un segundo paquete de fin de fichero, para liberar el receptor, pero este segundo paquete no es ni confirmado ni retransmitido. Si bien este
mecanismo no garantiza que el transmisor tenga la certeza de que la transferencia se completó correctamente, es capaz de resolver la mayor parte de los casos que ocurren en la práctica.
5.3.2. Protocolo FTP de la red ARPA
Este protocolo (Poste¡ 80) fue uno de los primeros PTAs utilizados y es bastante sofisticado, permitiendo la organización más general de procesos, representada en la figura.
Figura 66.7. Organización del protocolo FTP de ARPA
De acuerdo con su definición, la transferencia se hace entre dos estaciones llamadas “FTP usuario”, responsable del control de la transferencia (generación de comandos), y el “FTP servidor”, responsable de la actuación en función de los comandos recibidos.
Cada estación está compuesta por dos procesos, a saber: uno “interpretador de protocolo” (IP), responsable de la administración de la parte de control de la transferencia; y otro de “transferencia de datos” (PTD), responsable de la transferencia de los datos propiamente dicha.
El protocolo FTP asume que un usuario estará controlando la transferencia. Por esta razón, la conexión de control (entre el IP usuario y el IP servidor) es una conexión TELNET, descrita anteriormente. Los comandos FTP son, por lo tanto, cadenas de caracteres ASCII, capaces de ser generados directamente por un usuario en un termina¡. La conexión de control debe existir durante toda la transferencia; no así la de datos, que puede hacerlo parcialmente.
El FTP reconoce cuatro tipos diferentes de representación de datos: ASCII, EBCDIC, byte local de tamaño n, y binario.
Los dos primeros tipos reconocen que el fichero contiene caracteres y permiten la definición de un parámetro adicional. Este parámetro indica si el fichero se imprimirá conteniendo caracteres de control de impresión en el formato ASA (como en el “FORMAT” en FORTRAN), o lo hará con los caracteres del tipo usado en el TELNET (esencialmente ASCII); puede indicar también que el fichero no se destina a impresión (es decir, será almacenado o procesado por un programa, por ejemplo un compilador).
Los formatos de byte local de tamaño n y binario se utilizan para datos que no son caracteres.
Además de la representación de los datos, el FTP reconoce que un fichero puede ser estructurado de tres formas: como una secuencia de bytes, como secuencia de registros o como un conjunto de páginas indexadas individualmente.
Para hacer la transferencia, el FTP ofrece tres formas distintas, independientes de la estructura del fichero. La primera se hace enviando los datos byte a byte sin ninguna información adicional; el fin de la
transmisión será indicado por el cierre de la conexión de datos.
Cuando se desea mayor fiabilidad, se utiliza el modo de transferencia de bloques. Los datos del fichero se dividen en bloques; cada uno es precedido por un encabezamiento que contiene información de control,
tal como longitud, bits indicando fin de registro ( si fuera el caso), o fin de fichero y un contador para un posible reinicio (“restart”) en caso de error.
El tercer modo de transferencia permite la compresión de los datos, además de !os controles usados en el modo de transferencia en bloques. Esta compresión procura aprovechar las repeticiones de caracteres (principalmente blancos y ceros) que ocurren en los ficheros.
La transferencia se controla de la siguiente manera:
1) El usuario (a través de su IP) establece una conexión TELNET con el servidor, usando una dirección conocida. En este punto, existe una conexión FTP,
2) El usuario indica que desea transferir un fichero. Para esto, debe dar identificación de¡ fichero, así como su representación y estructura (que pueden ser dadas por omi sión).
3) El IP usuario envía un comando hacia el IP servidor y, al mismo tiempo indica al PTD usuario que espere en una dirección determinada.
4) El IP servidor, al recibir el comando de transferencia, indica al PTD servidor que establezca una conexión de datos con el PTD usuario, utilizando la dirección recibida en el comando de transferencia. El PTD responsable de hacer todas las conversiones de representación estructura necesarias.
5) Una vez establecida la conexión de datos, los PTDs intercambian mensajes indican do la dirección de transferencia para que ésta pueda empezar.
6) Después de la transferencia, el fin se indica o por el cierre de la conexión de datos
o por un mensaje explícito en la conexión TELNET dependiendo del modo de transmi sión usado.