4.

1 ANALISIS DEL PROTOCOLO FTP

El protocolo FTP viene definido en el RFC 959, tomando apartes de este documento, se hace un anlisis detallado de las caractersticas del FTP las cuales sern mostradas en este captulo. 4.1.1 Objetivos del protocolo FTP Promocionar el uso compartido de ficheros (programas y/o datos). Animar al uso indirecto o implcito (a travs de programas) de servidores remotos. Hacer transparente al usuario las variaciones entre la forma de almacenar ficheros en diferentes ordenadores

El FTP, aunque puede ser utilizado directamente por un usuario en consola, est diseado principalmente para ser usado por programas. Con esta especificacin se intentan satisfacer las diversas necesidades de los usuarios de estaciones de trabajo con un diseo de protocolo simple y fcil de programar. 4.2.2 Evolucin del protocolo FTP El FTP ha pasado por una larga evolucin a travs de los aos. A continuacin se muestran las caractersticas del protocolo desde el tiempo en el cual fue definido.

1971: Primera propuesta de mecanismos para transferencia de ficheros con la RFC 114. 1972: La RFC 354 defini al FTP como un protocolo para transferencia de ficheros en la red ARPANET, cuya funcin principal era la transferencia de ficheros fiable y eficiente permitiendo el uso adecuado de las caractersticas de almacenamiento remotas. 1973: Se publica la RFC 430, el cual present ms comentarios sobre el FTP. Finalmente, se public un documento "oficial" sobre el FTP como RFC 454. 1974: Las RFC 607 y 614 continuaron los comentarios sobre el FTP. La RFC 624 propuso ms cambios en el diseo y pequeas modificaciones. 1975: La RFC 686, trat las diferencias entre todas las primeras y las ltimas versiones del FTP. La RFC 691 present una pequea revisin de la RFC 686, referente al tema de ficheros para imprimir. 1980: Debido al salto del NCP al TCP como protocolo subyacente, naci en la RFC 765 las especificaciones de FTP para su uso sobre TCP. 1985: La RFC 959 est dirigida a la correccin de pequeos errores en la documentacin, a mejorar la explicacin de algunas caractersticas del

protocolo, y a aadir algunas nuevas rdenes opcionales. Esta especificacin es compatible con la anterior edicin (RFC 765). Un programa implementado conforme a la especificacin anterior debera estar automticamente en conformidad con esta especificacin. 4.2.3 Terminologa en FTP Dentro del trabajo realizado, se tienen en cuenta conceptos bsicos para el correcto entendimiento del protocolo; entre estos conceptos, algunos son: ASCII: Se considera tal y como est definido en el manual de protocolos de ARPA-Internet. En el FTP los caracteres ASCII el bit ms significativo es cero. Controles de acceso: Definen los privilegios de acceso del usuario para el uso de un sistema y de los ficheros que hay en l. Son necesarios para evitar el uso no autorizado o accidental de ficheros. Es una obligacin para un proceso servidor FTP utilizar los controles de acceso. Tamao de byte: Hay dos tamaos de byte interesantes en el FTP, el tamao lgico del fichero y el usado para la transmisin de los datos. El tamao de byte utilizado para la transmisin es siempre de 8 bits. Este tamao no es el tamao de byte con el que se guardan los datos ni el tamao lgico para la interpretacin de la estructura de los datos. Conexin de control: Es la ruta de comunicacin entre el USER-PI y el SERVER-PI para el intercambio de rdenes y respuestas. Conexin de datos: Una conexin bidireccional sobre la que se transfieren los datos en un modo y tipo especificados. La conexin se puede establecer entre un server-DTP y un user-DTP o entre dos server-DTP. Puerto de datos: El proceso de transferencia pasiva de datos escucha en el puerto de datos hasta que recibe una conexin del proceso de transferencia activa para abrir la conexin de datos. DTP (Data Transfer Process): Establece y maneja la conexin de datos. Puede ser activo o pasivo. Fin de lnea (EOL): Define la separacin entre lneas. La secuencia consiste en un retorno de carro seguido de un carcter de nueva lnea. Fin de fichero (EOF): Define el final de un fichero en proceso de transmisin. Fin de registro (EOR): Define el final de un registro en proceso de transferencia. Recuperacin de errores: Permite al usuario recuperar el control a partir de ciertas condiciones de error, como un fallo en el servidor o en el proceso de transferencia. Puede implicar el reinicio de la transferencia de un fichero a partir de un cierto punto. rdenes FTP: Un conjunto de rdenes que abarcan la informacin de control que va desde el proceso user-FTP al proceso server-FTP.

Fichero: Se refiere a un conjunto ordenado de datos de longitud arbitraria, definido de forma nica por una ruta. Modo: Se refiere al modo en que se transfieren datos por la conexin de datos. El modo define el formato de los datos durante la transferencia, incluyendo EOR y EOF. NVT (Network Virtual Terminal): Una NVT es un dispositivo imaginario que posee una estructura bsica comn a una amplia gama de terminales reales NVFS (Network Virtual File System): Un concepto que define un sistema de ficheros de red estndar con rdenes estndar y convenciones sobre los nombres de ruta [pathname]. PGINA: Un fichero se puede estructurar como un conjunto de partes independientes llamadas pginas. El FTP soporta la transmisin de ficheros discontinuos como pginas indizadas independientes. NOMBRE DE RUTA [PATHNAME]: El nombre de ruta se define como una cadena de caracteres que el usuario pasa al sistema de ficheros para identificar un fichero. La ruta normalmente contiene nombres de dispositivos y/o directorios y un nombre de fichero. El FTP no especifica an un estndar para indicar una ruta. Cada usuario debe seguir las normas que dictan los sistemas de ficheros implicados en la transferencia para nombrar los ficheros. PI: El Intrprete del Protocolo (Protocol Interpreter). La parte del usuario y del servidor del protocolo tienen distintos papeles que se implementan como un user-PI y un server-PI. REGISTRO: Un fichero secuencial se puede estructurar en un nmero de partes contiguas llamadas registros. El FTP soporta las estructuras de registro, pero un fichero no tiene por qu tener una estructura de registro. RESPUESTA: Una respuesta es un asentimiento (positivo o negativo) enviada por el servidor al usuario a travs de la conexin de control en respuesta a una orden FTP. La forma general de una respuesta es un cdigo de terminacin seguido de una cadena de texto. Los cdigos son usados por los programas y el texto por las personas. SERVER-DTP (SERVER DATA TRANSFER PROCESS): El proceso de transferencia de datos (Data Transfer Process), en su estado normal de "activo", establece una conexin de datos con el puerto de datos que est a la espera. Prepara los parmetros para transferir y almacenar y transfiere los datos cuando as se requiere a travs de su PI. El DTP se puede poner en estado "pasivo" para esperar una conexin, en lugar de iniciarla.

PROCESO SERVER-FTP: Un proceso o un conjunto de ellos que realizan la funcin de transferencia de ficheros en conjuncin con el proceso userFTP y, posiblemente, otro servidor. Las funciones consisten en un intrprete de protocolo (PI) y un proceso de transferencia de datos (DTP). SERVER-PI (SERVER PROTOCOL INTERPRETER): El intrprete de protocolo del servidor "escucha" en el puerto L hasta que recibe una conexin de un user-PI y establece una conexin de comunicaciones para control. Recibe rdenes FTP estndar desde el user-PI, enva respuestas y controla el server-DTP. TIPO: El tipo de representacin de datos usado para transferir y almacenar los datos. El tipo implica ciertas transformaciones a la hora de almacenar y enviar los datos. USUARIO: Una persona o un proceso en su lugar que desea utilizar el servicio de transferencia de ficheros. La persona puede interactuar directamente con el proceso server-FTP, pero se prefiere el uso de un proceso user-FTP ya que el diseo del protocolo est orientado a su utilizacin por autmatas. USER-DTP (USER DATA TRANSFER PROCESS): El Proceso de Transferencia de Datos espera a recibir una conexin en el puerto de datos desde el proceso server-FTP. Si dos servidores estn transfiriendo datos entre ellos, el user-DTP permanece inactivo. PROCESO USER-FTP: Un conjunto de funciones incluyendo un intrprete de protocolo, un proceso de transferencia de datos y una interfaz de usuario que juntos realizan la funcin de transferir ficheros en cooperacin con un proceso server-FTP. La interfaz de usuario permite usar un lenguaje local en el dilogo orden-respuesta con el usuario. USER-PI (USER PROTOCOL INTERPRETER): El intrprete de protocolo de usuario inicia la conexin de control desde su puerto U hasta el proceso server-FTP, enva rdenes FTP y controla el user-DTP si es necesario para la transferencia de ficheros.

EL MODELO FTP El siguiente representa un diagrama de un servicio FTP.

Figura 1: Modelo para el uso del FTP. NOTAS: La conexin de datos es bidireccional. La conexin de datos no tiene por qu existir todo el tiempo.

En el modelo descrito en la Figura 1: El intrprete de protocolo de usuario (user-PI), inicia la conexin de control. La conexin de control sigue el Protocolo Telnet. Las rdenes FTP estndar las genera el user-PI y se transmiten al proceso servidor a travs de la conexin de control. (El usuario puede establecer una conexin de control directa con el server-FTP, desde un terminal TAC por ejemplo, y enviar rdenes FTP estndar, obviando as el proceso userFTP.) Las respuestas estndar se envan desde el server-PI al user-PI por la conexin de control como contestacin a las rdenes. Las rdenes FTP especifican parmetros para la conexin de datos (puerto de datos, modo de transferencia, tipo de representacin y estructura) y la naturaleza de la operacin sobre el sistema de ficheros (almacenar, recuperar, aadir, borrar, etc.).

El user-DTP u otro proceso en su lugar, debe esperar a que el servidor inicie la conexin al puerto de datos especificado y transferir los datos en funcin de los parmetros que se hayan especificado. Se debe resear que el puerto de datos no tiene por qu estar en el mismo ordenador que enva las rdenes FTP a travs de la conexin de control, pero el usuario o el proceso user-FTP debe asegurarse de que se espera la conexin en el puerto de datos indicado. Tambin hay que destacar que la conexin de datos se puede usar simultneamente para enviar y para recibir. En otra situacin, un usuario puede querer transferir ficheros entre dos ordenadores que no son locales. El usuario prepara las conexiones de control con los dos servidores y da las rdenes necesarias para crear una conexin de datos entre ellos. De esta forma, la informacin de control se enva al user-PI pero los datos se transfieren entre los procesos de transferencia de datos de los servidores. A continuacin se muestra un modelo de esta interaccin servidor-servidor.

