Evolución del modelo C/S.
La principal desventaja del C/S es que las comunicaciones giran con base en esquemas de Entrada/Salida (send/receive).
El objetivo de un S.O.D respecto al I/O es hacerlo ver como centralizado.
La idea con RPC es hacer llamados a procedimientos localizados en otras maquinas.
Funcionamiento:
por ejemplo la llamada invocada desde el main:
c = read(fd, buf, nbytes)
En C, los enteros, escalares y otros se pasan por valor; los arreglos
se pasan por Referencia.
La idea con RPC es hacer ver a una llamada remota como si fuera local, por esto la invocación debe ser transparente para el que la utiliza.
La transparencia en RPC se logra agregando un Stub o proxy tanto al cliente como al servidor.
Los pasos que ejecuta un Cliente para invocar un procedimiento remoto en un Servidor son los siguientes:
Paso de parámetros en RPC:
Debido a problemas de alfabetos (ASCII/ABCDIC), representación de enteros (complemento a uno o a dos), punto flotante, ordenamiento de bytes (Little Endian y Big Endian), se hace necesario establecer una forma canonica de representar los distintos tipos de datos.
Se ejecuta un proceso conocido como Marshalling/UnMarshalling, el cual consiste el transformar los tipos de datos locales de una maquina en un formato estándar para ser transmitidos por la red.
Los tipos básicos como escalares entre otros se pasan por valor, cuando son arreglos tanto en los clientes como servidores se realiza una copia local, se manipulan y se envian por la red.
En RPC no hay paso de punteros.
Además de los parámetros normales de una función,
se requiere transferir otra información como: Nombre del procedimiento,
versión, etc.
Localización de Servidores:
Como un cliente localiza un servidor?
1) podría ser que el cliente tuviera la dir. del servidor. Esto
es muy ineficiente y estático.
2) realizar un proceso dinámico de asociación o binding
con el servidor.
Partimos de una especificación formal del servidor:
Cuando un servidor comienza a ejecutar envía un mensaje a un programa (local o remoto) llamado el "binder" o servidor de registro.
El cliente conoce la dirección del binder a quien interroga por la existencia o no de los servidores que desea contactar.
Este binder se conoce como un Localizador de Recursos en la red, un
broker o un "corredor" de procedimientos.
El protocolo RPC y XDR fueron originalmente desarrollados por SUN.
Hoy son ampliamente difundidos mediante una las aplicaciones más importantes conocida como Network File System (NFS). Se considera un estándar de facto.
RPC ha tenido evolución hacia DCE (Distributed Computing Environtment) desarrollado por OSF.
Debido a que el desarrollar en este ambiente implica adicionar a mi programa un conjunto de llamadas de RPC (Remote Procedure Call) y XDR (eXternal Data Representation), se requería mucho conocimiento de este, muchas causas de errores, mucha inversión en tiempo dedicado a problemas de comunicaciones a parte del problema en si a resolver, el mantenimiento de una aplicación tambien es traumatica. Por estas razones se decide crear un PreCompilador de RPC, que nos genera automaticamente el código fijo y relacionado con la parte de comunicaciones. Obviamente un procompilador implica la especificación formal de la utilización de RPC en un programa.
Un precompilador muy popular es el RPCGEN.
RPCGEN utiliza un lenjuaje de especificación de procedimientos conocido como RPCL.
Los archivos de especificación son *.x
Los tipos de definciones que permite hacer RPCL son:
En toda maquina que ofrezca servicios en RPC, debe tener un proceso llamado "Portmapper" el cual es responsable de mapear procedimientos a puertos UDP.
El portmapper utiliza en si mismo un puerto bien conocido (111) por el cual cualquier cliente puede contactarlo.
Pasos para llamar un cliente al servidor:
EN EL SERVIDOR:
Se utilizan dos llamadas:
int registerrpc( u_long prognum, u_long versnum, u_long procnum, char *(*procname)(), xdrproc_t inproc, xdrproc_t outproc).
void svc_run()
EN EL CLIENTE:
Se utiliza:
int callrpc(char *host, u_long prognum, u_long versnum, u_long procnum,
char *in, xdrproc_t inproc, char *out, xdrproc_t outproc)
Sistema de Archivos en Red
Es una facilidad que permite compartir archivos a través de un ambiente heterogeneo de maquinas. S.O., redes, etc.
Para un usuario que este utilizando NFS, es totalmente transparente en que parte de la red están almacenados los archivos.
Para manipular transparentemente los archivo, se utilizan los mismos comandos para manipulación de archivos locales (UNIX: ls, cp, mv, chmod, etc).
Arquitectura NFS:
OSI NFS
* VFS: Provee un Wrapper para que se comporte como un F.S. unix tradicional.
Un sistema de archivos tradicional contiene archivos y directorios,
cada uno corresponde a un inodo.
Cada inodo es único en un F.S. pero no en la red, por esto se
diseño VFS el cual contiene vnode.
* La interfaz NFS esta representada por el intercambio de información
por la red entre un cliente y un servidor NFS, mediante los protocolos
RPC y XDR.
Transparencia en NFS:
La transparencia que maneja NFS se da respecto a: tipo de F.S, localización del F.S., S.O. (RPC), formato de datos (XDR), tipo de red (TCP/IP y otras).
Protocolo NFS y mount:
NFS nunca interpreta pathnames, en vez de esto utiliza un descriptor de archivo (File Handle) para cualquier referencia. Si es un directorio gana acceso a todos los archivos hacia abajo.
NFS es un protocolo STATELESS.
Mounting:
Es el proceso de montar un sistema de archivos por un cliente.
En Unix, siempre que se desea utilizar una partición de un disco
duro, este debe se "montado" en el root "/".
El proceso que se sigue en NFS es el siguiente:
1) En el cliente: Se envía en pathname remoto.
2) En el servidor: si el pathname es válido y tiene los permisos
adecuados, se retorna un descriptor de archivo. En este descriptor se envia
adicionalmente: tipo de F.S., tipo de disco, # inodo, aspectos de seguridad.
Muchos clientes montan automaticamente un F.S. remotos al momento de booting.
Muchas implementaciones implementan un concepto llamado: Automounting. Esto permite a un conjunto de directorios remotos estar asociados con directorios local, pero que no son montados al momento del boot. En vez de esto, la primera vez que se tenga referencia a un archivo de estos directorios, se envia un mensaje a todos los servidores y el primero que contesta monta este directorio para el cliente.
Ventajas del automounting:
Se tiene todas las llamadas al sistema para manipulación de archivos excepto open y close debido a que es stateless.
La ventaja de la característica stateless es que el servidor no tiene que almacenar información de los archivos abiertos.
Dado que el sistema de archivos de Unix y otros tipos de F.S. se ofrece las llamadas open y close, simplemente por compatibilidad.
Si no hay estado, como se implementan las operaciones de bloqueo sobre archivos (locking)? La respuesta es que NFS ofrece procedimientos adicionales para proveer este servicio.
Respecto a la seguridad, es de anotar que NFS utiliza el mismo esquema de seguridad de UNIX, es decir, dueño, grupo y todos; y rwx.
NFS no encripta la información que transmite
Cada Sistema operacional tiene una forma diferente de configurar el servidor y la manera que un cliente lo monta.
En el caso de UNIX, que es el que más ampliamente a difundido NFS, se tiene un conjunto de pasos mas o menos similares entre marcas diferentes de sistemas Unix, en este caso se presentará para LINUX:
En la maquina Unix que quiere ofrecer un F.S. o directorio a un grupo de maquinas clientes, se especifican en el archivo /etc/exports, el conjunto de F.S. o directorios que dicho servidor ofrece.
En este archivo tambien se puede especificar aspectos de seguridad como: maquinas (por dir ip, nombre, domino, metacaracteres, etc), usuarios, lectura y/o escritura, entre otros aspectos:
Ej, archivo /etc/exports:
/usr centauro.eafit.edu.co(ro)
/usr/local/share *.dis.eafit.edu.co(ro)
/usuarios *.dis.eafit.edu.co(rw)
En el cliente, solo el usuario root puede montar un F.S. remoto, ejecutando el siguiente comando:
$ mount agamenon:/usuarios /usuarios
Si se quiere que automaticamente monte un F.S. remoto cuando realice
el boot, se debe agregar unas entradas al archivo: /etc/fstab, así:
Edwin Montoya, DIS, LabTel. emontoya@eafit.edu.co