Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
El módulo FTP (File Transfer Protocol) [RFC959] es el que posibilita que una máquina intercambie ficheros con otras computadoras remotas. Aunque existen otros protocolos para cubrir la necesidad de compartir ficheros dentro del ámbito de una red local, como el NFS (Network File System) [RFC1094] [RFC1813], el protocolo FTP está diseñado específicamente para acceder a sistemas fuera de nuestra jurisdicción, como es el caso de los grandes servidores de ficheros repartidos por todo el mundo.
Esto hace que, en el ámbito TCP/IP mundial, el tráfico de ficheros derivado del uso del protocolo FTP sólo haya sido superado, en los últimos años, por el relacionado con el "World Wide Web" [HTTP1.1].
El protocolo FTP en sí está especificado en [RFC959], con una pequeña matización en [RFC1579] para facilitar el acceso de los clientes FTP cuando estos deben atravesar una "firewall" corporativa o departamental. En [RFC783] se define el TFTP (Trivial File Transfer Protocol) que, como su mismo nombre indica, es un protocolo extremadamente sencillo (menos de 4Kbytes de código) utilizable, fundamentalmente, en ámbitos LAN. Utiliza el protocolo UDP [RFC768], mientras que el FTP propiamente dicho utiliza el TCP [RFC793]. En [RFC906] se proporciona un ejemplo de uso de TFTP para inicializar puestos de red sin disco. En [RFC913] se define el protocolo SFTP (Simple File Transfer Protocol), un paso intermedio entre TFTP y FTP.
Tal y como se ha especificado el protocolo FTP incluso posibilita
el intercambio de ficheros entre dos servidores, transferencia
tutelada por una tercera máquina. Dicha posibilidad no se ha
considerado útil y no se ha implementado aquí. En caso de
necesidad es muy fácil utilizar el protocolo TELNET para lograr
dicho fin.
Interfaz
La interfaz de este módulo está constituida por diversos procesos cooperantes y varias rutinas que se ejecutan en el contexto del llamante.
PROC_FTP_BC
Este proceso es el encargado de inicializar este módulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". La inicialización de este módulo debe ser posterior a la del módulo TCP.
PROC_FTP_SUP
Este proceso es el encargado de recibir los comandos provenientes de la capa superior y efectuar las tareas demandadas. Los mensajes que espera recibir son "MSG_MBUF", con el siguiente formato:
campo1: Cadena de MBUF's conteniendo el comando a ejecutar y
todos sus parámetros. El comando y los parámetros deben
ir, cada uno de ellos, en un nodo de la cadena.
campo2: Identificador de la conexión
campo3: No utilizado
La capa FTP intentará ejecutar el comando solicitado, con los parámetros que se indiquen. La realimentación que se genera es puramente visual. Cuando el protocolo FTP desea informar de algo al usuario envía un mensaje "MSG_MBUF" a la capa superior, con el formato habitual:
campo1: Cadena de MBUF's conteniendo el mensaje a visualizar
campo2: Identificador de la conexión
campo3: Indeterminado
Como regla general, para que el usuario pueda distinguir los mensajes textuales de la capa FTP de los enviados por el servidor, los primeros van precedidos por tres asteriscos ("***").
Si el usuario desea abortar la ejecución de un comando FTP, genera un mensaje "MSG_FTP_ABORT" con el formato:
campo1: Indeterminado
campo2: Identificador de la conexión
campo3: Indeterminado
La realimentación, nuevamente, será visual.
Los comandos actualmente implementados son:
El primer parámetro de este comando especifica el nombre de usuario con el que debemos identificarnos ante el servidor FTP. Si existe un segundo parámetro, éste constituirá la palabra de paso asociada.
Este comando sólo se utiliza cuando se desea modificar la autentificación efectuada al principio del enlace al servidor. De hecho cuando se abre una sesión FTP, esta capa se encarga automáticamente de realizar la autentificación sin que el usuario deba escribir ningún comando.
Este comando necesita un parámetro, que será la palabra clave asociada a un nombre de usuario. Este comando debe enviarse inmediatemente después del comando "USER" cuando en éste no se especifique ya la palabra de paso. Normalmente se utiliza dicho comando para realizar la autentificación, por lo que "PASS" se puede considerar innecesario.
Este comando no requiere parámetros. Solicita al servidor que cierre el enlace. Si hay alguna transferencia en progreso, el servidor retrasará el cierre de la conexión hasta que se haya terminado de transferir el fichero.
Cuando la conexión se cierra se envía un mensaje "MSG_FTP_CLOSE" con el formato:
campo1: Ignorado
campo2: Identificador de la conexión
campo3: Ignorado
Los ficheros transferidos se consideran ASCII. El protocolo realizará cualquier conversión que considere conveniente para adaptar los datos recibidos al formato local.
Los ficheros transferidos se consideran BINARIOS. No se realiza ninguna conversión. Este es, habitualmente, el modo en el que se debería trabajar a la hora de intercambiar ficheros. Dado que el protocolo FTP fija que el modo por defecto sea ASCII, es responsabilidad del usuario el enviar un comando "BINARY".
Este comando requiere un parámetro e indica a la máquina remota cual debe ser el directorio de trabajo actual.
Sin ningún parámetro este comando informa de cual es nuestro directorio local actual. Si se indica un parámetro, éste será nuestro nuevo directorio local. El directorio local es el directorio donde se reciben los ficheros que envía el servidor y desde dónde se leen los ficheros que se le envían al mismo.
Este comando solicita el listado de un directorio. Si no se indican parámetros se listará el directorio actual. Si se indica un parámetro se listará el directorio especificado.
Este comando no necesita ningún parámetro. Pide al servidor que informe de cual es el "path" de acceso al directorio de trabajo actual.
Este comando solicita al servidor que cree el directorio especificado.
Este comando solicita al servidor que borre el directorio especificado.
Este comando solicita el envío de un fichero. El primer parámetro indica el nombre del fichero que queremos. El segundo parámetro, si existe, indica el nombre con el que debe almacenarse en nuestro disco. Si el segundo parámetro no existe, se intentará grabar con el mismo nombre. Si el segundo parámetro es un guión ("-"), el fichero se listará en pantalla.
Este comando informa al servidor de que se le va a enviar un fichero. Si sólo se indica un parámetro, éste será el nombre del fichero a transmitir. Si se indican dos parámetros, el primero será el nombre del fichero a enviar y el segundo el nombre con el cual debe ser almacenado en el servidor.
Este comando solicita al servidor que borre el archivo especificado.
Los comandos pueden escribirse en mayúsculas, minúsculas o cualquier combinación de las mismas. Los parámetros, en cambio, suelen ser interpretados por el servidor y deben escribirse teniendo en cuenta la convención utilizada localmente en el mismo. Por ejemplo, en un servidor UNIX las mayúsculas y minúsculas son significativas en un nombre de fichero o directorio, mientras que en una máquina MS-DOS son consideradas equivalentes.
PROC_FTP_INF
Este proceso es el encargado de gestionar la recepción y el envío de ficheros, y demás información asociada. En general no tiene otra interacción con el usuario que el envío de textos para ser impresos. No obstante también se encarga de informar de la apertura y cierre de enlaces FTP.
Con estos mensajes se pretende que la capa superior imprima en la pantalla el texto indicado.
campo1: Cadena de MBUF's conteniendo el mensaje a visualizar
campo2: Identificador de la conexión
campo3: Indeterminado
Este mensaje se genera para indicar a la capa superior que ha sido aceptado un intento de conexión FTP a una máquina remota. A partir de ese momento la conexión está abierta y lista para aceptar comandos. Habitualmente el primer paso de esta capa es pedir al usuario que se identifique, solicitándole su nombre de usuario y su palabra de paso. No es necesario utilizar los comandos "USER" o "PASS".
campo1: Valor indeterminado
campo2: Identificador de la conexión
campo3: Valor indeterminado
Este mensaje se genera cuando uno de los extremos cierra la conexión FTP, ya sea mediante el comando correspondiente o gracias a la llamada imperativa que será descrita a continuación.
campo1: Valor indeterminado
campo2: Identificador de la conexión
campo3: Valor indeterminado
En cuanto a las rutinas, sus prototipos son:
void ftp_open(uint32 ip,uint16 puerto,uint32 id,proc_id proc_retorno);
Esta rutina intenta realizar una conexión FTP al puerto 'puerto' de la máquina 'ip'. 'id' contiene el identificador de la conexión y 'proc_retorno' es el proceso que debe ser informado de todos los eventos y que recibe los datos en sí. Como resultado de esta llamada, el proceso especificado recibirá un mensaje "MSG_FTP_OPEN" o bien un "MSG_FTP_CLOSE", según corresponda. Su formato será el declarado anteriormente.
Aunque esta llamada permite abrir una conexión FTP de control en cualquier puerto donde haya un servidor FTP, éstos tienen un puerto ya asignado para tal fin: "FTP_PUERTO" (puerto 21).
void ftp_close(uint32 id);
Esta rutina cierra una conexión, especificada según su identificador 'id'. El proceso responsable recibirá un "MSG_FTP_CLOSE", con el formato habitual, cuando la conexión se cierre finalmente. Esta orden no puede ser ignorada por el servidor, que se verá forzado a aceptar la desconexión. Si hay alguna transferencia en curso, se truncará en este punto.
estado ftp_flujo(uint32 id);
Esta rutina informa de la disponibilidad de la capa FTP para aceptar nuevos comandos. La rutina devuelve "FLUJO_LLENO" si no puede hacerse cargo de comandos adicionales y "OK" si admite nuevas peticiones. Dada la semántica implantada, si se envían comandos cuando el control de flujo está cerrado se mantendrán en una cola de espera. Adicionalmente se garantiza que si en un momento dado el control de flujo está abierto, éste permanecerá en dicho estado hasta que se envíe un nuevo comando. La utilidad de una función así consiste en la ejecución de ficheros "script" por parte del módulo principal.
'id' es el identificador de conexión sobre la cual estamos
solicitando información. Si en un momento dado el control de
flujo está cerrado habrá que reintentarlo de nuevo tras un
tiempo prudencial (por ejemplo, una décima de segundo).
Implementación
La implantación que se ha efectuado del protocolo FTP sigue de forma precisa lo especificado en [RFC959]. No se han incluido algunas de las posibilidades por considerarlas obsoletas y de uso muy poco común. De hecho muchos de los servidores analizados durante las pruebas de funcionamiento tampoco las soportaban. Los formatos de transferencia definidos son:
Este tipo es el utilizado por defecto. La máquina origen convertirá el texto a formato NVT (Network Virtual Terminal), tal y como se define en el protocolo TELNET [RFC854], y la máquina destina convertirá la información recibida a su propio formato interno.
La información se considera datos binarios no sujetos a interpretación ni traducción. Ni la máquina fuente ni la máquina destino los modificarán en modo alguno. Este es el formato utilizado para la transferencia de ficheros cuando éstos no constituyen texto. Ejemplos de ello son programas ejecutables, gráficos, datos comprimidos, etc. Se puede utilizar este tipo aún cuando los ficheros estén constituidos por texto, siempre y cuando luego el usuario disponga de alguna herramienta para adaptar los CR, LF o CRLF de final de línea y demás idiosincrasias propias de cada equipo informático. En la actualidad ello no constituye ningún problema.
Estos tipos no se soportan, por considerarlos anticuados y poco difundidos.
Este formato indica, en modo ASCII que los datos no deben modificarse. En general la idea de ello es que no van a utilizarse para imprimir, así que no debería contener ninguna información "no texto", como tabuladores, "Form Feed", etc.
Estos formatos especifican diferentes sistemas de control utilizados a la hora de imprimir un texto. Dado que el cliente FTP implementado pone el máximo interés en no modificar los datos que se transmiten o reciben, o hacerlo lo mínimo posible, estos formatos no son soportados.
Este formato es el normal y el único que se soporta. Asume que el fichero es una secuencia continua de bytes.
Estas estructuras imponen un formato particular en el fichero y no son soportadas.
Este modo es el único que se soporta. Asume que el cierre de la conexión de datos FTP supone el EOF.
No soportados.
Lo ideal sería, hoy en día, soportar sólo:
"IMAGE"+"FILE"+"STREAM", ya que será la única combinación de
sistemas que el usuario va a utilizar cuando acceda a un servidor
público FTP. La razón de implantar también
los modos "ASCII"+"NON
PRINT" es porque, por razones históricas,
éste es el formato por
defecto cuando se realizar una conexión FTP.
Bibliografía
[HTTP1.1] "HyperText Transfer Protocol"
http://www.w3.org
[RFC768] RFC768: "User Datagram Protocol"
Jon Postel
Agosto 1.981
[RFC783] RFC783: "THE TFTP PROTOCOL (REVISION 2)"
K. R. Sollins
Junio 1.981
[RFC793] RFC793: "Transport Control Protocol"
Jon Postel
Septiembre 1.981
[RFC854] RFC854: "Telnet Protocol specification"
Jon Postel
Joyce Reynolds
Mayo 1.983
[RFC906] RFC906: "Bootstrap Loading using TFTP"
Ross Finlayson
Junio 1.984
[RFC913] RFC913: "Simple File Transfer Protocol"
Mark K. Lottor
Septiembre 1.984
[RFC959] RFC959: "FILE TRANSFER PROTOCOL (FTP)"
Jon Postel
Joyce Reynolds
Octubre 1.995
[RFC1094] RFC1094: "NFS: Network File System Protocol
Specification"
Sun Microsystems, Inc.
Marzo 1.989
[RFC1123] RFC1123:"Requirements for Internet Hosts --
Application and Support"
Robert Braden
Octubre 1.989
[RFC1579] RFC1579: "Firewall-Friendly FTP"
Steven M. Bellovin
Febrero 1.994
[RFC1639] RFC1639: "FTP Operation Over Big Address Records
(FOOBAR)"
David M. Piscitello
Junio 1.994
[RFC1813] RFC1813: "NFS Version 3 Protocol Specification"
B. Callaghan
B. Pawlowski
P. Staubach
Junio 1.995
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