Figura 2: Modelo de esta interaccin servidor-servidor. El protocolo requiere que las conexiones de control permanezcan abiertas mientras se transfieren datos. Es responsabilidad del usuario solicitar el cierre de las conexiones de control una vez termine de usar el servicio, mientras que el servidor es el encargado de cerrarlas. El servidor puede interrumpir la transferencia de datos si las conexiones de control se cierran sin previa solicitud.

LA RELACIN ENTRE FTP Y TELNET: El FTP usa el protocolo Telnet en la conexin de control. Esto se puede conseguir de dos formas: primera, el user-PI o el server-PI pueden implementar las reglas

del Protocolo Telnet directamente; o, segunda, el user-PI o el server-PI pueden usar el mdulo Telnet que exista en el sistema. La facilidad de implementacin, compartir cdigo y la programacin modular, estn a favor de la segunda aproximacin. La eficiencia y la independencia abogan por la primera aproximacin. En la prctica, el FTP no depende mucho del protocolo Telnet, por ello la primera aproximacin no necesariamente implica gran cantidad de cdigo.

FUNCIONES DE TRANSFERENCIA DE DATOS Los ficheros slo se transmiten por la conexin de datos. La conexin de control se usa para enviar rdenes, que describen la funcin a realizar, y las repuestas a estas rdenes. Varias rdenes se refieren a la transferencia de datos entre ordenadores. Estas rdenes incluyen MODE (modo) que especifica cmo se transmiten los bits de datos y las rdenes STRU (STRUcture, estructura) y TYPE, que se usan para definir la forma de representacin de los datos. La transmisin y la representacin son bsicamente independientes, pero el modo de transmisin flujo depende de la estructura del fichero y si se especifica el modo de transmisin "comprimido", la naturaleza del byte de relleno depende del tipo de representacin. REPRESENTACIN DE DATOS Y ALMACENAMIENTO: Los datos se transfieren desde un dispositivo de almacenamiento en el ordenador que enva los datos a otro en el ordenador que los recibe. A menudo es necesario realizar ciertas transformaciones en los datos porque la representacin de los datos almacenados vara de un ordenador a otro. Los ordenadores que intervienen en la transferencia deberan realizar las transformaciones necesarias entre la representacin estndar y su representacin interna. Nos encontramos con un problema diferente cuando se transmiten datos en forma binaria (no caracteres) entre ordenadores con distinto tamao de palabra. No siempre est claro cmo se deben enviar los datos y como se deben almacenar al recibirlos. En cualquier caso, el usuario debera tener la opcin de especificar la representacin de los datos y las transformaciones realizadas en ellos. Hay que sealar que el FTP proporciona muy limitados tipos de representacin. Las transformaciones necesarias ms all de esta limitada capacidad las deber realizar el usuario directamente. TIPOS DE DATOS: El usuario especifica las representaciones de datos que se manejarn en el FTP. Este tipo puede definir implcita (como es el caso de ASCII y EBCDIC) o explcitamente (como en un tamao de byte local) un tamao de byte para la interpretacin denominado "tamao de byte lgico".

Hay que tener en cuenta que esto no tiene nada que ver con el tamao de byte usado para la transmisin a travs de la conexin de datos, llamado "tamao de byte de transferencia", y no debera haber confusin entre ambos. o TIPO ASCII: Este es el tipo por defecto y debe ser admitido por todas las implementaciones del FTP. Su principal propsito es transferir ficheros de texto, excepto cuando ambos ordenadores encuentran el tipo EBCDIC ms conveniente. El ordenador que enva los datos, los convierte de una representacin de caracteres interna a la representacin estndar. El receptor convertir los datos del tipo estndar a su propia forma interna. De acuerdo con el estndar NVT, la secuencia <CRLF> se debe usar donde sea necesario para indicar el final de una lnea de texto. (Ver el tratamiento de la estructura del fichero al final de la seccin sobre Almacenamiento y Representacin de los Datos.) Usar la representacin estndar NVT-ASCII implica que los datos se deben interpretar como bytes de 8 bits. o TIPO EBCDIC: El propsito de este tipo es la transferencia eficaz entre ordenadores que usan EBCDIC como su representacin de carcter interna. Para la transmisin, los datos estn en forma de caracteres EBCDIC de 8 bits. El cdigo de carcter es la nica diferencia entre la especificacin funcional de los tipos EBCDIC y ASCII. o TIPO IMAGEN: Los datos se envan como bits contiguos que, para la transferencia, estn empaquetados en bytes de transferencia de 8 bits. El receptor debe almacenar los datos como bits contiguos. La estructura del sistema de almacenamiento puede necesitar el rellenado del fichero (o de cada registro, para un fichero estructurado en registros) hasta el lmite pertinente (byte, palabra o bloque). Este rellenado, que debe ser todo ceros, slo puede tener lugar al final del fichero (o de cada registro) y debe haber una forma de identificar los bits de relleno para poder eliminarlos si se obtiene el fichero. La transformacin de relleno debe ser conocida por el usuario para procesar el fichero en el lugar de recepcin. El tipo imagen est indicado para el almacenamiento y obtencin de ficheros y la transferencia de datos binarios. Se recomienda que todas las implementaciones del FTP acepten este tipo.

o TIPO LOCAL: Los datos se transfieren en bytes lgicos del tamao especificado por el segundo parmetro obligatorio, tamao de byte. El valor del tamao de byte debe ser un entero decimal; no hay valor por defecto. El tamao de byte lgico no es necesariamente el mismo que el tamao de byte de transferencia. Si hay diferencia entre los tamaos de byte, entonces los bytes lgicos se deben empaquetar contiguamente, a pesar de los lmites del byte de transferencia y con el relleno necesario al final. Cuando los datos llegan al receptor, se transformarn de una manera independiente del tamao de byte lgico y del ordenador en cuestin. Esta transformacin debe ser inversible (i.e., se obtendr el mismo fichero si se usan los mismos parmetros) y los desarrolladores de la implementacin deben hacerla pblica. o CONTROL DE FORMATO: Los tipos ASCII y EBCDIC llevan un segundo parmetro (opcional); este es para indicar qu tipo de control de formato vertical, si es que lo hay, se asocia con el fichero. Los siguientes tipos de representacin de datos se definen en el FTP: Un fichero de texto se enva a un ordenador por uno de estos tres propsitos: para su impresin, para almacenarlo y posteriormente recuperarlo, o para procesarlo. Si se enva un fichero para imprimirlo, el receptor debe saber cmo est representado el control de formato vertical. En el segundo caso, debe ser posible almacenar el fichero y despus recuperarlo exactamente igual. Por ltimo, debera ser posible enviar un fichero de un ordenador a otro y procesarlo en el receptor sin problemas indebidos. Un formato ASCII o EBCDIC por s solo no satisface estas tres condiciones. Por lo tanto, estos tipos tienen un segundo parmetro especificando uno de los siguientes tres formatos: NO PARA IMPRIMIR [NON PRINT]: Este es el formato por defecto si se omite el segundo parmetro (formato). Se debe admitir en todas las implementaciones del FTP. El fichero no necesita ninguna informacin de formato vertical. Si se pasa a un proceso para imprimir, este proceso puede asumir valores estndar para espaciado y mrgenes.

Normalmente, este formato se usar con ficheros que van a ser procesados o simplemente almacenados. CONTROLES DE FORMATO TELNET: El fichero contiene controles de formato vertical ASCII/EBCDIC (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) que el proceso para imprimir interpretar apropiadamente. <CRLF>, siguiendo exactamente este orden, tambin indica fin-de-lnea. CONTROL DE CARRO (ASA): El fichero contiene caracteres de control de formato vertical ASA (FORTRAN). En una lnea o registro formateado de acuerdo con el estndar ASA, el primer carcter no se imprime. En su lugar, se usa para determinar el movimiento vertical del papel que debera tener lugar antes de que se imprima el resto del registro. El estndar ASA especifica los siguientes caracteres de control: Carcter Espacio 0 1 + Espaciado vertical Mueve el papel una lnea arriba Mueve el papel dos lneas arriba Mueve hasta el comienzo de la sig. Pgina No se mueve, i.e., sobrescribe

Claramente, debe haber alguna manera para el proceso que imprime de distinguir el final de la entidad estructural. Si un fichero tiene estructura de no hay problema; los registros se marcan explcitamente durante la transferencia y el almacenamiento. Si el fichero no tiene estructura de registro, la secuencia fin-de-lnea <CRLF> se usa para separar lneas al imprimir, pero los controles ASA tienen prioridad sobre estos especificadores de formato. ESTRUCTURAS DE DATOS Adems de los diferentes tipos de representacin, el FTP permite especificar la estructura de un fichero. Se definen tres estructuras de fichero en el FTP:

o ESTRUCTURA DE FICHERO: Donde no hay una estructura interna y el fichero se considera como una secuencia continua de bytes de datos. o ESTRUCTURA DE REGISTRO: Donde el fichero est compuesto de registros secuenciales. o ESTRUCTURA DE PGINA: Donde el fichero est compuesto de pginas indizadas independientes. Si no se usa la orden STRU (estructura), se asume por defecto estructura de fichero, pero todas las implementaciones del FTP deben aceptar para ficheros de "texto" las estructuras de fichero y de. La estructura de un fichero afectar al modo de transferencia y a la interpretacin y almacenamiento del fichero. La estructura "natural" de un fichero depende del ordenador que almacena el fichero. Si se quiere realizar una transferencia entre ordenadores tan dispares que sea til, debe haber una forma para que uno reconozca lo que el otro asume por defecto. Con unos ordenadores orientados por naturaleza a ficheros y otros orientados a registros, puede haber problemas si se enva un fichero con una estructura a un ordenador orientado a la otra. Si un fichero de texto se enva con estructura de registros a un ordenador que est orientado a ficheros, entonces ste ltimo debera aplicar internamente una transformacin basada en la estructura de registros. Obviamente, esta transformacin debera ser adecuada, pero, adems, debe ser inversible para que se pueda obtener un fichero idntico usando estructura de registro. En el caso de enviar un fichero con estructura de fichero a un ordenador orientado a registro, surge la cuestin de qu criterio debe usar el ordenador para dividir el fichero en registros que se puedan procesar localmente. Si es necesaria esta divisin, la implementacin del FTP debera usar la secuencia <CRLF> para ficheros de texto ASCII o <NL> para ficheros de texto EBCDIC como separador de registro. Si una implementacin del FTP adopta esta tcnica, debe estar preparada para hacer la transformacin inversa si se recupera el fichero con estructura de fichero. o ESTRUCTURA DE FICHERO: La estructura de fichero se asume por defecto si no se utiliza la orden STRU (eSTRUctura). Si el fichero tiene esta estructura, se considera como una secuencia continua de bytes de datos, sin ninguna estructura interna.

