• Author / Uploaded
• Adrian Moreira

• Categories
• Servidor (Informática)
• Computación distribuida
• Middleware
• Software
• Programa de computadora

Citation preview

UTM. MOREIRA PINARGOTE FREDDY ADRIAN

1

UNIVERSIDAD TECNICA DE MANABI FACULTAD DE CIENCIAS INFORMATICAS SISTEMAS DISTRIBUIDOS SEXTO SEMESTRE PARALELO “A”

LLAMADA A PROCEDIMIENTO REMOTO 

Resumen— El presente trabajo trata sobre llamadas a procedimientos remotos, donde se conocerá un poco de su historia, un concepto claro de lo que es una llamada a procedimiento remoto, el proceso de una llamada a un procedimiento remoto, donde también conoceremos los objetivos de una RPC, características del Stub y por ultimo se presentara un ejemplo de RPC. I. INTRODUCCIÓN

Como se sabe, un sistema distribuido es un conjunto de computadoras conectadas en red que le dan la sensación al usuario de ser una sola computadora. Este tipo de sistema brinda una serie de características tales como: compartición de recursos, la concurrencia, alta escalabilidad, y tolerancia a fallos. A pesar que agregar complejidad al software y disminuir los niveles de seguridad, los sistemas de procesamiento distribuidos brindan una buena relación precio - desempeño y pueden aumentar su tamaño de manera gradual al aumentar la carga de trabajo.

II. MARCO TEÓRICO A. Definición ¿Qué es un RPC? En informática, una llamada a procedimiento remoto es una comunicación entre procesos que permite que un programa de ordenador para hacer que una subrutina o procedimiento para ejecutar en otro espacio de direcciones sin que el programador codifica explícitamente los detalles de esta interacción a distancia. Es decir, el programador escribe esencialmente el mismo código si la subrutina es local para el programa en ejecución, o a distancia. Cuando el software en cuestión utiliza los principios orientados a objetos, RPC se llama invocación remota o la invocación de métodos remotos. Muchas tecnologías diferentes se han utilizado para aplicar el concepto. [1]

RPC (Llamada a procedimiento remoto) es una tecnología, tradicionalmente empleada en ambiente UNIX, que permite el desarrollo de sistemas de procesamiento distribuido basados en el paradigma procedimental. Con el advenimiento de implementaciones para plataforma Windows, así como para Java, es posible pensar en RPC como un mecanismo de integración de software heterogéneo. El presente documento presenta las características técnicas más importantes del mecanismo de Llamadas a Procedimientos Remotos (RPC, Remote Procedure Calls), tal como su función, pase de parámetros, protocolo de transporte etc. [11] [1][2]

Campodocs.com – Nola

[5] Sistemas-distribuidos-ist-ucpr.wikispaces.com [11] Tamps.cinvestav.mx – Llamada a procedimientos remotos

Octubre 2014 – Febrero 2015

Proceso llamada a procedimiento remoto [5]

B.

Historia y Orígenes

La idea de tratar las operaciones de red como las llamadas a procedimientos remotos se remonta por lo menos hasta la década de 1980 en los primeros

UTM. MOREIRA PINARGOTE FREDDY ADRIAN

documentos de ARPANET. Bruce Jay Nelson generalmente se le atribuye haber acuñado el término. Uno de los primeros usos comerciales de RPC fue por Xerox con el nombre de "El Correo", en 1981 - La primera aplicación popular de la RPC en Unix era de Sun RPC, que se utiliza como base para el Sistema de archivos de red. [2] C. 

Objetivos de RPC Proporcionar un middleware que simplifique el desarrollo de aplicaciones distribuidas



Evitar que programador tenga que interactuar directamente con el interfaz de Sockets



Abstraer (ocultar) los detalles relativos a la red



El Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales



Se busca ofrecer un entorno de programación lo más similar posible a un entorno no distribuido.



El sistema RPC oculta los detalles de implementación de esas llamadas remotas Implementa la llamada remota mediante un dialogo petición respuesta -- Mensaje de petición: identifica procedimiento llamado, contiene parámetros de la llamada -- Mensaje de respuesta: contiene valor/es devuelto/s se encarga de enviar/recibir mensajes para comunicar ambas partes se encarga de gestionar los contenidos de esos mensajes (empaquetado y formateado de datos) [3]

D.

Diferencias con llamadas locales (LPC)



Punto clave: manejo de errores.



Con RPC pueden existir fallos en servidor remoto o en la red.



Acceso a variables globales y efectos laterales

Octubre 2014 – Febrero 2015

2

en el cliente no son posible 

Procedimiento. Remoto (servidor) no tiene acceso al espacio de direcciones del cliente / imposibilidad de usar punteros.



RPC impone encapsulamiento



