LLAMADA A PROCEDIMIENTO REMOTO RPC
CONCEPTO
Supongamos, por ejemplo, que tenemos un computador muy potente en clculo matemtico y otro con un buen despliegue para grficos. Queremos hacer un programa con mucho clculo y con unos grficos "maravillosos". Ninguno de los dos computadores cumple con ambos requisitos. Una solucin, utilizando RPC (Llamada a procedimientos remotos), consiste en programar las funciones matemticas en el computador de clculo y publicar dichas funciones. Estas funciones podrn ser llamadas por el computador grfico, pero se ejecutarn en el computador de clculo. Por otro lado, hacemos nuestros grficos en el computador grfico y cuando necesitemos algn clculo, llamamos a las funciones del computador de clculo. Al programa con las funciones se le llama "servidor". Al programa que llama a esas funciones se le llama "cliente". Normalmente el servidor est siempre corriendo y a la espera de que algn cliente llame a alguna de sus funciones. Cuando el cliente llama a una funcin del servidor, la funcin se ejecuta en el servidor y el cliente detiene su ejecucin hasta que el servidor termina. El cdigo del programa servidor bsicamente hay que seguir los siguientes pasos: - Codificar las funciones que van a ser llamadas siguiendo un determinado mecanismo. - Informar al sistema operativo de un nombre, una versin y funciones que publica. - Correr un bucle infinito esperando que alguien llame a alguna de sus funciones. A su vez, el programa cliente debe: - Establecer una conexin con el servidor. - Llamar a las funciones. - Cerrar la conexin con el servidor.
ASPECTOS DE IMPLEMENTACION RPC
RPC es una tcnica poderosa para construir aplicaciones distribuidas bajo el modelo ClienteServidor. Se basa en extender la nocin convencional de un llamado a un procedimiento local, por lo que el procedimiento que esta siendo invocado no se halla dentro del mismo espacio de direcciones del proceso que efecta su llamado. Ambos procesos pueden estar en el mismo sistema computacional o pueden estar en diferentes sistemas conectados a una misma red comn. El uso de RPC facilita el desarrollo de aplicaciones distribuidas puesto que no considera todos los detalles de interface con la red, tal el caso de la programacin va sockets. RPC implementa la transparencia respecto a los protocolos de transporte, puesto que abstrae a la aplicacin de los mecanismos fsicos y lgicos de la comunicacin de datos, permitiendo a la aplicacin usar una variedad de transportes.
Funcionamiento RPC
Un llamado a un procedimiento remoto (RPC) es similar a un llamado a una funcin. Cuando se realiza un RPC, se pasan argumentos al procedimiento remoto y el proceso que realiza el llamado espera por una respuesta a ser retornado por el procedimiento remoto. La figura siguiente describe el flujo realizado durante una llamada a un procedimiento remoto entre dos sistemas interconectadas por una red.
Un procedimiento remoto es identificado unvocamente por una tripleta: Nmero de Programa, Nmero de versin y Nmero de procedimiento. El Nmero de Programa, identifica a un grupo de procedimientos remotos relacionados, cada uno de los cuales tiene una nica identificacin. Un programa puede a su vez, tener varias versiones. Los nmeros de versin permiten tener mltiples versiones de un RPC disponibles a ser invocados de forma simultnea. Cada versin consiste de una coleccin de procedimientos, los cuales estn disponibles a ser llamados remotamente.
Definicin del Protocolo de comunicacin
A fin de generar este protocolo, se cuenta con el compilador de protocolos rpcgen que nos ayuda en el proceso de codificacin y la generacin de los stubs para el cliente y servidor. El generador de RPC (rpcgen) requiere como entrada leer un archivo con los prototipos de las funciones que queremos publicar. Este archivo se denomina interfaz del servicio. Cada prototipo de funcin es definido mediante: nombre de procedimiento de servicio, los parmetros que recibe y sus tipos de datos y el retorno de parmetros y sus tipos de datos.
STUBS Cliente y Servidor
Los Stubs se generan automticamente por el software del RPC en base a la interfaz del servicio y son independientes de la implementacin que se haga del cliente y del servidor. Solo dependen de la interfaz. La idea detrs de RPC es hacer que una llamada remota se parezca lo ms posible a una llamada local. Se desea que RPC sea transparente, el procedimiento llamador no debera enterarse que el procedimiento llamado se est ejecutando en una maquina diferente y viceversa. Supngase que un programa necesita leer datos de un archivo, el programador incluir un llamado a READ en el cdigo para obtener los datos. En un sistema tradicional (un procesador) la rutina READ es extrada de una librera por el encadenador y es insertada
dentro del programa objeto. Este es un pequeo procedimiento, el cual es implementado invocando a una Llamada al Sistema (SYSCALL) equivalente. El procedimiento READ es una interfaz entre el cdigo del usuario y el sistema operativo local. RPC logra su transparencia de una forma similar, cuando READ es un procedimiento remoto, una versin diferente de READ, llamada stub del cliente es puesto en la librera. Como en el caso original es invocada usando la misma secuencia de llamado, haciendo una llamada al Sistema Operativo local. La diferencia con la versin original es que no pide los datos al SO, en su lugar, empaqueta los parmetros en un mensaje y solicita enviar este mensaje al servidor. Luego de la llamada a SEND, el stub del cliente llama a RECEIVE bloquendose asimismo hasta que la respuesta llegue. Cuando el mensaje arriba al servidor, el SO del servidor pasa el mensaje al stub del servidor. Un stub de servidor, es el equivalente del stub del cliente pero en el servidor. Es una pieza de cdigo que transforma requerimientos que ingresan de la red en llamadas a procedimientos locales. El servidor habr llamado a RECEIVE y estar bloqueado esperando mensajes. El stub del servidor desempaqueta los parmetros del mensaje e invoca la ejecucin del procedimiento servidor. Una vez concluido el procedimiento de servicio, el stub del servidor recupera el control y empaqueta el resultado en un mensaje y llama a SEND para regresarlo al cliente. Cuando el mensaje llega a la maquina cliente, el mensaje se copia al buffer en espera y el proceso cliente elimina su bloqueo. El stub del cliente examina el mensaje, desempaqueta el resultado y lo copia a quien hizo la llamada. El proceso cliente que hizo la llamada obtiene el control, todo lo que sabe es que ahora dispone de los datos y no tiene la menor idea de que el trabajo se realizo de manera remota y no en el ncleo local. Todo el detalle de la transferencia de mensajes se oculta en dos procedimientos de biblioteca, al igual que los detalles de realizacin de interrupciones a las llamadas al sistema se ocultan en las bibliotecas tradicionales.
