INTRODUCCION

Un sistema distribuido es un conjunto de computadoras conectadas en red que le dan la sensacin al usuario de ser una sola computadora. Este tipo de sistema brinda una serie de bondades tales como: comparticin de recursos, la concurrencia, alta escalabilidad, y tolerancia a fallos. RPC es una tecnologa, 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 integracin de software heterogneo. Los RPC ocultan la comunicacin entre procesos, de forma que parezca una llamada a un procedimiento absolutamente normal, es decir, permite a un programa comunicarse con sus partes remotas utilizando el mismo mecanismo(llamada a procedimiento) que utiliza para comunicarse con las locales.

1. QUE ES RPC? El RPC (del ingls Remote Procedure Call, Llamada a Procedimiento Remoto)

Es un protocolo que permite a un programa de ordenador ejecutar cdigo en otra mquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tena que estar pendiente de las comunicaciones, estando stas encapsuladas dentro de las RPC. Es la transferencia sincrnica de datos y control entre dos partes de un programa distribuido a travs de espacios de direcciones disjuntas. La manera en que RPC logra hacer esto, es por medio de lo que se conoce como STUB. En el caso del STUB servidor, se conoce como SKELETON. Estos Stubs y Skeletons permiten que al momento de ser invocada la funcin remota esta pueda ser simulada localmente.

1.1Historia Presentadas por Birrell y Nelson en los aos 80 (Xerox Parc), siendo un concepto muy atractivo pero no muy bien comprendido. Se produjeron intentos prematuros de estandarizacin que terminaron mostrando problemas y carencias serios. En los aos 90 aparecen entornos de desarrollo RPC con capacidades limitadas (p.e.DCE: Distributed Computing Environment). En la actualidad: nfasis en rendimiento.

Nuevos paradigmas orientados a objetos. Preocupacin por la confiabilidad.

Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de sune denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre s. La mayora de ellos utilizan un lenguaje de descripcin de interfaz (IDL) que define los mtodos exportados por el servidor. Hoy en da se est utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de stos pueden ser SOAP o XML-RPC. 1.2 El mecanismo de RPC El stub del cliente: se encarga de empaquetar los parmetros y la solicitud, enviarlos al intermediario en el servidor, y luego esperar la respuesta, desempaquetarla y entregarla a la aplicacin. El programa principal del servidor (que incluye el stub y el dispatcher). se encarga de recibir peticiones, desempaquetar los parmetros, invocar la funcin solicitada, pasarle los parmetros, luego obtener el resultado, empaquetarlo y enviarlo al cliente. Las rutinas de serializacin de datos: Se debe tomar en cuenta que las mquinas cliente y servidor puedan ser de arquitectura diferente (y no compatible). Servicio de binding: Responsable de la transparencia de localizacin, gestiona la asociacin entre el nombre del procedimiento remoto (y su versin) con su localizacin en la maquina servidor (direccin, puertos, skeleton, etc). Realiza la bsqueda del skeleton de la implementacin concreta del procedimiento remoto llamado por un cliente. Ejemplos: portmapper en Sun-RPC, protocolo UDDI en servicios web, rmiregistry en Java-RMI.

1.3 Caractersticas del Stub -La base del mecanismo RPC consiste en la introduccin de representantes que hacen como si fuesen el cliente/servidor En el lado cliente, el representante del servidor se denomina Stub (o Proxy). El stub es quien proporciona transparencia en la invocacin del cliente.

El stub debe poseer llamadas con la misma declaracin (forma) que el servidor.

El cliente invoca las llamadas del stub como si fuese el servidor. El stub, a travs de un protocolo RPC y con unos mecanismos de aplanamiento, enva un mensaje al extremo remoto solicitando la ejecucin real de la llamada.

El stub, a travs de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto y recupera el resultado de la invocacin.

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

-Cada procedimiento que el cliente quiera invocar a travs de RPCs necesita su propio stub.

1.4 Caractersticas del Skeleton En el lado servidor, el representante del cliente se llama Skeleton El skeleton es quien proporciona transparencia en el lado del servidor El skeleton debe conocer las llamadas ofrecidas por el servidor El skeleton, a travs de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto solicitando la ejecucin real de la llamada El skeleton invoca la llamada del servidor como si fuese el cliente El skeleton, a travs de un protocolo RPC y con unos mecanismos de aplanamiento, enva un mensaje al extremo remoto indicando el resultado de la invocacin. Cada procedimiento que el servidor exporte a travs de RPCs requiere su propio skeleton