Los parámetros para la llamada remota no pueden pasarse por referencia (solo por valor).



Mayor sobrecarga en llamadas RPC (transferencia por red, aplanamiento de datos, etc.)



En algunos entornos se limita el intercambio de estructuras complejas, en otros se usan métodos de aplanado/desaplanado [4] III.

un

mayor

nivel

de

EL PASO DE MENSAJES

Una RPC es iniciado por el cliente, que envía un mensaje de solicitud a un servidor remoto conocido para ejecutar un procedimiento especificado con los parámetros suministrados. El servidor remoto envía una respuesta al cliente, y la aplicación continúa su proceso. Mientras el servidor está procesando la llamada, el cliente se bloquea, a menos que el cliente envía una solicitud asincrónica al servidor, como una llamada XHTTP. Hay muchas variaciones y sutilezas en diversas implementaciones, lo que resulta en una variedad de diferentes protocolos RPC. [6] Una diferencia importante entre las llamadas a procedimientos remotos y las llamadas locales es que las llamadas remotas pueden fallar debido a problemas de red impredecibles. Además, los que llaman por lo general deben hacer frente a estos fallos sin saber si el procedimiento remoto se invocó en realidad. Procedimientos Idempotent se manejan fácilmente, pero lo suficientemente siguen existiendo dificultades que el código para llamar a procedimientos remotos a menudo se limita a los subsistemas de bajo nivel. __________________________ [3][4] Ecured,cu - crack_708 [6] Campodocs.com - Nola

UTM. MOREIRA PINARGOTE FREDDY ADRIAN

Secuencia de eventos durante una RPC 





El cliente llama al stub del cliente. La llamada es una llamada de procedimiento local, con parámetros empujado en la pila de la forma habitual. El resguardo del cliente embala los parámetros en un mensaje y realiza una llamada al sistema para enviar el mensaje. Embalaje de los parámetros se denomina cálculo de referencias. Sistema operativo local del cliente envía el mensaje de la máquina cliente al servidor.



El sistema operativo local en el servidor pasa los paquetes entrantes al resguardo del servidor.



El resguardo del servidor desempaqueta los parámetros del mensaje. Desembalaje de los parámetros se llama unmarshalling.



Por último, el resguardo del servidor llama al procedimiento servidor. La respuesta traza los mismos pasos en la dirección inversa. [7]

Mecanismos de contacto estándar Para permitir que los diferentes servidores de acceso a los clientes, se han creado una serie de sistemas RPC estandarizados. La mayoría de ellos utilizan un lenguaje de descripción de la interfaz para que las distintas plataformas llaman la RPC. Los archivos de IDL a continuación, se pueden utilizar para generar código de interfaz entre el cliente y el servidor. La herramienta más común usada para esto es RPCGEN. [8] Característica del Stub

3



El stub es quien proporciona transparencia en la invocación del cliente



El stub debe poseer llamadas con la misma declaración (forma) que el servidor



El cliente invoca las llamadas del stub “como si” fuese el servidor



El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto solicitando la “ejecución real” de la llamada



El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto y recupera el “resultado” de la invocación.



El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué dirección IP y en qué puerto hay que contactar con el extremo remoto



Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub. [9] IV.

EJEMPLO DE RPC

A continuación describiremos un ejemplo de invocación remota mediante RPC. Lo primero es crear el fichero de interfaz que lo denominaremos test.x: program PROGRAMA_TEST { version VERSION_TEST { int TEST (int) = 1; } = 1; } = 0x20000001;

La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si” fuesen el cliente/servidor. 

En el lado cliente, el representante del servidor se denomina Stub (o Proxy)

______________________ [7] [8] Campodocs.com – Nola [9] Ecured,cu - crack_708

Este fichero especifica una única función llamada Octubre 2014 – Febrero 2015

UTM. MOREIRA PINARGOTE FREDDY ADRIAN

TEST(), que acepta un parámetro entero y devuelve otro entero. Todas las funciones declaradas tienen un número de procedimiento que deberá ser diferente a 0. A su vez, el programa tendrá una versión (en nuestro caso 1) y un número de programa (en nuestro caso 0x20000001). El compilador de interfaces generar una función con el nombre test 1(), es decir, el nombre declarado en el fichero de especificación pero en minúscula, seguido de un guion bajo y el número de versión. Para compilar el fichero de especificación: rpcgen test.x