o ESTRUCTURA DE REGISTRO: Todas las implementaciones del FTP deben aceptar la estructura de registro para ficheros de texto, el fichero est formado por registros dispuestos secuencialmente. o ESTRUCTURA DE PAGINA: Para transmitir ficheros discontinuos, el FTP define una estructura de pgina. Los ficheros de este tipo tambin se conocen como ficheros de acceso aleatorio o como ficheros con huecos. En estos ficheros hay a veces otra informacin asociada con el fichero como un todo (por ejemplo, un descriptor de fichero), o con una seccin del fichero (por ejemplo, controles de acceso a pgina) o ambos. En el FTP las secciones del fichero se llaman pginas. Para tratar con varios tamaos de pgina y con la informacin asociada, cada pgina se enva con una cabecera de pgina. Esta cabecera tiene definidos los siguientes campos: LONGITUD DE LA CABECERA: El nmero de bytes lgicos en la cabecera incluyendo este. El tamao mnimo de la cabecera es de 4. NDICE DE PGINA: El nmero lgico de pgina de esta seccin del fichero. Esto no es el nmero de secuencia de transmisin de esta pgina, sino el ndice usado para identificar esta pgina del fichero. TAMAO DE DATOS: El nmero de bytes lgicos que hay en los datos de la pgina. El mnimo es 0. TIPO DE PGINA: Existen los siguientes tipos de pgina: 0 = ltima pgina: Se usa para indicar el final de una transmisin con estructura de pgina. El tamao de cabecera debe ser 4 y el tamao de datos debe ser 0. 1 = Pgina normal: Este es el tipo usado para ficheros paginados simples sin informacin de control de acceso asociada a nivel de pgina. El tamao de la cabecera debe ser 4. 2 = Pgina de descriptor: Este tipo se utiliza para transmitir la informacin descriptiva del fichero considerado como un todo.

3 = Pgina con control de acceso: Este tipo incluye un campo adicional en la cabecera para ficheros paginados con informacin de control de acceso a nivel de pgina. El tamao de la cabecera debe ser 5.

CAMPOS OPCIONALES: Se pueden usar ms campos en la cabecera para proporcionar, por ejemplo, informacin de control por pgina. Todos los campos miden un byte lgico. El tamao de byte lgico se especifica por la orden TYPE.

Una nota de atencin sobre los parmetros: Un fichero debe ser almacenado y recuperado con los mismos parmetros si la versin recuperada debe ser idntica a la versin originalmente transmitida. Por tanto, las implementaciones del FTP deben devolver un fichero idntico al original si los parmetros usados para almacenar y recuperar el fichero son los mismos. 3.2 ESTABLECIENDO CONEXIONES DE DATOS

La mecnica de transferir datos consiste en preparar la conexin de datos en los puertos apropiados y elegir los parmetros para la transferencia. El usuario y los server-DTP tienen ambos un puerto por defecto. El puerto por defecto del proceso de usuario es el mismo que el puerto de la conexin de control. El puerto por defecto del proceso servidor es el puerto adyacente al puerto de la conexin de control. El tamao de byte para la transferencia es de 8 bits. Este tamao slo es relevante para la transferencia de datos; no tiene nada que ver con la representacin de los datos dentro del sistema de ficheros de un ordenador. El proceso de transferencia de datos pasivo (que puede ser un user-DTP o un segundo server-DTP) deber "escuchar" en el puerto de datos antes de enviar una orden de peticin de transferencia. Esta orden determina el sentido de la transferencia de los datos. El servidor, una vez recibida la peticin de transferencia, iniciar la conexin de datos al puerto indicado. Una vez establecida la conexin, la transferencia de datos comienza entre los DTP y el server-PI enva una respuesta de confirmacin al user-PI. Todas las implementaciones del FTP deben soportar el uso de los puertos de datos por defecto y slo el user-PI puede solicitar un cambio a un puerto diferente. Usando la orden PORT, el usuario puede especificar un puerto alternativo. Puede que el usuario quiera volcar un fichero en una impresora o que se obtenga el fichero de un tercer ordenador. En este ltimo caso, el user-PI establece las

conexiones de control con ambos ordenadores. Luego dice a un servidor (mediante una orden FTP) que "escuche" hasta recibir una conexin que el otro iniciar. El user-PI enva aun server-PI una orden PORT indicando el puerto de datos del otro. Finalmente, se envan a ambos las rdenes apropiadas de transferencia. En general, es responsabilidad del servidor mantener la conexin de datos (abrirla y cerrarla). La excepcin a esto se produce cuando el user-DTP enva los datos en un modo de transferencia que requiere cerrar la conexin para indicar EOF. El servidor DEBE cerrar la conexin de datos bajo las siguientes circunstancias: El servidor ha terminado de enviar datos en un modo de transferencia que requiere un cierre para indicar EOF. El servidor recibe una orden ABORT del usuario. Una orden del usuario especifica un nuevo puerto. La conexin de control se cierra correctamente o de cualquier otro modo. Se produce una condicin de error irrecuperable.

En cualquier caso, el cierre es una opcin del servidor que se debe indicar al proceso de usuario slo mediante una respuesta 250 226.

3.3 MANEJO DE LA CONEXION DE DATOS

PUERTOS DE LA CONEXIN DE DATOS POR DEFECTO: Todas las implementaciones del FTP deben soportar el uso de los puertos de datos por defecto y slo el user-PI puede iniciar el uso de otros puertos. NEGOCIANDO PUERTOS DE DATOS DISTINTOS A LOS QUE HAY POR DEFECTO: El user-PI puede especificar un puerto de datos diferente por su parte con la orden PORT. El user-PI puede solicitar al servidor la localizacin de un puerto en el propio servidor con la orden PASV. Como una conexin est definida por el par de direcciones, cualquiera de estas acciones es suficiente para tener una conexin de datos diferente, pero se permite usar ambas rdenes para utilizar nuevos puertos en los dos lados de la conexin. REUTILIZACIN DE LA CONEXIN DE DATOS: Cuando se usa el modo flujo para transferencia de datos el final de fichero se indica cerrando la

conexin. Esta causa un problema si se van a transferir varios ficheros en la sesin, debido a la necesidad que tiene el TCP de mantener el registro de la conexin por un tiempo de espera para garantizar una comunicacin fiable. Por eso la conexin no puede reabrirse inmediatamente. Hay dos soluciones a este problema. La primera es negociar un puerto diferente al que hay por defecto. La segunda es usar otro modo de transmisin. Un comentario sobre los modos de transmisin: El modo flujo de transferencia es implcitamente poco fiable porque no se puede determinar si la conexin se ha cerrado prematuramente o no. Los otros modos de transferencia (de bloque, comprimido) no cierran la conexin para indicar el final de fichero. Los datos que enva el FTP a travs de ellos hacen que se pueda determinar el final de fichero. Por eso, usando estos modos, se puede dejar la conexin de datos abierta para transferir ms de un fichero.

3.4 MODOS DE TRANSMISION:

Otro aspecto a considerar en la transferencia de datos es la eleccin apropiada del modo de transmisin. Hay tres modos: Uno que formatea los datos y permite reiniciar la transmisin; otro que adems comprime los datos para una transferencia eficaz; y el ltimo que pasa los datos sin apenas procesarlos. En este ltimo caso, el modo interacta con el atributo de estructura para determinar el tipo de proceso. En el modo comprimido, el tipo de representacin determina el byte de relleno. Todas las transferencias de datos se deben complementar con un fin-de-fichero (EOF, end-of-file) que se puede indicar explcita o implcitamente cerrando la conexin de datos. Para ficheros con estructura de registro, todos los indicadores de fin-de-registro (EOR) son explcitos, incluyendo el ltimo. Para ficheros transmitidos con estructura de pgina, se usa una pgina con el indicador de ltima pgina activado. NOTA: En el resto de esta seccin, byte significa "byte de transferencia" excepto donde se indique explcitamente. Para estandarizar la transferencia, el ordenador que enva los datos trasladar sus caracteres de fin de lnea o de fin de registro a la representacin indicada por el modo de transferencia y la estructura del fichero, y el receptor realizar la traduccin inversa a su representacin interna. Por eso, la informacin de fin-deregistro se puede transferir como un cdigo de control de dos bytes en modo flujo o como un bit activado en un descriptor de modo bloque o comprimido.

El fin-de-lnea en un fichero ASCII o EBCDIC no estructurado en registros se debera indicar con <CRLF> o <NL> respectivamente. Debido a que estas transformaciones implican un trabajo extra para algunos sistemas, sistemas idnticos que transfieren entre ellos un fichero de texto no estructurado en registros pueden preferir usar una representacin binaria y modo flujo para la transferencia. Se definen los siguientes modos de transmisin en el FTP:

3.4.1 MODO FLUJO

Los datos se transmiten como un flujo de bytes. No hay ninguna restriccin en el tipo de representacin usado; se permiten estructuras de registro. En un fichero estructurado en registros, EOR y EOF se indicarn por un cdigo de control de dos bytes. El primer byte del cdigo de control consistir en todo unos, el carcter de escape. El segundo tendr el bit de orden ms bajo activado y ceros en el resto para EOR y el segundo bit de orden ms bajo activado para EOF; esto es, el byte valdr 1 para EOR y 2 para EOF. EOF y EOR se pueden indicar conjuntamente en el ltimo byte transmitido activando los dos bits ms bajos. Si se pretende transmitir un byte con todo unos como dato, se debera repetir en el segundo byte del cdigo de control. Si la estructura es de fichero, se indica el EOF cuando el ordenador que enva los datos cierra la conexin de datos y todos los bytes son bytes de datos.

3.4.2 MODO BLOQUE

El fichero se transmite como una serie de bloques de datos precedidos por uno o ms bytes cabecera. Los bytes de la cabecera contienen un campo contador y un cdigo descriptor. El campo contador indica la longitud total del bloque de datos en bytes, indicando as el inicio del siguiente bloque de datos (no hay bits de relleno). El cdigo descriptor define: ltimo bloque del fichero (EOF), ltimo bloque del registro (EOR), indicador de reinicio o datos sospechosos. Este ltimo cdigo NO es para controlar errores desde el propio FTP. Su uso est motivado por el deseo de ciertos sitios que intercambian cierto tipo de informacin (por ejemplo, datos ssmicos o meteorolgicos) enviando y recibiendo todos los datos a pesar de que

pueda haber errores locales (como errores leyendo una cinta magntica). Se permiten estructuras de registro y se puede usar cualquier tipo de representacin. La cabecera consiste en tres bytes. De los 24 bits de informacin, los 16 ms bajos representan un contador de bytes y los 8 ms altos representan cdigos de descripcin como se muestra a continuacin.

