Sistemas operativos modernos

bién pueden tener acceso a los atributos de los archivos, como el modo, el tamaño y la hora de la última modificación. NFS reconoce casi todas las llamadas al sistema de UNIX, con la ex­ cepción tal vez sorprendente de open y close. La omisión de open y close no es un accidente; es intencional por completo. No es necesa­ rio abrir un archivo antes de leerlo ni cerrarlo al terminar. En vez de eso, si un cliente quiere leer un archivo, envía al servidor un mensaje lookup que contiene el nombre del archivo, solicitándo­ le que lo busque y le devuelva un identificador de archivo (éste, contiene un identificador de sis­ tema de archivos y un número de nodo-i, entre otros datos). A diferencia de una llamada open, esta operación lookup no copia información en tablas internas del sistema. La llamada read contiene el identificador del archivo que se leerá, el desplazamiento dentro del archivo donde se iniciará la lectura y el número de bytes deseados. Cada uno de estos mensajes es autosuficiente. La ventaja de este esquema es que el servidor no necesita recordar nada, entre una llamada y otra, acerca de conexiones abiertas. Por tanto, si un servidor falla y luego se recupera, no se ha­ brá perdido información sobre archivos abiertos, porque no existe. Un servidor de este fipo, que no mantiene información de estado acerca de los archivos abiertos, se conoce como sin estado (stateless). Por desgracia, el método de NFS dificulta lograr con exacfitud la semántica de archivos de UNIX. Por ejemplo, en UNIX se puede abrir un archivo y bloquearlo para que no puedan te­ ner acceso a él otros procesos. Cuando se cierra el archivo, se desbloquea. En un servidor sin estado como NFS, no es posible asociar bloqueos con un archivo abierto, porque el servidor no sabe cuáles archivos están abiertos. Por tanto, NFS necesita un mecanismo adicional para ma­ nejar los bloqueos. NFS emplea el mecanismo de protección estándar de UNIX, con los bits rwx para el due­ ño, el grupo y los demás (que mencionamos en el capítulo 1 y describiremos con detalle más adelante). En un principio, cada mensaje de solicitud contenía sólo los identificadores de usua­ rio y de grupo del solicitante, que el servidor NFS usaba para validar el acceso. Así, se confia­ ba en que los clientes no harían trampa. Varios años de experiencia demostraron hasta la saciedad que tal supuesto era—^¿cómo decirlo?— inocente. En la actualidad puede usarse crip­ tografía de clave pública para establecer una clave segura con la cual validar al cliente y al ser­ vidor en cada solicitud y contestación. Cuando se habilita esta opción, un cliente mal intencionado no puede hacerse pasar por otro, porque no conoce la clave secreta del cliente. Implementación de NFS Aunque la implementación del código del cliente y del servidor es independiente de los proto­ colos de NFS, casi todos los sistemas UNIX utilizan una implementación de tres capas similar a la de la figura 10-37. La capa superior es la capa de llamadas al sistema, que maneja llama­ das como open, read y close. Después de analizar en forma sintácfica la llamada y verificar los parámetros, esta capa invoca a la segunda, la capa de Sistema de Archivos Virtual (VFS; Virtual File System). La labor de la capa VFS consiste en mantener una tabla con una entrada por cada archivo abierto, análoga a la tabla de nodos-i de archivos abiertos en UNIX. En el UNIX ordinario, un nodo-i se idenfifica de manera inequívoca con un par (dispositivo, número de nodo-i). En cam-