Otros elementos Servicio de binding Responsable de la transparencia de localizacin Servicio auxiliar que complementa a stub y skeleton Gestiona la asociacin entre el nombre del procedimiento remoto (y su versin) con su localizacin en la maquina servidor (direccin, puertos, skeleton, etc.) Realiza la bsqueda del skeleton de la implementacin concreta del procedimiento remoto llamado por un cliente Selecciona skeleton+servidor que atender a la llamada remota

Ejemplos: portmapper en Sun-RPC, protocolo UDDI en servicios web, rmiregistry en Java-RMI

Compilador de interfaces A partir de la descripcin del interfaz del procedimiento remoto genera de forma automtica el cdigo del stub y del skeleton stub+skeleton solo dependen de la interfaz del procedimiento remoto Dependiendo del entorno RPC puede generar otro cdigo adicional que sea necesario Interfaz del procedimiento remoto (datos necesarios para generar stub+skeleton) especifica el interfaz ofrecido por el procedimiento (argumentos de entrada + valor devuelto) especifica cmo ser el aplanado/desaplanado opcionalmente aporta informacin que se usar para localizar el procedimiento remoto (nmero / versin)

Definicin de interfaces de procedimiento remotos: -Usando el mismo lenguaje de programacin con el que ser implementado Ejemplo: Java-RMI (usa directamente interfaces Java)

-Usando un lenguaje de definicin de interfaces independiente del lenguaje de programacin [IDL: interface definition language] Compilador IDL hace la traduccin al lenguaje de implementacin Ejemplos: XDR usado en Sun-RPC, Corba-IDL, WSDL en servicios web El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tena que estar pendiente de las comunicaciones, estando stas encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o funcin y enviando ste de vuelta el resultado de dicha operacin al cliente. Sokects

Designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.

El trmino socket es tambin usado como el nombre de una interfaz de programacin de aplicaciones (API) para la familia de protocolos de Internet TCP/IP, provista usualmente por el sistema operativo.

Los sockets de Internet constituyen el mecanismo para la entrega de paquetes de datos provenientes de la tarjeta de red a los procesos o hilos apropiados. Un socket queda definido por un par de direcciones IP local y remota, un protocolo de transporte y un par de nmeros de puerto local y remoto.

Para que dos programas puedan comunicarse entre s es necesario que se cumplan ciertos requisitos: Que un programa sea capaz de localizar al otro. Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad. Para ello son necesarios los dos recursos que originan el concepto de socket: Un par de direcciones del protocolo de red (direccin IP, si se utiliza el protocolo TCP/IP), que identifican la computadora de origen y la remota. Un par de nmeros de puerto, que identifican a un programa dentro de cada computadora. Los sockets permiten implementar una arquitectura cliente-servidor. La

comunicacin debe ser iniciada por uno de los programas que se denomina programa "cliente". El segundo programa espera a que otro inicie la comunicacin, por este motivo se denomina programa "servidor". Un socket es un proceso o hilo existente en la mquina cliente y en la mquina servidora, que sirve en ltima instancia para que el programa servidor y el cliente lean y escriban la informacin. Esta informacin ser la transmitida por las diferentes capas de red.

Descripcin del servicio: La llamada a procedimiento remoto es un mecanismo por el que dos procesos se pueden comunicar entre s. Este mecanismo habilita el intercambio de datos y permite solicitar funcionalidades residentes en otros procesos. Dichos procesos pueden residir en el mismo equipo, en una red local o en internet, es decir que en resumidas cuentas, este servicio permite que las aplicaciones de nuestro equipo puedan comunicarse con el sistema operativo y entre s.

MAQUINA CLIENTE

MAQUINA SERVIDOR

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 programacin lo ms similar posible a un entorno no distribuido.

El sistema RPC oculta los detalles de implementacin de esas llamadas remotas Implementa la llamada remota mediante un dialogo peticin respuesta -- Mensaje de peticin: identifica procedimiento llamado, contiene parmetros 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).

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 en el cliente no son posible Procedimiento. Remoto (servidor) no tiene acceso al espacio de direcciones del cliente / imposibilidad de usar punteros. RPC impone un mayor nivel de encapsulamiento Los parmetros 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 mtodos de aplanado/desaplanado.

Comportamiento ante fallos Aspecto clave que determina la equivalencia semntica entre llamadas remotas y llamadas locales. Llamadas locales ofrecen una semntica exactamente una vez (ejecucin fiable).