Cabecera de Bloque Los cdigos de descripcin se indican mediante bits en el byte de descripcin. Hay asignados 4 cdigos, donde cada nmero de cdigo es el valor decimal del correspondiente bit en el byte.

Cdigo Significado 128 El final del bloque de datos es EOR 64 El final del bloque de datos es EOF 32 Puede haber errores en el bloque 16 El bloque de datos es un marcador de reinicio Con esta codificacin, ms de una condicin codificada puede ocurrir para un bloque en particular. Se pueden activar tantos bits como sea necesario. El indicador de reinicio est incluido en el flujo de datos como un nmero de 8 bits representando caracteres imprimibles en el lenguaje usado en la conexin de control (por ejemplo, NVT-ASCII). <SP> (espacio en el lenguaje apropiado) no se debe usar dentro de un indicador de reinicio. Por ejemplo, para transmitir un indicador de seis caracteres, se debera enviar lo siguiente:

3.4.3 MODO COMPRIMIDO

Hay tres clases de informacin a enviar: Datos normales, enviados en una cadena de bytes; datos comprimidos, formados por repeticiones o relleno; e informacin de control, enviada en una secuencia de escape de dos bytes. Si se enva n>0 bytes (hasta 127) de datos normales, estos n bytes van precedidos de un byte con el bit ms a la izquierda a cero y los 7 bits ms a la derecha contienen el nmero n.

Para comprimir una cadena de n repeticiones del byte de datos d, se envan los 2 siguientes bytes:

Una cadena de n bytes de relleno se puede comprimir en un solo byte, donde el byte de relleno vara segn el tipo de representacin. Si el tipo es ASCII o EBCDIC, el byte de relleno es <SP> (espacio, cdigo ASCII 32, cdigo EBCDIC 64). Si el tipo es imagen o byte local, el relleno es un byte cero.

La secuencia de escape est formada por dos bytes, el primero de los cuales es el byte de escape (todo ceros) y el segundo contiene cdigos de descripcin segn lo definido para el modo bloque. Los cdigos tienen el mismo significado que anteriormente y se aplican a las cadenas de bytes transmitidas con xito. El modo comprimido es til para obtener un ancho de banda adicional en transmisiones muy largas con un coste extra de CPU muy pequeo.

3.5 RECUPERACION DE ERRORES Y REINICIO

No hay nada que detecte bits perdidos o alterados en las transmisiones de datos; este nivel de control de errores lo maneja el TCP. Sin embargo, se proporciona un medio para recomenzar transferencia para proteger a los usuarios de fallos graves en el sistema (incluyendo fallos de un ordenador, un proceso FTP o de la red usada).

Slo est definido el procedimiento de reinicio para los modos de transferencia de bloque y comprimido. Requiere que el que enva datos inserte un cdigo marcador especial en el flujo de datos con informacin que indique por dnde vamos. Esta informacin slo tiene significado para el ordenador que enva los datos, pero debe consistir en caracteres imprimibles en el lenguaje negociado o por defecto de la conexin de control (ASCII o EBCDIC). El indicador puede representar una cuenta de los bits, los registros o cualquier otra informacin por la que un sistema pueda identificar un punto de control. El receptor de los datos, si implementa el procedimiento de reinicio, debera guardar la correspondiente posicin de este marcador en el sistema receptor y devolver esta informacin al usuario. En el caso de un fallo del sistema, el usuario puede reiniciar la transferencia de datos identificando el ltimo marcador recibido con el procedimiento de recomenzar del FTP. El siguiente ejemplo ilustra el uso de este procedimiento: El que enva datos inserta un bloque marcador apropiado en el flujo de datos en un punto conveniente. El que recibe marca el correspondiente punto en sus sistemas de ficheros y proporciona al usuario informacin del ltimo marcador recibido, ya sea directamente o por la conexin de control en una respuesta 110 (dependiendo de quin enve el fichero). Si ocurre un error del sistema, el usuario o proceso reinicia el servidor en el ltimo punto que este indic enviando la orden recomenzar con el marcador del servidor como argumento. La orden se transmite por la conexin de control y es seguida inmediatamente por la orden (ya sea RETR, STOR o LIST) que se estaba ejecutando cuando ocurri el error.

4. FUNCIONES DE TRANSFERENCIA DE FICHEROS

El canal de comunicacin entre el user-PI y el server-PI se establece como una conexin TCP desde el usuario al puerto estndar. El intrprete de protocolo de usuario es responsable de enviar rdenes FTP e interpretar las respuestas recibidas; el server-PI interpreta las rdenes, enva respuestas y controla su DTP para establecer la conexin de datos y transferirlos. Si el proceso de transferencia pasiva es el user-DTP, entonces est controlado a travs del protocolo interno del ordenador donde se ejecuta el user-DTP; si es otro server-DTP, est controlado a travs de rdenes recibidas en su PI desde el user-PI.

4.1 ORDENES FTP

4.1.1 ORDENES DE CONTROL DE ACCESO

Las siguientes rdenes especifican identificadores de control de acceso. NOMBRE DE USUARIO (USER): El argumento es una cadena Telnet que identifica al usuario. Esta identificacin es la que requiere el servidor para acceder a su sistema de ficheros. Normalmente esta ser la primera orden a transmitir una vez establecida la conexin de control (algunos ordenadores lo pueden requerir). El servidor puede requerir informacin adicional como una contrasea y/o cuenta. Los servidores pueden permitir una nueva orden USER en cualquier momento para cambiar el control de acceso y/o la informacin de la cuenta. Esto tiene el efecto de descartar cualquier informacin anterior sobre usuario, contrasea y cuenta y comienza la secuencia de acceso otra vez. Todos los parmetros de la transferencia permanecen sin cambios y cualquier transferencia de fichero en curso se completa bajo los anteriores parmetros de control de acceso. CONTRASEA (PASS): El argumento es una cadena Telnet especificando la contrasea del usuario. Esta orden debe ir inmediatamente precedida por la orden USER y, para algunos ordenadores, completa la identificacin del usuario para el control de acceso. Como la informacin de la contrasea es un dato confidencial, es preferible, en general, "enmascararla" o evitar mostrarla en pantalla. Por tanto es responsabilidad del proceso user-FTP el ocultar la informacin sobre la contrasea. CUENTA (ACCT): El argumento es una cadena Telnet identificando la cuenta del usuario. Esta orden no est necesariamente relacionada con la orden USER, ya que algunos ordenadores pueden requerir una cuenta para acceder y otros slo para cierto tipo de acceso, como almacenar ficheros. En este ltimo caso, la orden se puede enviar en cualquier momento. Hay cdigos de respuesta para diferenciar automticamente estos casos: Cuando se requiere informacin de la cuenta, la respuesta a una orden PASS correcta es el cdigo 332. Por otra parte, si NO se requiere esta informacin, la respuesta a una orden PASS correcta es 230; y si la cuenta se requiere para una orden enviada ms tarde, el servidor debera devolver una respuesta 332 o una 532 dependiendo de qu almacene o descarte la orden, respectivamente. CAMBIO DE DIRECTORIO DE TRABAJO (CWD): Esta orden permite al usuario trabajar en un directorio o conjunto de datos [data set] diferente para almacenar o recuperar informacin sin alterar su informacin de entrada o de cuenta. Los parmetros de transferencia permanecen sin

cambios. El argumento es un nombre de ruta especificando el directorio o alguna otra agrupacin de ficheros dependiente del sistema. CAMBIAR AL DIRECTORIO PADRE (CDUP): Esta orden es un caso especial de CWD y se incluye para simplificar la implementacin de programas para transferir rboles de directorios entre sistemas operativos que tienen diferentes formas de nombrar al directorio padre. Los cdigos de respuestas debern ser idnticos a los de CWD. MONTAR ESTRUCTURA (SMNT): Esta orden permite al usuario montar un sistema de ficheros diferente sin alterar su informacin de entrada o de cuenta. Los parmetros de transferencia permanecen sin cambios. El argumento es un nombre de ruta especificando un directorio o alguna otra agrupacin de ficheros dependiente del sistema. REINICIALIZAR (REIN): Esta orden termina una orden USER, descargando todos los datos del entrada/salida y la informacin de cuenta, excepto que si hay alguna transferencia en proceso permite que termine. Todos los parmetros se inician con sus valores por defecto y la conexin de control se deja abierta. El estado alcanzado es idntico al que se tiene inmediatamente despus de abrir la conexin de control. Posiblemente se espere una orden USER a continuacin de sta. DESCONECTAR (QUIT): Esta orden termina una orden USER y si no hay en proceso ninguna transferencia, cierra la conexin de control. Si hay una transferencia de fichero en proceso, la conexin permanecer abierta hasta que el servidor enve una respuesta con el resultado de la transferencia y luego se cierra. Si el proceso de usuario est transfiriendo ficheros para varios usuarios (USERs) pero no quiere cerrar la conexin y reabrirla para cada usuario, se debera usar el comando REIN en lugar de QUIT. Un cierre inesperado de la conexin de control provoca que el servidor acte como si hubiera recibido las rdenes interrumpir (ABOR) y desconectar (QUIT).

4.1.2 ORDENES DE PARAMETROS DE TRANSFERENCIA

Todos los parmetros de transferencia de datos tienen valores por defecto y las rdenes que especifican valores para ellos slo se deben utilizar si se van a cambiar los parmetros por defecto. El valor por defecto es el ltimo valor especificado o, si no se ha especificado ninguno, el valor por defecto estndar es el que se indica aqu. Esto implica que el servidor debe "recordar" los valores por defecto aplicables. Las rdenes pueden ir en cualquier orden, pero deben

preceder a la transferencia. Las siguientes rdenes especifican parmetros de transferencia de datos: PUERTO DE DATOS (PORT): El argumento es una especificacin ordenador-puerto para el puerto que ser usado en la conexin de datos. Hay valores por defecto tanto para el puerto de usuario como para el del servidor y, bajo circunstancias normales, esta orden y su respuesta no son necesarias. Si se usa esta orden, el argumento es la concatenacin de una direccin IP (32 bits) y un puerto TCP (16 bits). Esta informacin est repartida en campos de 8 bits y el valor de cada campo se transmite como un nmero decimal (representado como una cadena de caracteres). Los campos estn separados por comas. Una orden PORT podra ser algo as: PORT h1,h2,h3,h4,p1,p2 Donde h1 es el nmero decimal correspondiente a los 8 bits ms altos de la direccin IP del ordenador. PASIVO (PASV): Esta orden solicita al server-DTP que "escuche" en un puerto de datos (que no es el puerto por defecto) y espere a recibir una conexin en lugar de iniciar una al recibir una orden de transferencia. La respuesta a este comando incluye la direccin IP y el puerto donde este servidor est esperando a recibir la conexin. TIPO DE REPRESENTACION (TYPE): El argumento especifica un tipo de representacin tal y como se describi en la seccin Representacin de Datos y Almacenamiento. Algunos tipos requieren un segundo parmetro. El primer parmetro es un nico carcter Telnet y el segundo, para ASCII y EBCDIC, tambin; el segundo parmetro para tamao de byte local es un entero decimal. Los parmetros estn separados por un <SP> (espacio, cdigo ASCII 32). Se asignan los siguientes cdigos para tipos:

La representacin por defecto es ASCII no para imprimir. Si se cambia el parmetro de formato y ms tarde slo el primer argumento, el formato vuelve a ser el inicial por defecto (no para imprimir). ESTRUCTURA DEL FICHERO (STRU): El argumento es un nico carcter Telnet especificando una estructura de fichero. Existen los siguientes cdigos para la estructura: F - Fichero (sin estructurar en registros) R - Estructurado en registros P - Estructurado en pginas La estructura por defecto es Fichero. MODO DE TRANSFERENCIA (MODE): El argumento es un nico carcter Telnet especificando un modo de transferencia. Los posibles cdigos son los siguientes: S - Flujo B - Bloque C - Comprimido El modo por defecto es Flujo.

4.1.3 ORDENES DE SERVICIO FTP

Las rdenes de servicio FTP definen la transferencia del fichero o la funcin del sistema de ficheros que requiere el usuario. El argumento normalmente ser un nombre de ruta. La sintaxis del nombre de ruta debe seguir las convenciones del servidor (con valores estndar por defecto aplicables) y las convenciones del lenguaje usado en la conexin de control. Se sugiere que por defecto se utilice el ltimo dispositivo, directorio o nombre de fichero o el valor por defecto para los usuarios locales. Las rdenes pueden enviarse en cualquier secuencia, excepto que la orden "renombrar" debe ir seguida por una "renombrar a" y la orden "recomenzar" debe ir seguida por la orden de servicio interrumpida (por ejemplo, STOR o RETR).

Cuando se transfieren datos se debe hacer siempre a travs de la conexin de datos, excepto para algunas respuestas informativas. Las siguientes rdenes especifican peticiones de servicio FTP: RECUPERAR (RETR): Esta orden hace que el server-DTP transfiera una copia del fichero especificado en el nombre de ruta al proceso que est al otro lado de la conexin de datos. El estado y el contenido del fichero en el servidor debe permanecer tal y como estaba. ALMACENAR (STOR): Esta orden hace que el server-DTP lea los datos transferidos por la conexin de datos y los guarde en un fichero en el servidor. Si el fichero especificado en el nombre de ruta existe en el servidor, su contenido se debe reemplazar con los datos recibidos. Se crea un fichero nuevo en el servidor si el indicado no exista ya. ALMACENAR UNICO (STOU): Esta orden se comporta igual que STOR slo que el fichero resultante se crea en el directorio actual con un nombre nico para ese directorio. La respuesta 250 Transferencia iniciada debe incluir el nombre generado. AADIR (con creacin) (APPE): Esta orden hace que el server-DTP reciba datos a travs de la conexin de control y los guarde en un fichero en el servidor. Si el fichero especificado en el nombre de ruta existe, los datos se aaden a ese fichero; si no, se crea un fichero nuevo en el servidor. SOLICITAR ESPACIO (ALLO): Esta orden puede ser necesaria para que algunos servidores reserven suficiente espacio de almacenamiento para recibir el nuevo fichero. El argumento debe ser un entero decimal indicando el nmero de bytes (usando el tamao de byte lgico) de almacenamiento que se deben reservar. Para ficheros enviados con estructura en registros o pginas, puede ser necesario enviar el tamao mximo de registro o pgina; esto se indica con un entero decimal como segundo argumento de la orden. Este segundo argumento es opcional, pero cuando se utilice, debe estar separado del primero por los caracteres Telnet <SP> R <SP>. A continuacin de esta orden se deber indicar una orden STOR o APPE. La orden ALLO debera tratarse como la orden NOOP (no operacin) por los servidores que no necesitan conocer de antemano el tamao del fichero y aquellos servidores que slo interpreten el tamao mximo de registro o pgina deberan admitir un valor intil como primer argumento e ignorarlo. RECOMENZAR (REST): El argumento representa un marcador del servidor a partir del cual debe recomenzar la transferencia. La orden no realiza la transferencia del fichero, pero hace que el puntero de lectura o escritura del

fichero se site a continuacin del punto indicado. A continuacin de esta orden se debe enviar la orden de servicio FTP apropiada que har que contine la transferencia del fichero. RENOMBRAR DE (RNFR): Esta orden indica el fichero que queremos cambiar de nombre en el servidor. Debe ir inmediatamente seguida de la orden "renombrar a" con el nuevo nombre para el fichero. RENOMBRAR A (RNTO): Esta orden especifica el nuevo nombre para el fichero indicado mediante el comando RNFR. Las dos rdenes seguidas hacen que el fichero cambie de nombre. INTERRUMPIR (ABOR): Este comando pide al servidor que interrumpa la orden de servicio FTP previa y cualquier transferencia de datos asociada. La orden de interrupcin puede requerir alguna "accin especial", tratada ms adelante, para forzar el reconocimiento de la orden por el servidor. No se har nada si la orden anterior ha finalizado (incluyendo la transferencia de datos). El servidor no cierra la conexin de control, pero puede que s cierre la conexin de datos. Hay dos posibles casos para el servidor al recibir esta orden: La orden de servicio FTP est ya terminada An est en ejecucin.

En el primer caso, el servidor cierra la conexin de datos (si est abierta) y devuelve una respuesta 226 indicando que la orden de interrumpir se ha procesado correctamente. En el segundo caso, el servidor interrumpe el servicio FTP en proceso y cierra la conexin de datos, devolviendo una respuesta 426 para indicar que la solicitud de servicio termin anormalmente. Luego, el servidor enva una respuesta 226 para indicar que la orden de interrumpir se ha procesado correctamente. BORRAR (DELE): Esta orden borra en el servidor el fichero indicado en el nombre de ruta. Si se quiere tener un nivel extra de proteccin (del tipo "Seguro que quiere borrar el fichero?"), la debera proporcionar el proceso user-FTP. BORRAR DIRECTORIO (RMD): Esta orden borra en el servidor el directorio indicado. CREAR DIRECTORIO (MKD): Esta orden crea el directorio indicado en el servidor. MOSTRAR EL DIRECTORIO DE TRABAJO (PWD): Esta orden hace que el servidor nos devuelva en la respuesta el nombre del directorio actual.

LISTAR (LIST): Esta orden hace que el servidor enve una listado de los ficheros a travs del proceso de transferencia de datos pasivo. Si el nombre de ruta u otra agrupacin de ficheros, el servidor debe transferir una lista de los ficheros en el directorio indicado. Si el nombre de ruta especifica un fichero, el servidor debera enviar informacin sobre el fichero. Si no se indica argumento alguno, implica que se quiere listar el directorio de trabajo actual o directorio por defecto. Los datos se envan a travs de la conexin de datos con tipo ASCII o EBCDIC. (El usuario se debe asegurar del tipo con TYPE). Como la informacin sobre un fichero puede variar mucho de un sistema a otro, es muy difcil que sta pueda ser procesada automticamente, pero puede ser til para una persona. LISTAR NOMBRES (NLST): Esta orden hace que se enve un listado de directorio desde el servidor. El nombre de ruta indica un directorio u otra agrupacin de ficheros especfica del sistema; si no hay argumento, se asume el directorio actual. Los datos se transfieren en formato ASCII o EBCDIC a travs de la conexin de datos separados unos de otros por <CRLF> o <NL>. (Una vez ms el usuario se debe asegurar con TYPE). La funcin de esta orden es devolver informacin que pueda ser usada por un programa para procesar posteriormente los ficheros automticamente. Por ejemplo, implementando una funcin que recupere varios ficheros. PARAMETROS DEL SISTEMA (SITE): Esta orden la usa el servidor para proporcionar servicios especficos propios de su sistema que son fundamentales para transferir ficheros pero no lo suficientemente universales como para ser incluidos como rdenes en el protocolo. La naturaleza de este servicio y la especificacin de su sintaxis se puede obtener como respuesta a una orden HELP SITE. SISTEMA (SYST): Esta orden devuelve el tipo de sistema operativo del servidor. La respuesta debe tener como primera palabra uno de los nombres de sistema. ESTADO (STAT): Esta orden hace que el servidor nos enva una respuesta con su estado a travs de la conexin de control. La orden se puede enviar durante la transferencia de un fichero (junto con las seales Telnet IP y Synch) en cuyo caso el servidor responder con el estado de la operacin en progreso, o se puede enviar entre transferencias de ficheros. En este ltimo caso, la orden puede llevar un argumento. Si el argumento es un nombre de ruta, la orden es similar a LIST, excepto que los datos se devolvern por la conexin de control. Si no hay ningn argumento, el servidor devolver informacin general del estado del proceso servidor

FTP. Esto debera incluir los valores actuales de los parmetros de transferencia y el estado de las conexiones. AYUDA (HELP): Esta orden hace que el servidor enve informacin sobre la implementacin del FTP a travs de la conexin de control. La orden puede tener un argumento que debe ser un nombre de orden y as devuelve informacin ms especfica como respuesta. La respuesta es de tipo 211 214. Se sugiere que se permita el uso de HELP antes del comando USER. El servidor puede usar esta respuesta para especificar parmetros dependientes del sistema, por ejemplo, en respuesta a HELP SITE. NO OPERACION (NOOP): Esta orden no afecta a ningn parmetro ni orden introducida previamente. No hace nada ms que provocar que el servidor enve una respuesta OK.

El Protocolo de Transferencia de Ficheros sigue la especificacin del Protocolo Telnet en todas las comunicaciones a travs de la conexin de control. Las rdenes FTP se pueden dividir en aquellas que indican identificadores de control de acceso, parmetros de transferencia de datos y peticiones de servicio FTP. Algunas rdenes (como ABOR, STAT y QUIT) se pueden enviar por la conexin de control cuando hay una transferencia en proceso. Puede que algunos servidores no sean capaces de gestionar las conexiones de control y de datos simultneamente, en cuyo caso puede ser necesaria alguna accin especial para captar la atencin del servidor. Se recomienda insistentemente esta forma: Se inserta la seal Telnet "Interrumpir Proceso" (IP) en la conexin de control. Se enva la seal Telnet "Synch". Se enva el comando (p.e., ABOR) por la conexin de control. El intrprete de protocolo del servidor, despus de recibir la seal "IP", lee de la conexin de control UNICAMENTE UN COMANDO. (Para otros servidores, puede que esto no sea necesario, pero el hacerlo no tendr ninguna repercusin.)