El compilador habrá generado tres nuevos ficheros: test.h, test_svc.c y test_clnt.c. El fichero test.h declara la función especificada, mientras que test_svc test_clnt declaran los resguardos del servidor y cliente respectivamente. Será necesarios compilarlos junto con los clientes y servidores. A continuación mostramos el código del cliente test_client.c: #include "test.h" void programa_test_1(char *host) { CLIENT *clnt; int *result_1; int test_1_arg = 10; #ifndef DEBUG clnt = clnt_create (host, PROGRAMA_TEST, VERSION_TEST, "udp"); if (clnt == NULL) { clnt_pcreateerror (host); exit (1); } #endif /* DEBUG */ result_1 = test_1(&test_1_arg, clnt); if (result_1 == (int *) NULL) { clnt_perror (clnt, "call failed"); } printf("Resultados: %d\n",*result_1); #ifndef DEBUG clnt_destroy (clnt); #endif /* DEBUG */ } int main (int argc, char *argv[]) { char *host; if (argc < 2) { Octubre 2014 – Febrero 2015

4 printf ("usage: %s argv[0]); exit (1); } host = argv[1]; programa_test_1 (host); exit (0); }

server_host\n",

La llamada clnt_create() crea un manejador de RPC para un programa y versión especificas en una maquina destino. Además es necesario especificar el protocolo utilizado (TCP o UDP). También incluimos el código del servidor test server.c: #include "test.h" int * test_1_svc(int *argp, struct *rqstp) { static int result; /* * insert server code here */ 3result = *argp * 2; return &result; }

svc_req

A continuación se muestra el resumen de comandos para compilar y enlazar el cliente y servidor: [10] cc -o test_client test_clnt.cc cc -o test_server test_svc.cc

Ejecuta el servidor: ./test_server

Ejecuta el cliente: ./test_client localhost

______________________ [10] Ingeniería Informática - Universidad Rey Juan Carlos

test_client.cc test_server.cc

UTM. MOREIRA PINARGOTE FREDDY ADRIAN

5

CONCLUSIONES En este trabajo se ha visto representada las características técnicas más importantes del mecanismo de Llamadas a Procedimientos Remotos (RPC, Remote Procedure Calls), específicamente de la implementación ONC, así también como su funcionamiento de una RPC. Como ya se pudo observar una RPC es una tecnología, que tradicionalmente es empleada en ambiente UNIX, que permite el desarrollo de sistemas de procesamiento distribuido basados en el paradigma procedimental. Con el advenimiento de implementaciones para plataforma Windows, así como para Java, se concibe a RPC como una tecnología de integración entre plataformas disimiles de hardware y software. REFERENCIAS

[1][2][6][7][8] HTTP://CAMPODOCS.COM/ARTICULOSENCICLOPEDICOS/ARTICLE_92561.HTML [5] HTTP://SISTEMAS-DISTRIBUIDOS-ISTUCPR.WIKISPACES.COM/7.1.2+LLAMADAS+A+PROCEDIMI ENTOS+REMOTOS [3][4] [9]HTTP://WWW.ECURED.CU/INDEX.PHP/LLAMADA_A_PROCEDI MIENTO_REMOTO [10]HTTPS://WWW.GOOGLE.COM.EC/URL? SA=T&RCT=J&Q=&ESRC=S&SOURCE=WEB&CD=1&CAD=RJA &UACT=8&VED=0CB4QFJAA&URL=HTTP%3A%2F %2FDOCENCIA.ETSIT.URJC.ES%2FMOODLE %2FPLUGINFILE.PHP%2F14544%2FMOD_FOLDER %2FCONTENT%2F1%2FPRACTICASRPC%2FINTRORPC.PDF %3FFORCEDOWNLOAD%3D1&EI=PC23VOAN4I4GGTVSIG4AG&USG=AFQJCNEPMASPHOKTRQEWISSO L3F1KQYHTQ&SIG2=UL_FSBZSRZB5MPFO_F7YFW [11]HTTP://WWW.TAMPS.CINVESTAV.MX/~VJSOSA/CLASES/SD/R PC_NOTAS.PDF Autor

Octubre 2014 – Febrero 2015

Mi nombre es FREDDY ADRIAN MOREIRA PINARGOTE soy estudiante de la asignatura de Sistemas Distribuidos, actualmente curso el Sexto semestre en la Carrera de INGENIERIA EN SISTEMAS, FACULTAD DE CIENCIAS INFORMÁTICAS DE LA UNIVERSIDAD TÉCNICA DE MANABÍ. Soy una persona responsable, organizada y me gusta trabajar en equipo. Mis metas son convertirme en un profesional de la Ingeniería en Sistemas Informáticos, para poder dar soluciones a los problemas que puedan presentarse en nuestra vida social. Tengo como objetivo ayudar a la comunidad universitaria, y principalmente mente a mis padres, ya que gracias a Dios y al esfuerzo de ellos cumpliré mis sueños y ser un nuevo profesional de la República del Ecuador. Traducido por: Moreira Pinargote Freddy Adrian Universidad Técnica de Manabí Facultad de Ciencias Informáticas Sistemas Distribuidos Sexto paralelo A 2014