El entorno de ejecucin de las llamadas locales garantiza que el procedimiento llamado se ejecuta exactamente una vez Llamada termina devolviendo un valor de retorno si tuvo xito o una indicacin del error (excepcin, cdigo de error) en caso de fallo Llamador se queda en espera indefinidamente hasta que finalice llamada En RPC no es posible espera indefinida (posibilidad de fallos) En llamadas remotas las posibles fuentes de fallos son mltiples. 1. Fallos en los procedimientos llamados La ejecucin del proceso llamado se detiene por errores del hardware o del sistema operativo que lo ejecuta (ej.: cada del sistema) Tambin por errores internos del propio procedimiento (divisiones por 0, ndices de arrays fuera de rango, etc.)

2. Fallos en la comunicacin Prdida de la conexin: la red deja de enviar paquetes (cada de la red, prdida de un enlace) Corrupcin del contenido de alguno de los mensajes enviados Prdida de paquetes: algn mensaje/s no llega a su destino Recepcin fuera de orden: paquetes retrasados recibidos de forma desordenada 3. Otros fallos: bugs en el proceso llamado, ataques, etc. En general el proceso cliente no tiene capacidad para distinguir los diferentes tipos de errores -Cliente slo percibe que una o ms de sus peticiones no reciben respuesta, pero no llega a saber por qu: La peticin (llamada) no lleg al proceso remoto El servidor est cado o no ha llegado a procesar la peticin La peticin lleg y el servidor la proces, pero la respuesta no lleg al cliente

 Otros,...

-Dependiendo de los mecanismos definidos y de la semntica se puede volver a pedir la ejecucin del procedimiento remoto o no.

La forma de gestionar los fallos por parte del entorno RPC determina la semntica efectiva de las llamadas remotas.

-Herramientas para controlar los fallos Uso de mensajes de asentimiento (ACKs) con o sin temporizadores (time-out): Permiten confirmar la recepcin de cada mensaje y detectar la prdida de mensajes Uso de nmero de secuencia y control de duplicados: Cliente y servidor asocian un identificador a sus mensajes El otro extremo mantiene lista con los IDs de los mensajes recibidos Se mantiene una copia de los mensajes enviados ms reciente- mente junto con sus IDs

Semntica de las llamadas RPC

Dependiendo del modelo de gestin de fallos por parte del entorno RPC se pueden soportar distintas aproximaciones a la semntica exacta- mente una vez de las llamadas locales (LPC)

No es posible garantizar la semntica exactamente una vez debido a la posibilidad de fallos de comunicacin 3 tipos de semntica en llamadas RPC (de menor a mayor complejidad)

Semntica tal-vez: Procedimiento remoto puede ejecutarse una vez o ninguna

Cliente puede recibir una respuesta o ninguna Funcionamiento: Cliente enva peticin y queda a la espera un tiempo Si no llega respuesta dentro del tiempo de espera, contina su ejecucin Cliente no tiene realimentacin en caso de fallo (no sabe que peso)

Solo admisible en aplicaciones donde se tolere la prdida de peticiones y la recepcin de respuestas con retaso (fuera de orden)

Semntica al-menos-una-vez Procedimiento remoto se ejecuta una o ms veces

Cliente puede recibir una o ms respuestas Funcionamiento: o Cliente enva peticin y queda a la espera un tiempo o Si no llega respuesta o ACK dentro del tiempo de espera, repite la peticin o Servidor no filtra peticiones duplicadas procedimiento remoto puede ejecutarse o repetidas veces o Cliente puede recibir varias respuestas

Solo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles) Una operacin es idempotente si se puede ejecutar varias veces resultando el mismo efecto que si se hubiera ejecutado solo una

Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento

Semntica como-mximo-una-vez El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna

Cliente recibe una respuesta o una indicacin de que no se ha ejecutado el procedimiento remoto Funcionamiento: o Cliente enva peticin y queda a la espera un tiempo o Si no llega respuesta o ACK dentro del tiempo de espera, repite la peticin o Servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas (servidor con memoria) procedimiento remoto sol se ejecuta una vez o Cliente slo recibe una respuesta si la peticin lleg y se ejecut el procedimiento, si no recibe informe del error.

Semntica ms prxima la de llamadas a procedimiento locales (semntico slo una vez) en presencia de fallos.

RESUMEN: Semntica Tal-vez

Al menos una vez

Como mximo una vez

Funcionamiento Cliente no retransmite sus peticiones (no usa ACK), su servidor no filtra peticiones duplicadas Cliente retransmite sus peticiones (usa ACK + temporizador), el servidor no filtra peticiones duplicadas ante repeticiones repetidas, servidor repite ejecucin Cliente reintenta retransmitir peticiones (usa ACK + temporizador), servidor filtra las peticiones duplicadas ante peticiones repetidas, servidor retransmite las respuestas pasadas.