4.2 RESPUESTAS FTP

Las respuestas a rdenes del FTP estn pensadas para asegurar la sincronizacin entre peticiones y acciones en el proceso de transferencia de ficheros y para garantizar que el proceso de usuario siempre conoce el estado del servidor. Cada

orden debe generar por lo menos una respuesta, aunque puede haber ms de una; en este ltimo caso, las diferentes respuestas se deben distinguir fcilmente. Adems, algunos comandos deben ocurrir en secuencia, como USER, PASS y ACCT o RNFR y RNTO. Las respuestas muestran la existencia de un estado intermedio si todos los comandos anteriores han ido correctamente. Un error en cualquier punto de la secuencia implica que se debe iniciar de nuevo desde el principio. Una respuesta FTP consiste en un nmero de tres cifras (transmitido como tres caracteres alfanumricos) seguidos de texto. El nmero se proporciona para su uso por autmatas que deben determinar el prximo estado; el texto va dirigido a las personas. Se pretende que el nmero contenga suficiente informacin codificada como para que el intrprete de protocolo de usuario no necesite examinar el texto y pueda o bien descartarlo o bien mostrarlo al usuario. En particular, el texto puede depender del servidor y, por tanto, puede variar en cada cdigo de respuesta. Una respuesta debe contener el cdigo de 3 dgitos, seguidos de espacio <SP>, seguido de una lnea de texto (en la que hay definido una longitud mxima), y termina con el cdigo Telnet de fin de lnea. Habr casos en los que el texto es mayor que una lnea. En estos casos el texto debe ir marcado para que el proceso de usuario sepa cuando ha terminado la respuesta y haga otras cosas. Esto requiere de un formato especial en la primera lnea para indicar que hay ms y otro en la ltima lnea para indicar lo propio. Al menos una de estas debe contener el cdigo de respuesta apropiado para indicar el estado de la transaccin. Para satisfacer a todos, se ha decidido que ambas, la primera y la ltima lnea, deben contener el mismo cdigo. Por tanto, el formato para respuestas multi-lnea consiste en que la primera lnea empieza con el cdigo de respuesta requerido seguido inmediatamente de un guin, "-" (tambin es el signo menos), seguido del texto. La ltima lnea empezar con el mismo cdigo, seguido inmediatamente por un espacio <SP>, opcionalmente texto, y el cdigo Telnet de fin de lnea. Por ejemplo: 123 - Primera lnea Segunda lnea 234 Una lnea que comienza con nmeros 123 La ultima lnea El proceso de usuario slo necesita buscar la segunda ocurrencia del mismo cdigo de respuesta, seguido de <SP> (espacio), al principio de una lnea. Si una

lnea intermedia comienza con un nmero de tres dgitos, el servidor debe desplazar ese nmero para evitar confusiones. Este esquema permite que se usen los procedimientos estndar del sistema para la informacin de respuesta (como, por ejemplo, para STAT), con las lneas primera y ltima aadidas "artificialmente". En casos raros en los que estos procedimientos generen tres dgitos y un espacio al principio de cualquier lnea, el principio de cada lnea de texto se debera desplazar con algn texto neutral, como espacios. Este esquema asume que las respuestas multilnea no pueden estar anidadas. Cada tres dgitos de la respuesta tienen un significado especial. Se pretende permitir un rango de respuestas desde muy simple a muy sofisticado para el proceso de usuario. El primer dgito denota si la respuesta es buena, mala o incompleta. (Refirindonos al diagrama de estado), un proceso de usuario poco sofisticado podr determinar su prxima accin simplemente examinando el primer dgito. Un proceso de usuario que quiera conocer aproximadamente el tipo de error ocurrido (por ejemplo, error del sistema de ficheros o error de sintaxis) puede examinar el segundo dgito, reservando el tercero para una mayor precisin en la informacin (por ejemplo, orden RNTO sin ser precedida por una RNFR). Hay cinco valores para el primer dgito del cdigo de respuesta: 1yz RESPUESTA PRELIMINAR POSITIVA: Se ha iniciado la accin requerida; se espera otra respuesta antes de seguir con una nueva orden. (El proceso de usuario que enva otra orden antes de que la respuesta de finalizacin llegue, estar violando el protocolo, pero el proceso servidor debera encolar cualquier orden que reciba mientras est ejecutando una orden anterior.) Este tipo de respuesta se puede usar para indicar que se ha aceptado la orden y que el proceso de usuario debera ocuparse ahora de la conexin de datos, en implementaciones donde controlar ambas conexiones a la vez es difcil. El proceso servidor puede enviar, a lo sumo, una respuesta 1yz por orden recibida. 2yz RESPUESTA DE FINALIZACIN POSITIVA: La accin requerida se ha completado satisfactoriamente. Se puede iniciar una nueva orden. 3yz RESPUESTA INTERMEDIA POSITIVA: La orden se ha aceptado, pero se est pendiente de recibir ms informacin para completarla. El usuario debera enviar otra orden indicando esta informacin. Esta respuesta se utiliza en rdenes que deben ir en secuencia.

4yz REPUESTA DE FINALIZACIN NEGATIVA TRANSITORIA: La orden no se ha aceptado y la accin requerida no se ha llevado a cabo, pero la condicin de error es temporal y se puede solicitar la accin de nuevo. El usuario debera volver al principio de la secuencia de comandos, si es que la hay. Es difcil dar un significado a "transitoria", particularmente cuando dos sistemas diferentes (el servidor y el usuario) deben estar de acuerdo en la interpretacin. Cada respuesta la categora 4yz puede tener un valor diferente, pero se pretende con ella que el proceso de usuario reintente la operacin. Una regla para determinar si una respuesta pertenece a la categora 4yz o a la 5yz (permanente negativa) es que las respuestas son 4yz si la orden se puede repetir sin cambios en la forma o en las propiedades del usuario o del servidor (por ejemplo, la orden y sus argumentos son los mismos; el usuario no cambia su cuenta ni su nombre; el servidor no lo interpreta de diferente forma. 5yz RESPUESTA DE FINALIZACIN NEGATIVA PERMANENTE: La orden no se ha aceptado y la accin requerida no ha tenido lugar. El proceso de usuario no debera repetir la misma peticin (en la misma secuencia). Incluso algunas condiciones de error "permanente" se pueden corregir, por eso el usuario (la persona) puede hacer posteriormente que su proceso de usuario repita posteriormente la orden (por ejemplo, se corrige el argumento, o el usuario cambia el estado de su directorio.)

Las siguientes agrupaciones de funciones se codifican en el segundo dgito: x0z SINTAXIS: Estas respuestas se refieren a errores de sintaxis, rdenes correctas sintcticamente pero que no encajan en ninguna otra categora, rdenes no implementadas o superfluas. x1z INFORMACIN: Estas son respuestas a solicitudes de informacin como STATUS o HELP. x2z CONEXIONES: Respuestas referidas a las conexiones de control y de datos. x3z AUTENTICACIN Y CUENTA: Respuestas para el proceso de entrada al sistema y procedimientos de cuenta. x4z SIN ESPECIFICAR AN. x5z SISTEMA DE FICHEROS: Estas respuestas indican el estado del sistema de ficheros en el servidor segn se realizan transferencias u otras acciones sobre el sistema de ficheros.

El tercer dgito afina ms en el significado de cada una de las categoras indicadas por el segundo. La lista de respuestas de la siguiente seccin mostrar esto. El texto asociado con cada respuesta es slo una recomendacin, no una obligacin, y puede incluso cambiar segn la orden asociada. Los cdigos de respuesta, por otra parte, deben seguir estrictamente las especificaciones; es decir, las implementaciones de servidores no deben inventarse nuevos cdigos para situaciones que son ligeramente diferentes a las descritas aqu, sino que deberan adaptarse a los cdigos ya definidos. Una orden como TYPE o ALLO cuya correcta ejecucin no proporciona al usuario ninguna nueva informacin debera devolver un cdigo 200. Si la orden no se ha implementado porque no tiene sentido para un determinado sistema, por ejemplo ALLO en un TOPS-20, una respuesta de finalizacin positiva es conveniente para no confundir al proceso de usuario. En este caso se usa una respuesta 202 con, por ejemplo, el siguiente texto: "No es necesario solicitar espacio para el fichero." Si, por otra parte, la orden no es especfica a ningn sistema y no est implementada, la respuesta debe ser 502. Un caso particular de esto es la respuesta 504 para una orden que est implementada pero que se solicita con un argumento no implementado.

4.2.1 CDIGOS DE RESPUESTA POR GRUPOS FUNCIONALES

200 Orden correcta. 500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como lnea de orden demasiado 501 Error de sintaxis en parmetros o argumentos. 202 Orden no implementada, no necesaria en este sistema. 502 Orden no implementada. 503 Secuencia de rdenes incorrecta. 504 Orden no implementada para ese parmetro. 110 Respuesta de marcador de reinicio. En este caso, el texto debe ser: MARK yyyy = mmmm. Donde yyyy es el marcador del flujo de datos en el proceso de usuario y mmmm es el equivalente en el servidor. 211 Estado del sistema o respuesta de ayuda del sistema. 212 Estado del directorio. 213 Estado del fichero. 214 Mensaje de ayuda. Sobre cmo usar el servidor o el significado de una orden particular no estndar. Esta respuesta slo es til para una persona. 215 NOMBRE system type. Donde NOMBRE es un nombre de sistema. 120 El servicio estar en funcionamiento en nnn minutos. 220 Servicio preparado para nuevo usuario. 221 Cerrando la conexin de control. Desconectado si procede.

421 Servicio no disponible, cerrando la conexin de control. Esta puede ser la respuesta a cualquier comando si el servidor sabe que debe finalizar. 125 La conexin de datos ya est abierta; comenzando transferencia. 225 Conexin de datos abierta; no hay transferencia en proceso. 425 No se puede abrir la conexin de datos. 226 Cerrando la conexin de datos. La accin sobre fichero requerida ha sido correcta (por ejemplo, una transferencia o interrupcin). 426 Conexin cerrada; transferencia interrumpida. 227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2). 230 Usuario conectado, contine. 530 No est conectado. 331 Usuario OK, necesita contrasea. 332 Necesita una cuenta para entrar en el sistema. 532 Necesita una cuenta para almacenar ficheros. 150 Estado del fichero correcto; va a abrirse la conexin de datos. 250 La accin sobre fichero solicitado finaliz correctamente. 257 "NOMBRERUTA" creada. 350 La accin requiere ms informacin 450 Accin no realizada. Fichero no disponible (por ejemplo, fichero bloqueado). 550 Accin no realizada, Fichero no disponible (por ejemplo, fichero no existe, no se tiene acceso al mismo). 451 Accin interrumpida. Error local. 551 Accin interrumpida. Tipo de pgina desconocido. 452 Accin no realizada. Falta de espacio en el sistema de ficheros. 552 Accin interrumpida. Se ha sobrepasado el espacio disponible de almacenamiento (para el directorio actual). 553 Accin no realizada. Nombre de fichero no permitido.

4.2.2 CDIGOS DE RESPUESTA POR NMERO.

110 Respuesta de marcador de reinicio. En este caso, el texto debe ser: MARK yyyy = mmmm. Donde yyyy es el marcador del flujo de datos en el proceso de usuario y mmmm es el equivalente en el servidor (atencin a los espacios entre los marcadores y el "="). 120 El servicio estar en funcionamiento en nnn minutos. 125 La conexin de datos ya est abierta; comenzando transferencia. 150 Estado del fichero correcto; va a abrirse la conexin de datos. 200 Orden correcta. 211 Estado del sistema o respuesta de ayuda del sistema.

212 Estado del directorio. 213 Estado del fichero. 214 Mensaje de ayuda. Sobre cmo usar el servidor o el significado de una orden particular no estndar. Esta respuesta slo es til para una persona. 215 NOMBRE system type. Donde NOMBRE es un nombre de sistema. 220 Servicio preparado para nuevo usuario. 221 Cerrando la conexin de control. Desconectado si procede. 225 Conexin de datos abierta; no hay transferencia en proceso. 226 Cerrando la conexin de datos. La accin sobre fichero requerida ha sido correcta (por ejemplo, una transferencia o interrupcin). 227 Iniciando modo pasivo (h1,h2,h3,h4,p1,p2). 230 Usuario conectado, contine. 250 La accin sobre fichero solicitado finaliz correctamente. 257 "NOMBRERUTA" creada. 331 Usuario OK, necesita contrasea. 332 Necesita una cuenta para entrar en el sistema. 532 Necesita una cuenta para almacenar ficheros. 350 La accin requiere ms informacin. 421 Servicio no disponible, cerrando la conexin de control. Esta puede ser la respuesta a cualquier comando si el servidor sabe que debe finalizar. 425 No se puede abrir la conexin de datos. 426 Conexin cerrada; transferencia interrumpida. 450 Accin no realizada. Fichero no disponible (por ejemplo, fichero bloqueado). 451 Accin interrumpida. Error local. 452 Accin no realizada. Falta de espacio en el sistema de ficheros. 500 Error de sintaxis, comando no reconocido. Esto puede incluir errores como lnea de orden demasiado larga. 501 Error de sintaxis en parmetros o argumentos. 502 Orden no implementada. 503 Secuencia de rdenes incorrecta. 504 Orden no implementada para ese parmetro. 530 No est conectado. 550 Accin no realizada. Fichero no disponible (por ejemplo, fichero no existe, no se tiene acceso al mismo). 551 Accin interrumpida. Tipo de pgina desconocido. 552 Accin interrumpida. Se ha sobrepasado el espacio disponible de almacenamiento (para el directorio actual). 553 Accin no realizada. Nombre de fichero no permitido.

5. ESPECIFICACIONES

5.1 IMPLEMENTACION MINIMA

Para hacer un FTP funcional sin mensajes de error innecesarios, se requiere que todos los servidores implementen como mnimo las siguientes funciones:

Los valores por defecto de los parmetros de transferencia: TYPE - ASCII No para imprimir MODE - Flujo STRU - Fichero Todos los servidores deben aceptar los valores indicados como estndar por defecto.

5.2 CONEXIONES

El intrprete de protocolo del servidor debe "escuchar" en el puerto L. El usuario o el intrprete de protocolo de usuario iniciarn la conexin de control full-duplex (bidireccional). Los procesos de servidor y de usuario deberan seguir las convenciones del Protocolo Telnet tal y como se especifican en el Manual de Protocolos de ARPA-Internet. Los servidores no tienen ninguna obligacin de proporcionar facilidades para la edicin de la lnea de comandos y pueden requerir que esto se haga en el ordenador del usuario. El servidor deber cerrar la conexin a peticin del usuario despus de que todas las transferencias y respuestas se han enviado.

El user-DTP debe "escuchar" en el puerto de datos especificado; este puede ser el puerto por defecto (U) u otro especificado por la orden PORT. El servidor, por defecto, iniciar las conexiones de datos desde su propio puerto de datos por defecto (L-1) usando el puerto de datos indicado por el usuario. El sentido de la transferencia y el puerto se determinarn por la orden de servicio FTP. Todas las implementaciones del FTP deben poder transferir datos usando el puerto por defecto y slo el user-PI puede solicitar el uso de puertos diferentes. Cuando se van a transferir datos entre dos servidores, A y B, el user-PI, C, establece la conexin de control entre ambos server-PIs. A uno de los servidores, por ejemplo, A, se le enva un comando PASV indicandole que "escuche" en su puerto de datos en lugar de iniciar la conexin cuando reciba la peticin de transferencia. Cuando el user-PI recibe la respuesta a la orden PASV, que incluye la direccin del ordenador y el puerto donde est escuchando, el user-PI enva el puerto de A a B mediante un comando PORT; se devuelve una respuesta. Luego el user-PI puede enviar las correspondientes rdenes a A y B. El servidor B inicia la conexin y comienza la transferencia de datos. La secuencia orden-respuesta se muestra aqu. Los mensajes se muestran en orden verticalmente, pero no horizontalmente:

El servidor cerrar la conexin de datos en las condiciones descritas en la seccin Estableciendo Conexiones de Datos. Si se va a cerrar la conexin de datos y no se necesita esto para indicar el final de fichero, el servidor lo debe hacer inmediatamente. No se permite que espere hasta recibir una nueva orden de transferencia porque el proceso de usuario ya habr comprobado la conexin de datos para ver si necesita "escuchar" (recuerde que el usuario debe "escuchar" en un puerto cerrado ANTES de enviar la peticin de transferencia. Para evitar fallos de sincronizacin, el servidor enva una respuesta (226) despus de cerrar la conexin de datos (o, si la conexin se deja abierta, una respuesta "Transferencia

completada." (250) y el user-PI debera esperar una de estas respuestas antes de enviar una nueva orden de transferencia). En cualquier momento en que el servidor o el usuario vean que el otro va a cerrar la conexin, debera leer inmediatamente cualquier dato que permanezca encolado en la conexin y proceder al cierre de la misma.

5.3 ORDENES

Las rdenes son cadenas de caracteres Telnet transmitidas por la conexin de control tal y como se describe en la seccin Ordenes FTP. Las funciones y la semntica de las rdenes se describe en las secciones: Ordenes de Control de Acceso, Ordenes de Parmetros de Transferencia, Ordenes de Sevicio FTP y Ordenes Varias. La sintaxis de los comandos se detalla aqu. Las rdenes comienzan con un cdigo de orden seguido de unos argumentos. Los cdigos de orden tienen cuatro o menos caracteres alfabticos. Las letras maysculas y las minsculas se tratan de la misma manera. Por tanto, cualquiera de las siguientes puede representar a la orden "recuperar": RETR Retr retr ReTr rETr

Tambin se aplica esto a cualquier smbolo que represente valores de los parmetros como la 'A' para el tipo ASCII. Los cdigos de comando y el campo de argumentos estn separados por uno o ms espacios. El campo de argumentos consiste en una cadena de caracteres de longitud variable terminada con la secuencia de caracteres <CRLF> (Retorno de carro, avance de lnea) para la representacin NVT-ASCII; para otros lenguajes negociados puede que se use otra representacin para el fin de lnea. El servidor no realizar ninguna accin hasta recibir el cdigo de fin de lnea. La sintaxis se especifica ms abajo en NVT-ASCII. Todos los caracteres del campo de argumentos son caracteres ASCII, incluyendo los enteros decimales representados en ASCII. Los parntesis cuadrados indican que un argumento es opcional. Si no se proporciona el argumento implica que se toma un valor por defecto apropiado.

5.3.1. ORDENES FTP

Las rdenes FTP son las siguientes: 5.3.2 USER <SP> <nombre-usuario> <CRLF> PASS <SP> <contrasea> <CRLF> ACCT <SP> <informacin-cuenta> <CRLF> CWD <SP> <nombre-ruta> <CRLF> CDUP <CRLF> SMNT <SP> <nombre-ruta> <CRLF> QUIT <CRLF> REIN <CRLF> PORT <SP> <dirIP-puerto> <CRLF> PASV <CRLF> TYPE <SP> <cdigo-tipo> <CRLF> STRU <SP> <cdigo-estructura> <CRLF> MODE <SP> <cdigo-modo> <CRLF> RETR <SP> <nombre-ruta> <CRLF> STOR <SP> <nombre-ruta> <CRLF> STOU <CRLF> APPE <SP> <nombre-ruta> <CRLF> ALLO <SP> <entero-decimal> [<SP> R <SP> <entero-decimal>] <CRLF> REST <SP> <marcador> <CRLF> RNFR <SP> <nombre-ruta> <CRLF> RNTO <SP> <nombre-ruta> <CRLF> ABOR <CRLF> DELE <SP> <nombre-ruta> <CRLF> RMD <SP> <nombre-ruta> <CRLF> MKD <SP> <nombre-ruta> <CRLF> PWD <CRLF> LIST [<SP> <nombre-ruta>] <CRLF> NLST [<SP> <nombre-ruta>] <CRLF> SITE <SP> <cadena> <CRLF> SYST <CRLF> STAT [<SP> <nombre-ruta>] <CRLF> HELP [<SP> <cadena>] <CRLF> NOOP <CRLF> ARGUMENTOS DE LAS ORDENES FTP

La sintaxis de los argumentos (usando la notacin BNF) es:

5.4 SECUENCIA DE RDENES Y RESPUESTAS

La comunicacin entre el usuario y el servidor se lleva a cabo mediante un dilogo. Como tal, el usuario enva una orden y el servidor devuelve una respuesta. El usuario debera esperar a recibir la respuesta antes de enviar ms rdenes. Algunas rdenes requieren una segunda respuesta a la que el usuario debera tambin esperar. Estas respuestas informan, por ejemplo, del estado o la finalizacin de una transferencia o del cierre de la conexin de datos. Son respuestas secundarias a rdenes de transferencia de ficheros. Un grupo importante de respuestas informativas son los mensajes al iniciar la conexin. En circunstancias normales, un servidor enviar una respuesta 220, "Esperando rdenes", cuando se completa la conexin. El usuario debera esperar esta respuesta antes de enviar cualquier orden. Si el servidor no puede aceptar rdenes en ese momento, se debera enviar una respuesta 120 indicando el

tiempo previsto de retraso y una respuesta 220 cuando est disponible. El usuario sabr as que no debe desconectar. RESPUESTAS ESPONTNEAS: A veces "el sistema" tiene que enviar un mensaje al usuario espontneamente (normalmente a todos los usuarios). Por ejemplo, "El sistema se apagar en 15 minutos". El FTP no proporciona los medios para enviar este mensaje inmediatamente al usuario. Se recomienda que esa informacin se encole en el server-PI y se enve en la siguiente respuesta (posiblemente en una respuesta multilnea). La tabla siguiente lista las respuestas indicando la finalizacin de cada orden correcta o incorrectamente. Se deben usar estas respuestas estrictamente; el servidor puede cambiar el texto en las respuestas, pero el significado y la accin que implica el nmero de cdigo y la secuencia de comandos no debe alterarse. SECUENCIAS ORDEN-RESPUESTA: En esta seccin se presenta la secuencia orden-respuesta. Cada orden se muestra con sus posibles respuestas; los grupos de rdenes se muestran juntos. En primer lugar aparecen las respuestas preliminares (con las respuestas de ejecucin correcta indentadas a continuacin), luego las respuestas de finalizacin positiva y negativa y, por ltimo, las respuestas intermedias con el resto de las rdenes de la secuencia. Este listado es la base de los diagramas, que se vern ms tarde. Establecimiento de conexin 120 220 220 421 Login USER 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230

202 530 500, 501, 503, 421 CWD 250 500, 501, 502, 421, 530, 550 CDUP 200 500, 501, 502, 421, 530, 550 SMNT 202, 250 500, 501, 502, 421, 530, 550 Logout REIN 120 220 421 500, 502 QUIT 221 500 Parmetros de transferencia PORT 200 500, 501, 421, 530 PASV 227 500, 501, 502, 421, 530 MODE 200 500, 501, 504, 421, 530 TYPE 200 500, 501, 504, 421, 530 STRU 200 500, 501, 504, 421, 530

Acciones sobre ficheros ALLO 200 202 500, 501, 504, 421, 530

REST 500, 501, 502, 421, 530 350 STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 STOU 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530 LIST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 NLST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550

500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE 250 450, 550 500, 501, 502, 421, 530 RMD 250 500, 501, 502, 421, 530, 550 MKD 257 500, 501, 502, 421, 530, 550 PWD 257 500, 501, 502, 421, 550 ABOR 225, 226 500, 501, 502, 421 rdenes informativas SYST 215 500, 501, 502, 421 STAT 211, 212, 213 450 500, 501, 502, 421, 530 HELP 211, 214 500, 501, 502, 421 Otras rdenes SITE 200 202 500, 501, 530 NOOP 200 500 421

6. DIAGRAMAS DE ESTADO

Aqu presentamos los diagramas de estado para una implementacin FTP muy simple. Slo se tiene en cuenta el primer dgito de la respuesta. Hay un diagrama de estado por cada grupo de rdenes FTP o secuencia de las mismas. La agrupacin de las rdenes se ha hecho construyendo un modelo para cada una de ellas y juntando las que tienen modelos idnticos estructuralmente. Para cada orden o secuencia hay tres posibles resultados: sin problemas (S), fallo (F) y error (E). En los diagramas se ha usado el smbolo B para "inicio" y el smbolo W para indicar "espera una respuesta". En primer lugar tenemos el diagrama que representa el grupo ms grande de rdenes FTP:

Este diagrama modela las rdenes: ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU y TYPE. El otro grupo grande de rdenes se representa con un diagrama muy parecido:

Este diagrama es para las rdenes: APPE, LIST, NLST, REIN, RETR, STOR y STOU. Como se puede ver, este segundo modelo puede usarse para representar el primer grupo de rdenes; la nica diferencia es que en el primer grupo las respuestas que empiezan por 1 no se esperan y, por tanto, se tratan como un error, mientras que el segundo grupo espera (a veces necesita) las respuestas que empiezan por 1. Recuerde que, como mucho, se permite una respuesta que empiece por 1 por cada orden. El resto de los diagramas modela secuencias de rdenes; quiz el ms simple de ellos es la secuencia de renombrar un archivo:

El siguiente diagrama es un modelo simple de la orden recomenzar:

Donde "cmd" es APPE, STOR o RETR. Podemos ver que los tres modelos anteriores son similares. Recomenzar difiere de renombrar slo en el tratamiento de las respuestas tipo100 en la segunda parte, mientras que el segundo grupo espera (a veces necesita) respuestas tipo 100. Slo se permite una respuesta tipo 100 por cada orden.

Por ltimo, mostramos un diagrama generalizado que se puede usar para modelar el intercambio orden y respuesta.

7. ESCENARIO TIPICO DEL FTP

El usuario del ordenador U quiere transferir ficheros a/desde el ordenador S: Generalmente, el usuario se comunicar con el servidor a travs del proceso userFTP. El siguiente puede ser un escenario tpico. Lo que muestra el user-FTP est entre parntesis, '---->' representa rdenes de U a S y '<----' representa respuestas de S a U.

8. ESTABLECIMIENTO DE LA CONEXION

La conexin de control del FTP se establece mediante FTP entre el puerto del proceso de usuario U y el puerto del proceso servidor L. A este protocolo se le ha asignado el puerto 21 (25 en octal), por tanto L=21.

APNDICE I RFCs sobre FTP Bhushan, Abhay, "Un protocolo de transferencia de ficheros", RFC 114 (NIC 5823), MIT-Project MAC, 16 de abril de 1971. Harslem, Eric, y John Heafner, "Comentarios sobre el RFC 114 (Un protocolo de transferencia de ficheros)", RFC 141 (NIC 6726), RAND, 29 de abril de 1971. Bhushan, Abhay, et al, "El Protocolo de Transferencia de Ficheros", RFC 172 (NIC 6794), MIT-Project MAC, 23 de junio de 1971. Braden, Bob, "Comentarios sobre las propuestas DTP y FTP", RFC 238 (NIC 7663), UCLA/CCN, 29 de septiembre de 1971. Bhushan, Abhay, et al, "El Protocolo de Transferencia de Ficheros", RFC 265 (NIC 7813), MIT-Project MAC, 17 de noviembre de 1971. McKenzie, Alex, "Una sugerencia para aadir al protocolo FTP", RFC 281 (NIC 8163), BBN, 8 de diciembre de 1971. Bhushan, Abhay, "El uso de la transaccin "Tipo de datos" en FTP", RFC 294 (NIC 8304), MIT-Project MAC, 25 de enero de 1972. Bhushan, Abhay, "El Protocolo de Transferencia de Ficheros", RFC 354 (NIC 10596), MIT-Project MAC, 8 de julio de 1972. Bhushan, Abhay, "Comentarios sobre el protocolo de transferencia de ficheros (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 de agosto de 1972. Hicks, Greg, "Documentacin para el usuario del FTP", RFC 412 (NIC 12404), Utah, 27 de noviembre de 1972. Bhushan, Abhay, "Estado del FTP y comentarios adicionales", RFC 414 (NIC 12406), MIT-Project MAC, 20 de noviembre de 1972. Braden, Bob, "Comentarios sobre el FTP", RFC 430 (NIC 13299), UCLA/CCN, 7 de febrero de 1973. Thomas, Bob, and Bob Clements, "Interaccin servidor-servidor en el FTP", RFC 438 (NIC 13770), BBN, 15 sw enero de 1973. Braden, Bob, "Ficheros para imprimir y FTP", RFC 448 (NIC 13299), UCLA/CCN, 27 de febrero de 1973.

McKenzie, Alex, "Protocolo de Transferencia de Ficheros", RFC 454 (NIC 14333), BBN, 16 de febrero de 1973. Bressler, Bob, and Bob Thomas, "Recogido de correo mediante FTP", RFC 458 (NIC 14378), BBN-NET and BBN-TENEX, 20 de febrero de 1973. Neigus, Nancy, "Protocolo de Transferencia de Ficheros", RFC 542 (NIC 17759), BBN, 12 de julio de 1973. Krilanovich, Mark, and George Gregg, "Comentarios sobre el FTP", RFC 607 (NIC 21255), UCSB, 7 de enero de 1974. Pogran, Ken, and Nancy Neigus, "Respuesta al RFC 607 - Comentarios sobre el FTP", RFC 614 (NIC 21530), BBN, 28 de enero de 1974. Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, "Comentarios sobre el FTP", RFC 624 (NIC 22054), UCSB, Ames Research Center, SRI-ARC, 28 de febrero de 1974. Bhushan, Abhay, "Comentarios sobre el FTP y respuesta al RFC 430", RFC 463 (NIC 14573), MIT-DMCG, 21 de febrero de 1973. Braden, Bob, "Compresin de datos en FTP", RFC 468 (NIC 14742), UCLA/CCN, 8 de marzo de 1973. Bhushan, Abhay, "FTP y el sistema de correo de red", RFC 475 (NIC 14919), MITDMCG, 6 de marzo de 1973. Bressler, Bob, and Bob Thomas "Interaccin servidor-servidor en FTP - II", RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 de marzo de 1973. White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), SRI-ARC, 8 marzo de 1973. White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), SRI-ARC, 8 de marzo de 1973. Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 (NIC 16157), MIT-Multics, 26 de junio de 1973. Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", RFC 520 (NIC 16819), Illinois, 25 de junio de 1973. Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 (NIC 17451), UCSD-CC, 22 de junio de 1973.

Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 15 de noviembre de 1973. McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 29 de noviembre de 1973. Sussman, Julie, "FTP Error Code Usage for More Reliable Mail Service", RFC 630 (NIC 30237), BBN, 10 de abril de 1974. Postel, Jon, "Cdigos de respuesta FTP revisados", RFC 640 (NIC 30843), UCLA/NMC, 5 junio de 1974. Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), SU-AI, 10 mayo de 1975. Harvey, Brian, "Un intento ms con el FTP", RFC 691 (NIC 32700), SU-AI, 28 de mayo 1975. Lieb, J., "La orden CWD en el FTP", RFC 697 (NIC 32963), 14 de julio de 1975. Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, 31 de octubre de 1977. Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), SRI-KL, 30 de diciembre de 1977. Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 10 de diciembre de 1978. Postel, Jon, "Especificacin del protocolo de transferencia de ficheros", RFC 765, ISI, junio de 1980. Mankins, David, Dan Franklin, and Buzz Owen, "Ordenes FTP orientadas a directorio", RFC 776, BBN, diciembre de 1980. Padlipsky, Michael, "Orden de guardar con nombre nico en FTP", RFC 949, MITRE, julio de 1985.