La Interface: La interfaz que proporciona el servidor se refiere a la forma de las llamadas exportadas por el servidor Una interface es el principal acuerdo entre el componente de software y el cliente. El lenguaje de definicin de interfaces (IDL) fue desarrollado para que los objetos en lenguajes diferentes puedan invocarse entre s. Corba usa CORBA IDL, Sun propone XDR para su RPC, DCE usa su IDL para RPC, Microsoft usa DCOM IDL. Un punto interesante es si estos IDLs exponen las interfaces de manera tal que sean comprendidos por cualquier objeto invocante. Funcionamiento del compilador de interfaces La Interface de RPC Para la comunicacin entre el servidor y el cliente, se trabaja con interfaces, que deben ser implementadas por el servidor y/o cliente, para que los STUBs puedan realizar la transparencia para ambos. Adems esto evita que deba existir una definicin local real de la clase remota, es decir, en el cliente solo debe estar definida la interface, no la clase remota

Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o funcin y enviando ste de vuelta el resultado de dicha operacin al cliente. El Modelo de Objetos de Componentes Distribuidos Es una tecnologa propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre s. Extiende el modelo COM de Microsoft y proporciona el sustrato de comunicacin entre la infraestructura del servidor de aplicaciones COM+ de Microsoft. La adicin de la quot;Dquot; a COM fue debido al uso extensivo de DCE/RPC, o ms especficamente la versin mejorada de Microsoft, conocida como MSRPC. ste ltimo es el ms utilizado debido a que, como ya hemos comentado en bastantes ocasiones, es el sistema operativo ms utilizado y por tanto, los servicios (la mayora) que ofrece su empresa creadora tambin lo son. El ejemplo ms comn y el ms claro con el que se puede explicar este

tipo de protocolo son las famosas actualizaciones de Windows. El cliente (en este caso nuestro PC) se conecta con los servidores de Microsoft para solicitar actualizaciones, de haber alguna de stas, se realiza el proceso de que caracteriza a los RPC. No solo existe este tipo de aplicacin para este tipo de protocolo en realidad son bastantes los usos que se les pueden dar, pero este es el ms sencillo y comn de entender. DCOM permite que el programador COM amplie sus componentes a travs de la red, dndoles los beneficios de la informtica distribuida. Cuando el cliente y el componente residen en el mismo equipo se comunican con la ayuda de procedimientos de llamada local (LPC), pero a travs de la red tienen que utilizar el DCOM estndar construido por Microsoft. Los Componentes COM a travs de la red se comportan del mismo modo que si estuviesen en la misma mquina con el cliente. Component Object Model (COM) es una plataforma de Microsoft para componentes de software introducida por dicha empresa en 1993. Esta plataforma es utilizada para permitir la comunicacin entre procesos y la creacin dinmica de objetos, en cualquier lenguaje de programacin que soporte dicha tecnologa. El trmino COM es a menudo usado en el mundo del desarrollo de software como un trmino que abarca las tecnologas OLE, OLE Automation, ActiveX, COM+ y DCOM. Si bien COM fue introducido en 1993, Microsoft no hizo nfasis en el nombre COM hasta 1997. Esencialmente COM es una manera de implementar objetos neutral con respecto al lenguaje, de manera que pueden ser usados en entornos distintos de aquel en que fueron creados, a travs de fronteras entre mquinas. Para componentes bien creados, COM permite la reutilizacin de objetos sin conocimiento de su implementacin interna, porque fuerza a los implementadores de componentes a proveer interfaces bien definidos que estn separados de la implementacin. Las diferentes semnticas de reserva de memoria estn acomodadas haciendo a los objetos responsables de su propia creacin y destruccin por medio del contador de referencias. Se puede hacer casting entre distintos interfaces de un objeto por medio de la funcin QueryInterface(). El mtodo preferido de herencia en COM es la creacin de subobjetos a los que se delegan las llamadas a mtodos ( llamado agregacin ). COM (Component Object Model: En este tipo de entornos las interfaces de los componentes publican un conjunto de apuntadores a tablas de memoria (tablas virtuales de funciones); el llamado entre componentes se hace a travs de los apuntadores, las interfaces son definidas utilizando el lenguaje IDL (Interface Description Language). DCOM (Distributed Component Object Model) Se utiliza para aplicaciones distribuidas, para el llamado de mensajes utiliza RPC (Remote Procedure Call).

Conclusiones
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o funcin y enviando ste de vuelta el resultado de dicha operacin al cliente.

BIBLIOGRAFIA

http://www.ecured.cu/index.php/Llamada_a_Procedimiento_Remoto#RPC

http://es.wikipedia.org/wiki/Socket_de_Internet http://www.fermu.com/es/451 http://www.slideshare.net/dianapaolalozano/rpc-llamadas-remotas