1) El documento trata sobre RPC (Remote Procedure Call) o llamadas a procedimientos remotos. 2) RPC permite ejecutar código en otra máquina remota de forma transparente para el programador. 3) RPC utiliza stubs y skeletons para empaquetar y desempaquetar los datos de la llamada remota de forma transparente.
Remote Procedure Call in Distributed SystemPoojaBele1
Presentation to give description about the remote procedure call in distributed systems
Presentation covers some points on remote procedure call in distributed systems
Bases de datos distribuidas heterogéneasJuan Anaya
Este documento describe las características de las bases de datos distribuidas heterogéneas, incluyendo que usan diferentes gestores de bases de datos y esquemas en cada sitio de manera autónoma. Explica los tipos de heterogeneidad que pueden existir debido a diferencias en los sistemas de gestión de bases de datos o en la semántica de los datos. También cubre los retos de procesar consultas y transacciones entre bases de datos heterogéneas de manera distribuida.
El documento describe el middleware, que es un software que permite la comunicación entre aplicaciones y sistemas. Explica que el middleware simplifica el trabajo de los programadores en sistemas distribuidos al generar conexiones entre aplicaciones. Luego detalla los diferentes tipos de middleware como procesamiento de transacciones, llamadas a procedimientos remotos, orientado a mensajes y corredores de objetos. Finalmente, describe algunos productos de middleware de Oracle y sus características.
El documento habla sobre los objetivos y fases del procesamiento de consultas en sistemas de bases de datos relacionales. Los objetivos son transformar consultas de alto nivel a estrategias de ejecución de bajo nivel para extraer datos de forma eficiente. El procesamiento se divide en cuatro fases: descomposición, optimización, generación de código y ejecución. La descomposición transforma consultas a álgebra relacional y comprueba corrección sintáctica y semántica.
El documento describe las arquitecturas de objetos distribuidos. Elimina la distinción entre cliente y servidor, donde los componentes son objetos que proporcionan y requieren servicios. Los objetos se comunican a través de middleware y pueden distribuirse en varias computadoras de una red. Esto permite retrasar decisiones sobre dónde se proporcionan servicios y añadir nuevos recursos de forma flexible y escalable.
Este documento trata sobre la programación en cliente-servidor de bajo nivel utilizando sockets y canales. Explica conceptos como sockets, dominios y tipos de sockets, y la creación, implementación y supresión de sockets. También describe el desarrollo del lado del servidor y cliente con sockets, incluyendo constructores y métodos importantes. El objetivo es comprender la comunicación entre procesos a través de sockets para desarrollar aplicaciones cliente-servidor.
PROTOCOLOS SIMPLES PARA GESTIÓN DE REDESEquipoSCADA
Este documento describe varios protocolos de comunicación de red como TCP, IP, TCP/IP, UDP, ARP y SNMP. Explica brevemente el propósito y funcionamiento de cada protocolo. También discute conceptos como agentes, objetos gestionados y sistemas de administración de red en el contexto de SNMP. El documento provee información fundamental sobre protocolos comúnmente usados para la gestión y monitoreo remoto de redes.
Remote procedure call on client server computingSatya P. Joshi
Remote procedure call on client server computing, what is Remote procedure call on client server computing, Remote procedure call on java, Remote procedure call on client server computing
Remote Procedure Call in Distributed SystemPoojaBele1
Presentation to give description about the remote procedure call in distributed systems
Presentation covers some points on remote procedure call in distributed systems
Bases de datos distribuidas heterogéneasJuan Anaya
Este documento describe las características de las bases de datos distribuidas heterogéneas, incluyendo que usan diferentes gestores de bases de datos y esquemas en cada sitio de manera autónoma. Explica los tipos de heterogeneidad que pueden existir debido a diferencias en los sistemas de gestión de bases de datos o en la semántica de los datos. También cubre los retos de procesar consultas y transacciones entre bases de datos heterogéneas de manera distribuida.
El documento describe el middleware, que es un software que permite la comunicación entre aplicaciones y sistemas. Explica que el middleware simplifica el trabajo de los programadores en sistemas distribuidos al generar conexiones entre aplicaciones. Luego detalla los diferentes tipos de middleware como procesamiento de transacciones, llamadas a procedimientos remotos, orientado a mensajes y corredores de objetos. Finalmente, describe algunos productos de middleware de Oracle y sus características.
El documento habla sobre los objetivos y fases del procesamiento de consultas en sistemas de bases de datos relacionales. Los objetivos son transformar consultas de alto nivel a estrategias de ejecución de bajo nivel para extraer datos de forma eficiente. El procesamiento se divide en cuatro fases: descomposición, optimización, generación de código y ejecución. La descomposición transforma consultas a álgebra relacional y comprueba corrección sintáctica y semántica.
El documento describe las arquitecturas de objetos distribuidos. Elimina la distinción entre cliente y servidor, donde los componentes son objetos que proporcionan y requieren servicios. Los objetos se comunican a través de middleware y pueden distribuirse en varias computadoras de una red. Esto permite retrasar decisiones sobre dónde se proporcionan servicios y añadir nuevos recursos de forma flexible y escalable.
Este documento trata sobre la programación en cliente-servidor de bajo nivel utilizando sockets y canales. Explica conceptos como sockets, dominios y tipos de sockets, y la creación, implementación y supresión de sockets. También describe el desarrollo del lado del servidor y cliente con sockets, incluyendo constructores y métodos importantes. El objetivo es comprender la comunicación entre procesos a través de sockets para desarrollar aplicaciones cliente-servidor.
PROTOCOLOS SIMPLES PARA GESTIÓN DE REDESEquipoSCADA
Este documento describe varios protocolos de comunicación de red como TCP, IP, TCP/IP, UDP, ARP y SNMP. Explica brevemente el propósito y funcionamiento de cada protocolo. También discute conceptos como agentes, objetos gestionados y sistemas de administración de red en el contexto de SNMP. El documento provee información fundamental sobre protocolos comúnmente usados para la gestión y monitoreo remoto de redes.
Remote procedure call on client server computingSatya P. Joshi
Remote procedure call on client server computing, what is Remote procedure call on client server computing, Remote procedure call on java, Remote procedure call on client server computing
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS Lina Chavez
Este documento describe diferentes tipos de servidores, incluyendo servidores dedicados y no dedicados, servidores FTP, de seguridad, de archivos, de impresión, de correo, bases de datos, web, fax, telefonía, uso y proxy. Cada tipo de servidor tiene funciones específicas como almacenar y distribuir archivos, transferir archivos de forma estable, comprobar paquetes entrantes, traducir nombres de dominio a direcciones IP, procesar aplicaciones web, administrar el tráfico de faxes y llamadas telefón
This document discusses remote procedure calls (RPC) and distributed deadlock detection. It begins with an overview of RPC, describing how it allows programs to call procedures located on other machines using the client-server model. It then covers some issues in RPC like structure, binding, and parameter/result passing. Finally, it briefly introduces distributed deadlock detection and the DDD algorithm.
SUN Network File system - Design, Implementation and Experience aniadkar
Overview of SUN Network File system and its design, architecture and implementation along with changes in NFS v3 and NFS v4
Presented by – Aniruddh Adkar
CSE 710 Parallel and Distributed File Systems ( Spring 2016 )
SUNY, University at Buffalo
RPC allows a program to call a subroutine that resides on a remote machine. When a call is made, the calling process is suspended and execution takes place on the remote machine. The results are then returned. This makes the remote call appear local to the programmer. RPC uses message passing to transmit information between machines and allows communication between processes on different machines or the same machine. It provides a simple interface like local procedure calls but involves more overhead due to network communication.
Este documento presenta un resumen de las notas para la asignatura de Sistemas Distribuidos. El texto introduce el objetivo del curso, que es enseñar conceptos y técnicas relacionadas con los sistemas distribuidos. Se explica que los sistemas distribuidos son importantes para el diseño de sistemas de información en las organizaciones. El documento contiene 12 capítulos que cubren temas como redes, modelos de arquitectura, comunicación entre procesos, sincronización, transacciones distribuidas y sistemas operat
Este documento describe las principales técnicas de conmutación de redes, incluyendo conmutación de circuitos, conmutación de mensajes y conmutación de paquetes. La conmutación de circuitos establece un circuito físico dedicado entre los extremos de la transmisión, mientras que la conmutación de mensajes y paquetes dividen los mensajes en unidades más pequeñas que se envían de forma independiente a través de la red. La conmutación de paquetes es más eficiente al aprovechar mejor los recursos de transmisión y reducir retrasos.
Este documento trata sobre las llamadas a procedimientos remotos (RPC). Brevemente describe:
1) Las RPC permiten construir aplicaciones distribuidas sobre TCP/IP de forma sencilla.
2) Las RPC definen la sintaxis y formato de los mensajes mediante un lenguaje de definición de interfaces (IDL).
3) El proceso cliente envía los argumentos al servidor y espera el resultado, mientras que el servidor ejecuta el procedimiento localmente y devuelve el resultado.
Este documento trata sobre los sistemas distribuidos. Explica que un sistema distribuido es la unión lógica de sistemas operativos en nodos independientes conectados en red. Cada nodo contiene un subconjunto específico de programas que componen el sistema operativo distribuido. También describe diferentes tipos de sistemas distribuidos como sistemas de computación distribuida, sistemas de información distribuida y sistemas distribuidos empotrados. Además, explica conceptos como transparencia, eficiencia, flexibilidad y escal
SSH es un protocolo que permite conexiones seguras remotas al encriptar todo el tráfico de datos. Proporciona autenticación del cliente y servidor, encriptación de datos de hasta 128 bits y reenvío seguro de aplicaciones X11 y puertos TCP. Requiere las bibliotecas OpenSSL y es implementado por paquetes como OpenSSH que permiten conexiones seguras por SSH.
Este documento resume varios protocolos clave de la capa de aplicación y presentación del modelo OSI, incluyendo FTP, DNS, DHCP, HTTP, NAT, POP, SMTP, SSH, Telnet, TFTP, LDAP, AFP, ICA, LPP, NCP, NDR, XDR y Telnet. Describe brevemente el propósito y función de cada protocolo.
X.25 es un protocolo estándar para la transmisión de datos a través de redes de conmutación de circuitos. Ofrece un servicio fiable orientado a conexión mediante la técnica de almacenamiento y reenvío con confirmación de recepción en cada nodo. Frame Relay es un protocolo más rápido y eficiente que simplifica el protocolo X.25 al eliminar funciones como el control de errores y flujo a nivel de red.
La capa de red es responsable del enrutamiento y direccionamiento de datos a través de redes. Utiliza direcciones jerárquicas únicas para identificar dispositivos más allá de una sola red. Los routers evalúan las rutas disponibles y establecen la mejor para enviar paquetes de datos, tomando decisiones basadas en factores como la densidad de tráfico.
Este documento presenta una introducción a los modelos fundamentales de sistemas distribuidos. Explica brevemente los modelos de interacción, fallos y seguridad, así como los modelos arquitectónicos más comunes como cliente-servidor, procesos peer-to-peer y capas de software. Finalmente, analiza conceptos clave como interfaces, objetos distribuidos e invocación remota en sistemas distribuidos.
Este documento describe y compara diferentes tecnologías WAN, incluyendo PPP, XDSL, Frame Relay, ISDN y ATM. Explica brevemente qué son, cómo funcionan, sus velocidades de transmisión, componentes, ventajas y desventajas. PPP y XDSL son tecnologías de línea simple que transmiten datos; Frame Relay usa conexiones dedicadas; ISDN transmite voz y datos digitalmente; y ATM aprovecha la capacidad de sistemas de transmisión.
Protocolos de enrutamiento vector distancia 28 2-2011tiutn
Este documento describe los protocolos de enrutamiento por vector de distancia como RIP e IGRP. Explica que estos protocolos utilizan el conteo de saltos como métrica y comparten información de enrutamiento a través de actualizaciones periódicas. También cubre conceptos como vectores de distancia, algoritmos de cálculo de rutas, características, ventajas y desventajas de estos protocolos de enrutamiento.
Este documento describe las amenazas y vulnerabilidades más comunes a los sistemas de información. Explica que las amenazas incluyen factores humanos, hardware, software, redes y desastres naturales. Las vulnerabilidades más frecuentes son contraseñas predeterminadas, llaves compartidas predeterminadas, suplantación de IP, interceptación pasiva, vulnerabilidades de servicios y aplicaciones. También describe técnicas de cifrado como simétrico, asimétrico e híbrido, y explica que los mecanismos de protección controlan el
Configuracion y administracion del espacio en discoYael_21
1) Existen cuatro conceptos clave para la gestión del almacenamiento en Oracle: bloques, extensiones, segmentos y espacios de tablas. 2) Los segmentos contienen objetos de la base de datos como tablas y almacenan datos en extensiones que se añaden a medida que el segmento crece. 3) La memoria compartida contiene datos como la caché, tabla de bloqueos y registro de transacciones pendientes de volcar al almacenamiento.
This document discusses remote invocation and summarizes key aspects of remote procedure call (RPC). It describes RPC as extending normal function calling such that the called and calling procedures are not in the same address space. RPC involves invoking remote elements through methods like request-reply protocol and remote method invocation. The document outlines the steps of an RPC call, including how client and server stubs are used to package requests and unpack responses to allow remote procedures to be called like local procedures.
Este documento discute varias tecnologías para aplicaciones distribuidas como .NET Remoting, WCF y CORBA. .NET Remoting permite trabajar con objetos remotos, WCF proporciona una plataforma de mensajería para sistemas distribuidos y CORBA establece un estándar para invocar métodos remotos de objetos en diferentes lenguajes y plataformas.
RPC permite que un programa ejecute código en otra máquina de forma remota sin preocuparse por las comunicaciones subyacentes. Esto se logra mediante stubs y skeletons que simulan la invocación local de funciones remotas. RPC abstrae los detalles de red para ofrecer un entorno de programación distribuido similar al local. Existen varias implementaciones de RPC como Sun RPC, DCE/RPC, Java RMI, CORBA y DCOM.
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS Lina Chavez
Este documento describe diferentes tipos de servidores, incluyendo servidores dedicados y no dedicados, servidores FTP, de seguridad, de archivos, de impresión, de correo, bases de datos, web, fax, telefonía, uso y proxy. Cada tipo de servidor tiene funciones específicas como almacenar y distribuir archivos, transferir archivos de forma estable, comprobar paquetes entrantes, traducir nombres de dominio a direcciones IP, procesar aplicaciones web, administrar el tráfico de faxes y llamadas telefón
This document discusses remote procedure calls (RPC) and distributed deadlock detection. It begins with an overview of RPC, describing how it allows programs to call procedures located on other machines using the client-server model. It then covers some issues in RPC like structure, binding, and parameter/result passing. Finally, it briefly introduces distributed deadlock detection and the DDD algorithm.
SUN Network File system - Design, Implementation and Experience aniadkar
Overview of SUN Network File system and its design, architecture and implementation along with changes in NFS v3 and NFS v4
Presented by – Aniruddh Adkar
CSE 710 Parallel and Distributed File Systems ( Spring 2016 )
SUNY, University at Buffalo
RPC allows a program to call a subroutine that resides on a remote machine. When a call is made, the calling process is suspended and execution takes place on the remote machine. The results are then returned. This makes the remote call appear local to the programmer. RPC uses message passing to transmit information between machines and allows communication between processes on different machines or the same machine. It provides a simple interface like local procedure calls but involves more overhead due to network communication.
Este documento presenta un resumen de las notas para la asignatura de Sistemas Distribuidos. El texto introduce el objetivo del curso, que es enseñar conceptos y técnicas relacionadas con los sistemas distribuidos. Se explica que los sistemas distribuidos son importantes para el diseño de sistemas de información en las organizaciones. El documento contiene 12 capítulos que cubren temas como redes, modelos de arquitectura, comunicación entre procesos, sincronización, transacciones distribuidas y sistemas operat
Este documento describe las principales técnicas de conmutación de redes, incluyendo conmutación de circuitos, conmutación de mensajes y conmutación de paquetes. La conmutación de circuitos establece un circuito físico dedicado entre los extremos de la transmisión, mientras que la conmutación de mensajes y paquetes dividen los mensajes en unidades más pequeñas que se envían de forma independiente a través de la red. La conmutación de paquetes es más eficiente al aprovechar mejor los recursos de transmisión y reducir retrasos.
Este documento trata sobre las llamadas a procedimientos remotos (RPC). Brevemente describe:
1) Las RPC permiten construir aplicaciones distribuidas sobre TCP/IP de forma sencilla.
2) Las RPC definen la sintaxis y formato de los mensajes mediante un lenguaje de definición de interfaces (IDL).
3) El proceso cliente envía los argumentos al servidor y espera el resultado, mientras que el servidor ejecuta el procedimiento localmente y devuelve el resultado.
Este documento trata sobre los sistemas distribuidos. Explica que un sistema distribuido es la unión lógica de sistemas operativos en nodos independientes conectados en red. Cada nodo contiene un subconjunto específico de programas que componen el sistema operativo distribuido. También describe diferentes tipos de sistemas distribuidos como sistemas de computación distribuida, sistemas de información distribuida y sistemas distribuidos empotrados. Además, explica conceptos como transparencia, eficiencia, flexibilidad y escal
SSH es un protocolo que permite conexiones seguras remotas al encriptar todo el tráfico de datos. Proporciona autenticación del cliente y servidor, encriptación de datos de hasta 128 bits y reenvío seguro de aplicaciones X11 y puertos TCP. Requiere las bibliotecas OpenSSL y es implementado por paquetes como OpenSSH que permiten conexiones seguras por SSH.
Este documento resume varios protocolos clave de la capa de aplicación y presentación del modelo OSI, incluyendo FTP, DNS, DHCP, HTTP, NAT, POP, SMTP, SSH, Telnet, TFTP, LDAP, AFP, ICA, LPP, NCP, NDR, XDR y Telnet. Describe brevemente el propósito y función de cada protocolo.
X.25 es un protocolo estándar para la transmisión de datos a través de redes de conmutación de circuitos. Ofrece un servicio fiable orientado a conexión mediante la técnica de almacenamiento y reenvío con confirmación de recepción en cada nodo. Frame Relay es un protocolo más rápido y eficiente que simplifica el protocolo X.25 al eliminar funciones como el control de errores y flujo a nivel de red.
La capa de red es responsable del enrutamiento y direccionamiento de datos a través de redes. Utiliza direcciones jerárquicas únicas para identificar dispositivos más allá de una sola red. Los routers evalúan las rutas disponibles y establecen la mejor para enviar paquetes de datos, tomando decisiones basadas en factores como la densidad de tráfico.
Este documento presenta una introducción a los modelos fundamentales de sistemas distribuidos. Explica brevemente los modelos de interacción, fallos y seguridad, así como los modelos arquitectónicos más comunes como cliente-servidor, procesos peer-to-peer y capas de software. Finalmente, analiza conceptos clave como interfaces, objetos distribuidos e invocación remota en sistemas distribuidos.
Este documento describe y compara diferentes tecnologías WAN, incluyendo PPP, XDSL, Frame Relay, ISDN y ATM. Explica brevemente qué son, cómo funcionan, sus velocidades de transmisión, componentes, ventajas y desventajas. PPP y XDSL son tecnologías de línea simple que transmiten datos; Frame Relay usa conexiones dedicadas; ISDN transmite voz y datos digitalmente; y ATM aprovecha la capacidad de sistemas de transmisión.
Protocolos de enrutamiento vector distancia 28 2-2011tiutn
Este documento describe los protocolos de enrutamiento por vector de distancia como RIP e IGRP. Explica que estos protocolos utilizan el conteo de saltos como métrica y comparten información de enrutamiento a través de actualizaciones periódicas. También cubre conceptos como vectores de distancia, algoritmos de cálculo de rutas, características, ventajas y desventajas de estos protocolos de enrutamiento.
Este documento describe las amenazas y vulnerabilidades más comunes a los sistemas de información. Explica que las amenazas incluyen factores humanos, hardware, software, redes y desastres naturales. Las vulnerabilidades más frecuentes son contraseñas predeterminadas, llaves compartidas predeterminadas, suplantación de IP, interceptación pasiva, vulnerabilidades de servicios y aplicaciones. También describe técnicas de cifrado como simétrico, asimétrico e híbrido, y explica que los mecanismos de protección controlan el
Configuracion y administracion del espacio en discoYael_21
1) Existen cuatro conceptos clave para la gestión del almacenamiento en Oracle: bloques, extensiones, segmentos y espacios de tablas. 2) Los segmentos contienen objetos de la base de datos como tablas y almacenan datos en extensiones que se añaden a medida que el segmento crece. 3) La memoria compartida contiene datos como la caché, tabla de bloqueos y registro de transacciones pendientes de volcar al almacenamiento.
This document discusses remote invocation and summarizes key aspects of remote procedure call (RPC). It describes RPC as extending normal function calling such that the called and calling procedures are not in the same address space. RPC involves invoking remote elements through methods like request-reply protocol and remote method invocation. The document outlines the steps of an RPC call, including how client and server stubs are used to package requests and unpack responses to allow remote procedures to be called like local procedures.
Este documento discute varias tecnologías para aplicaciones distribuidas como .NET Remoting, WCF y CORBA. .NET Remoting permite trabajar con objetos remotos, WCF proporciona una plataforma de mensajería para sistemas distribuidos y CORBA establece un estándar para invocar métodos remotos de objetos en diferentes lenguajes y plataformas.
RPC permite que un programa ejecute código en otra máquina de forma remota sin preocuparse por las comunicaciones subyacentes. Esto se logra mediante stubs y skeletons que simulan la invocación local de funciones remotas. RPC abstrae los detalles de red para ofrecer un entorno de programación distribuido similar al local. Existen varias implementaciones de RPC como Sun RPC, DCE/RPC, Java RMI, CORBA y DCOM.
El documento introduce los conceptos básicos de middleware, incluyendo su definición como software que permite la interacción entre aplicaciones en un ambiente distribuido, los tipos principales como RPC, MOM, data middleware y ORBs, y ejemplos de plataformas middleware como servidores de aplicaciones e integration brokers. También describe características como la interacción síncrona y asíncrona, y el uso de middleware para integrar aplicaciones a escala empresarial.
El documento describe los middleware. Los middleware permiten simplificar el desarrollo de aplicaciones distribuidas al ofrecer servicios de conectividad entre aplicaciones y plataformas heterogéneas. Los middleware también facilitan el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas actuando como una capa de abstracción entre las aplicaciones y los sistemas operativos subyacentes. Existen diferentes tipos de middleware como los orientados a bases de datos, llamadas a procedimientos remotos, correta de objetos y mensajería.
El documento describe los middleware. Los middleware permiten simplificar el desarrollo de aplicaciones distribuidas al ofrecer servicios de conectividad entre aplicaciones y plataformas heterogéneas. Los middleware también facilitan el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas actuando como una capa de abstracción entre las aplicaciones y los sistemas operativos subyacentes. Existen diferentes tipos de middleware como los orientados a bases de datos, llamadas a procedimientos remotos, correta de objetos y monitores de transacciones distribuid
El documento describe el protocolo de llamada a procedimiento remoto (RPC), el cual permite a un programa ejecutar código en otra máquina de forma remota sin preocuparse por las comunicaciones. RPC funciona a través de stubs y skeletons que encapsulan las comunicaciones entre el cliente y servidor, permitiendo al programador tratar las llamadas como si fueran locales. RPC se usa comúnmente para comunicación entre procesos en redes de computadoras.
El documento describe los conceptos clave de los middleware. Explica que el middleware es un software que permite la interacción entre aplicaciones al simplificar la conexión entre sistemas distribuidos. Luego detalla algunos tipos comunes de middleware como los monitores de transacciones, las llamadas a procedimientos remotos y el middleware orientado a mensajes. Finalmente, resalta las ventajas y usos de los productos de middleware de Oracle.
El documento describe los conceptos clave de los middleware. Explica que el middleware es un software que permite la interacción entre aplicaciones al simplificar la comunicación entre ellas. Luego detalla los principales tipos de middleware como los monitores de transacciones, las llamadas a procedimientos remotos, el middleware orientado a mensajes y los corredores de objetos. Finalmente, se enfoca en el middleware orientado a mensajes describiendo sus ventajas y cómo permite el intercambio asincrónico de datos entre procesos distribuidos a través del paso de mensajes.
El documento describe los conceptos clave de los middleware. Explica que el middleware es un software que permite la interacción entre aplicaciones al simplificar la conexión entre sistemas distribuidos. Luego detalla algunos tipos comunes de middleware como los monitores de transacciones, las llamadas a procedimientos remotos y el middleware orientado a mensajes. Finalmente, resalta las ventajas y usos de los productos de middleware de Oracle.
Net Remoting permite crear aplicaciones distribuidas al permitir que un cliente trabaje con objetos alojados en otra máquina de forma remota. WCF reemplaza a Net Remoting y permite construir aplicaciones orientadas a servicios que interactúan a través de diferentes plataformas y organizaciones. CORBA establece un estándar que facilita la invocación remota de métodos bajo un paradigma orientado a objetos al envolver código en diferentes lenguajes para que pueda ser invocado a través de una red.
Este documento describe y compara tres estilos arquitectónicos principales: centralizados, descentralizados y híbridos (distribuidos). Los sistemas centralizados concentran todos los recursos en un solo servidor central, mientras que los descentralizados distribuyen los recursos entre múltiples servidores. Los sistemas híbridos combinan elementos de ambos estilos para lograr una arquitectura más escalable y eficiente.
El documento describe conceptos relacionados con el desarrollo ágil de servicios móviles. Explica la arquitectura de clientes y servidores, el proceso de desarrollo, y métodos como Extreme Programming. También cubre temas como servicios móviles, arquitecturas de aplicaciones, ciclo de vida del desarrollo de software, pruebas y herramientas de desarrollo.
El documento trata sobre el desarrollo ágil de servicios móviles. Explica conceptos como servicios móviles, arquitecturas de clientes y servidores, procesos de desarrollo ágiles y herramientas. Detalla aspectos como la arquitectura cliente-servidor, los componentes de una aplicación móvil como midlets, y métodos como Extreme Programming para el desarrollo rápido de aplicaciones.
Arquitectura de sistemas distribuidos-grupo Mariagequito
Este documento describe los conceptos fundamentales de la arquitectura de sistemas distribuidos. Explica que estos sistemas consisten en una colección de ordenadores autónomos interconectados por una red que actúan como un servicio integrado. También describe características clave como la sincronización, concurrencia y tolerancia a fallos, así como ejemplos de arquitecturas como cliente-servidor y middleware.
Arquitectura de sistemas distribuidos-Grupo de Mariagequito
Este documento describe los conceptos fundamentales de la arquitectura de sistemas distribuidos. Explica que estos sistemas consisten en una colección de ordenadores autónomos interconectados por una red que actúan como un servicio integrado. También describe características clave como la sincronización, concurrencia y tolerancia a fallos, así como ejemplos de arquitecturas como cliente-servidor y middleware.
Net Remoting permite crear aplicaciones distribuidas fácilmente mediante la comunicación entre procesos y equipos a través de canales, utilizando codificación binaria o XML. WCF es una plataforma de mensajería orientada a servicios que permite el desarrollo rápido de sistemas distribuidos de forma segura a través de Internet o una red. CORBA define una arquitectura para objetos distribuidos donde los servicios de un objeto están dados por su interfaz IDL y los objetos están identificados por referencias.
Net Remoting permite crear aplicaciones distribuidas fácilmente mediante la comunicación entre procesos y equipos a través de canales, utilizando codificación binaria o XML. WCF es una plataforma de mensajería orientada a servicios que permite el desarrollo rápido de sistemas distribuidos de forma segura a través de Internet o una red. CORBA define una arquitectura para objetos distribuidos donde los servicios de un objeto están dados por su interfaz IDL y los objetos están identificados por referencias.
La comunicación entre procesos es clave para sistemas distribuidos y existen varios paradigmas como cliente-servidor, llamadas a procedimientos remotos y comunicación en grupo. Los datos deben empaquetarse antes de enviar y representarse de forma consistente. El modelo cliente-servidor usa solicitudes y respuestas mientras que las llamadas a procedimientos remotos buscan mayor transparencia. La comunicación en grupo permite comunicación uno-a-muchos o muchos-a-uno de forma dinámica. El middleware provee servicios comunes para aplicaciones distribuidas.
Este documento trata sobre objetos distribuidos e invocación remota. Explica tres modelos de programación para aplicaciones distribuidas: llamada a procedimiento remoto, invocación remota de métodos, y programación basada en eventos. También describe conceptos como middleware, interfaces, lenguajes de definición de interfaces, y el modelo de objetos distribuidos.
Este documento presenta información sobre un taller de programación distribuida que forma parte del cuarto semestre de la carrera de Computación e Informática. El taller es impartido por el Ingeniero Carlos Rios Campos y los alumnos inscritos son Antón Paico Mary Carmen, Manayay Chávez, Rommel Joan, y Piscoya Olazabal, Gaby Geraldine.
1. RPC (Remote Procedure Call)
César Cury Vergara
Roger Rodríguez Reyes
Ing. John Méndez Alandete
Corporacion Universitaria del Caribe “CECAR”
Facultad de Ingeniería
Programa Ingeniería de Sistemas
Asignatura Sistemas Distribuidos
Sincelejo – Sucre
Septiembre de 2010
2. ÍNDICE
1. Middleware
Definición
Clasificación de los Middleware:
– Orientado a transacciones
– Orientado a mensajes
– Basado en RPC
– Orientado a objetos
– Basado en grupos
2. Remote Procedure Call(RPC)
Definiciones
Características
Arquitectura
Modelo
Ventajas y Desventajas con respecto a otros Middleware
¿Cómo se logra la transparencia de acceso XDR (eXternal Data
Representation)?
¿Cómo se logra la transparencia de localización (binding)?
RPC Síncrono
RPC Asíncrono
Portmapper
3. Palabras claves: Middleware, RPC, Stubs.
Middleware
Definiciones:
[1] “Software de conectividad que consiste en un conjunto de servicios que permiten
interactuar a múltiples procesos que se ejecutan en distintas máquinas a través de la red”.
[2] Conjunto de herramientas que proporcionan una manera uniforme de acceder a los
recursos del sistema en todas las plataformas.
[3] Capa de software que ejecuta sobre el sistema operativo local ofreciendo unos
servicios distribuidos estandarizados.
Podemos clasificar los middleware en cinco tipos representativos: orientado a
transacciones, orientado a mensajes, basado en RPC, orientado a objetos distribuidos y
orientado a grupos. En los siguientes apartados veremos cuáles son las características
representativas de cada uno de ellos.
4. Middleware orientado a transacciones
Este tipo de middleware facilita el desarrollo de sistemas que requieren transacciones
distribuidas. La transacción asegura que un conjunto de operaciones se realicen en todos
los nodos del sistema o en ninguno. Generalmente se utilizan en aplicaciones que
requieren consistencia de estado entre componentes distribuidos.
Middleware orientado a mensajes
Este tipo de middleware facilita la comunicación mediante intercambio de mensajes. Los
mensajes pueden ser utilizados para solicitar la ejecución de servicios remotos, para
notificación distribuida de eventos, o para implementar sistemas basados en publicación-
suscripción.
Middleware basado en RPC
Este tipo de middleware proporciona gestión eficiente de llamadas remotas a
procedimiento (Remote Procedure Call --RPC). La principal ventaja de la RPC es que
permite definir la interfaz de comunicación con los componentes mediante un lenguaje de
definición de interfaz (Interface Definition Language --IDL). A partir de esta definición
existen herramientas automáticas de generación de código que generan el código
necesario para realizar el empaquetado/desempaquetado de los mensajes y gestionar la
comunicación a través de la red. Además, la RPC tiene implementaciones ( bindings) para
múltiples sistemas operativos y lenguajes de programación, aspecto que le convierten en
una solución interesante para la programación de sistemas distribuidos multi-plataforma.
Desde la perspectiva de los desarrolladores, la RPC además facilita la reutilización de
código, ya que se utiliza de forma semejante a una llamada a procedimiento local.
Middleware orientado a objetos
El middleware orientado a objetos es una extensión del middleware orientado a RPC que
agrega muchas características propias de los lenguajes de programación orientados a
objetos. Estas extensiones incluyen soporte para herencia, referencias a objetos y soporte
de excepciones.
El middleware orientado a objetos comparte muchas de las ventajas atribuidas al
middleware basado en RPC. De nuevo, el empaquetado y desempaquetado son generados
automáticamente por los suplentes del cliente y del servidor, liberando al programador de
esta tarea propensa al error. El middleware orientado a objetos soporta peticiones
síncronas como mecanismo de comunicación por defecto. No obstante muchos sistemas
5. también incluyen soporte para comunicación asíncrona, transacciones distribuidas y
mensajería, por lo que, en muchos aspectos, pueden utilizarse para sustituir cualquiera de
los middleware descritos anteriormente. Esta combinación de características lo convierte
en un middleware potente y flexible.
Al igual que ocurre con los middleware orientados a RPC, el principal inconveniente de
este tipo de middleware es la escalabilidad. Otro inconveniente es que este tipo de
middleware no siempre puede utilizarse en entornos y lenguajes de programación no
orientados a objetos, lo que da lugar a aplicaciones más complejas.
Ejemplos representativos de este tipo de middleware son Java RMI, JavaBeans, DCOM, y
CORBA.
Java RMI y Enterprise JavaBeans de Sun Microsystems. Java RMI proporciona
invocación remota de métodos en Java. Permite construir aplicaciones distribuidas
donde la máquina virtual de Java (Java Virtual Machine --JVM) puede realizar
invocación remota de objetos disponibles en otras JVM localizadas en otros nodos
de la red. Java RMI también proporciona soporte dinámico para la serialización de
objetos completos (para pasarlos como parámetros). Esta flexibilidad es posible
gracias a la arquitectura de la máquina virtual de Java, simplificada enormemente
por el uso un único lenguaje de programación.
Distributed Component Object Model (DCOM) de Microsoft. DCOM permite a los
componentes software comunicarse sobre una red usando instanciación de
componentes e invocación de métodos remotos. El principal inconveniente de
DCOM es que sólo está disponible en plataformas Windows.
Common Object Request Broker Architecture (CORBA). CORBA es una
especificación de la arquitectura middleware que proporciona soporte al
paradigma de programación cliente-servidor orientada a objeto para sistemas
distribuidos heterogéneos. CORBA oculta el acceso a objetos remotos mediante la
invocación local sobre un representante (proxy) del objeto remoto. CORBA es
parte de Object Management Architecture y ha sido definido por el Object
Management Group (OMG).
Middleware basado en grupos
El simple intercambio de mensajes entre un emisor y un receptor, no es siempre un buen
modelo de comunicación para un sistema distribuido. En muchas situaciones es más útil
disponer de primitivas que permitan enviar datos desde un emisor a un grupo de procesos.
Este tipo de comunicación es habitual en sistemas con requisitos de tolerancia a fallos,
disponibilidad de servicio o reparto de carga. En estos casos, suele ser más sencillo diseñar
la aplicación utilizando radiado de mensajes (multicast) en vez del envío punto a punto
(unicast).
6. Remote Procedure Call (RPC)
Definiciones:
Es el Middleware diseñado como servicio síncrono para permitir la gestión remota
de redes. Esconde las operaciones de envío y recepción bajo el aspecto de una
llamada convencional a una rutina o procedimiento. Los RPC tienen la misma
semántica que las llamadas a procedimientos ordinarios; es decir, se realiza la
llamada y se pasa el control al procedimiento servidor; cuando éste devuelve el
resultado, el cliente recupera el control.
Es un protocolo que permite a un programa de ordenador ejecutar código en otra
máquina remota sin tener que preocuparse por las comunicaciones entre ambas.
El RPC es una interfaz de programación de aplicación (API) disponible para el
desarrollo de aplicaciones distribuidas. Permite que los programas llamen a
subrutinas que se ejecutan en un sistema remoto.
Es una extensión del paradigma orientado a procedimientos (estructurado) que
consiste en hacer transparente para el programador la ubicación de las funciones
que invoca.
Es una técnica para el desarrollo de aplicaciones distribuidas, basadas en el
paradigma Cliente/Servidor.
Características:
Depende de la red y del estado del servidor, en consecuencia el manejo de errores
debe considerar esta característica;
Una RPC opera en forma más lenta que una llamada a un procedimiento local;
Requiere de autenticación;
Puede ser implementado sobre UDP o TCP;
El espacio de memoria del cliente y servidor son independientes;
La transferencia de datos en una RPC puede darse entre máquinas de diferentes
arquitecturas y sistemas operativos
XDR proporciona el estándar de codificación de datos (por ejemplo la longitud
mínima de cualquier campo ha de ser de 32 bits)
7. Arquitectura RPC
Figura 2. Arquitectura RPC.
Elementos de la arquitectura RPC:
Programa llamante, Programa llamado, Kernels (núcleos).
Los stubs:
Son librerías que emplean los programadores.
Se generan de forma automática.
Stub (Client): Es la representación del objeto remoto en la máquina local. Oculta todos los
detalles de la red. El “stub” oculta los detalles de la referencia al objeto remoto, el
empaquetado de los argumentos en un mensaje, el desempaquetado de los resultados y el
envío y recepción de los mensajes desde el cliente.
Stub (Server): Cuando llega un mensaje al servidor, el sistema operativo lo pasa al Stub
Server del proceso destino. El Stub Server es un trozo de código que transforma las
peticiones que le llegan de la red en llamadas a procedimientos locales. Antes de hacer la
invocación local, el esqueleto desempaqueta los argumentos del mensaje que ha recibido
y luego invoca el método correspondiente. El servidor realiza su trabajo y después
devuelve el resultado de la forma habitual. Cuando el esqueleto recibe el control una vez
que la ejecución del procedimiento finaliza, empaqueta el resultado en un mensaje de
respuesta que envía al cliente.
8. Funciones de los Stubs (Client, Server)
El stub cliente debe:
- Empaquetar los argumentos en un mensaje.
- Enviar el mensaje de invocación al servidor.
- Esperar el mensaje de respuesta.
- Desempaquetar los resultados (argumentos de salida) del mensaje de respuesta
- Devolver los resultados al código que invocó al stub.
El stub servidor debe:
- Esperar mensaje de invocación
- Desempaquetar los argumentos de la invocación.
- Realizar la invocación al procedimiento local y esperar a que termine.
- Empaquetar los argumentos de salida en el mensaje de respuesta.
- Enviar la respuesta al cliente.
9. Modelo RPC
Figura 3. Esquema RPC.
Los pasos que ejecuta un Cliente para invocar un procedimiento remoto en un Servidor
son los siguientes:
1. El Cliente llama un procedimiento local llamado el Client Stub (proxy).
2. El Client Stub empaqueta (marshalling) los parámetros, construye un mensaje y lo
envía al Kernel local.
3. El Kernel local lo envía al Kernel donde se encuentra el Server Stub
4. El Kernel remoto envía el mensaje al Server Stub.
5. El Server Stub desempaqueta (unmarshalling) los parámetros, identifica el
procedimiento y lo ejecuta.
6. El Server Stub recibe el resultado del servidor local
7. El Server Stub empaqueta (marshalling) la respuesta, construye un mensaje y lo
envía al Kernel.
8. El Kernel remoto lo envía de nuevo al Kernel local.
9. El Kernel local envía el mensaje al Client Stub.
10. Client Stub desempaqueta (unmarshalling) el resultado y lo retorna de la misma
forma que un procedimiento local.
10. Protocolos RPC:
Soporta uno o dos protocolos. Específicamente, las implementaciones ONC y DCE soportan
TCP y/o UDP como protocolos de transporte.
Figura 4. Protocolos RPC
La primera decisión es elegir entre un protocolo orientado a conexión o uno sin conexión:
Conexión:
Ventajas: comunicación más fácil, el núcleo del cliente no debe preocuparse de si
los mensajes se pierden o de si no hay reconocimiento.
Desventajas: En una LAN tiene pérdida de desempeño debido a que todo este
software adicional estorba, además la ventaja de no perder los paquetes no tiene
sentido ya que las LAN son confiables en esto.
Sin Conexión:
En general en sistemas dentro de un único edificio se utilizan protocolos sin conexión.
Mientras que en redes grandes se utiliza uno orientado a conexión.
Figura 5. Capas del Modelo OSI donde Trabaja RPC
11. Ventajas y desventajas de RPC con respecto a otros Middleware
Ventajas RPC
RPC ofrece un mecanismo de nivel más alto que los sockets
El mecanismo de enviar mensajes de solicitud y esperar la respuesta queda oculto
debajo de un esquema fácil de entender: llamar a un procedimiento, el cual
devuelve resultados
RPC ofrece un mecanismo de representación de datos independiente de la
máquina conocido como XDR (External Data Representation)
RPC facilita la definición del protocolo de comunicación (al nivel de aplicación)
Ventaja Principal: Es el middleware más maduro de todos.
Desventajas RPC
Cuando se requiere un alto grado de interconexión, conviene evitar el uso de RPC,
debido al alto consumo de procesamiento que conlleva, lo que baja notoriamente
el rendimiento.
RPC vs RMI
RPC
Obliga a utilizar el mismo lenguaje en ambos lado (cliente servidor).
Dependiente de la plataforma.
Poco escalable.
Diseño funcional de servicios, no orientados a objetos.
RMI
RPC orientado a objetos y multiplataforma.
Evolución hacia IIOP (CORBA): multiplataforma y multilenguaje.
Figura 6. Ventajas de RMI sobre RPC
12. RPC vs DCOM
DCOM cuenta con la característica de activación remota: Iniciar una aplicación mediante
una llamada a un componente, a diferencia de RPC.
RPC vs CORBA
La mayoría de los RPC siempre funcionará solamente en las mismas plataformas y con el
mismo conjunto de interfaces de lenguaje. El estilo RPC C en Solaris no necesariamente
funcionará con el estilo C RPC en Windows. Por otra parte, también podría estar vinculado
a un idioma específico y también un protocolo de red específico. No podemos llamar a
este estilo de interfaz de C a partir de Java (Nos dará compilador de los errores en el
primer paso en sí mismo). CORBA hecho resuelve estos problemas de la plataforma 3, de
funcionamiento y las dependencias de la red para un mecanismo RPC.
Tabla 1. Ventajas y Desventajas de los Middleware
Middleware Ventajas Desventajas
RPC
Por ser el primer tipo de Exige alto nivel de
Middleware es el menos procesamiento.
complicado de usar y
comprender. Tiene bajo rendimiento.
RMI
Gracias a la máquina Sólo para objetos Java.
virtual Java soporta
multiplataforma.
DCOM
Soporta multilenguaje. Especialmente diseñado
para trabajar sobre
sistemas operativos de
Microsoft®.
CORBA
Útil para desarrollar Al ser tan amplio, es más
sistemas P2P grandes, complejo que los otros
soporta multilenguaje Middleware.
de programación.
Soporta plataformas
y sistemas operativos
heterogéneos.
13. ¿Cómo se logra la transparencia de acceso?
External Data Representation (XDR)
Es un Standards utilizado para codificar los datos (parámetros de entrada y resultados)
en los mensajes RPC. Esta codificación permite que los valores que pasa una maquina
sean entendidos por la otra aunque utilicen una representación distinta para los datos.
XDR define numerosos tipos de datos, así como la manera en que han de transmitirse
en un mensaje RPC. El dato más pequeño ocupa 4 bytes.
Los mensajes de llamada y respuesta se formatean al estándar XDR.
La información almacenada dentro de los programas en ejecución se representa
mediante estructuras de datos (por ejemplo, por conjuntos de objetos
interrelacionados) mientras que la información transportada en los mensajes consiste
en secuencias de bytes. Independientemente de la forma de comunicación utilizada,
las estructuras de datos deben ser aplanadas o serializadas (convertidas a una
secuencia de bytes) antes de su transmisión y reconstruidas o deserializadas en el
destino.
Los tipos de datos primitivos transmitidos en los mensajes pueden tener valores de
muchos tipos distintos, y no todos los computadores almacenan los valores primitivos,
tales como los enteros, en el mismo orden. También es diferente en diferentes
arquitecturas la representación de los números en coma flotante. Otro problema es el
conjunto de códigos utilizado para representar los caracteres: por ejemplo, UNIX
utiliza la codificación ASCII con un byte por carácter, mientras que el estándar Unicode
permite representar textos en la mayoría de los lenguajes y utiliza dos bytes por
carácter. Existen dos variantes en la ordenación de enteros: la llamada big-endian, en
la que el byte más significativo va el primero, y la llamada little-endian, en la que va el
último.
Para hacer posible que dos computadores puedan intercambiar datos se puede utilizar
uno de los dos métodos siguientes:
Los valores se convierten a un formato externo acordado antes de la
transmisión y se revierten al formato local en la recepción; si los dos
computadores son del mismo tipo y lo saben, se puede omitir la
transformación al formato externo.
Los valores se transmiten según el formato del emisor, junto con una
indicación del formato utilizado, y el receptor los convierte si es necesario.
Hay que hacer notar, sin embargo, que los bytes no son alterados durante la
transmisión. Cualquier tipo de dato que pueda ser pasado como un argumento o
devuelto como resultado debe ser capaz de ser aplanado y cada uno de los tipos de
14. datos primitivos representados en una representación de datos acordada. Al estándar
acordado para la representación de estructuras de datos y valores primitivos se
denomina representación externa de datos.
El empaquetado (marshalling) consiste en tomar una colección de ítems de datos y
ensamblarlos de un modo adecuado para la transmisión de un mensaje. El
desempaquetado (unmarshalling) es el proceso de desensamblado en el destino para
producir una colección equivalente de datos. Por lo tanto, empaquetar consiste en
traducir las estructuras de datos y los valores primitivos en una representación externa
de datos. Similarmente, desempaquetar consiste en generar los valores primitivos
desde la representación de datos externa y reconstruir las estructuras de datos.
Esquema de generación de Stub (Cliente) y Stub (Server) a partir de la definición XDR
del interfaz remoto.
Tamaño del Bloque
La representación de todos los ítems es en múltiplo de cuatro bytes (si es necesario se
rellena con “ceros” para cumplir con esta condición)
Figura 7. Tamaño del bloque
15. ¿Cómo se logra la transparencia de localización?
Uno de los problemas existentes se basa en el direccionamiento al server, es decir la
forma en que el cliente localiza al servidor.
Una forma es incluir la dirección en el código del cliente, pero esto no sería muy
flexible a cambios. O sea que de existir cambios en la dirección del servidor se debería
recompilar el código del cliente. Para solucionar esto se plantea el binding.
Servicio de binding
Responsable de la transparencia de localización. Además funciona como un servicio
auxiliar que complementa a Client stub y Server stub.
– Gestiona la asociación entre el nombre del procedimiento Remoto (y su
versión) con su localización en la maquina servidor (dirección, puertos, Server
stub, etc.).
– Realiza la búsqueda del Server stub de la implementación concreta del
procedimiento remoto llamado por un cliente.
– Selecciona Server stub + servidor que atender a la llamada remota.
– Ejemplos: portmapper en Sun-RPC, protocolo UDDI en servicios web,
rmiregistry en Java-RMI.
Cuando el servidor inicia su ejecución:
Una llamada tipo initialize que se encuentra fuera del ciclo principal exporta la interfaz del
servidor:
El servidor envía un mensaje a un programa conector para darle a conocer su
existencia.
Esto es el registro del servidor (registering the server).
El servidor proporciona al conector su nombre, número de versión y un único
identificador.
El identificador generalmente tiene una longitud de 32 bits y un asa (handle) que
se utiliza para localizarlo.
16. El asa (handle) depende del sistema y puede ser:
Una dirección ethernet, ip, x.500.
Un identificador ralo de procesos, etc.
El asa también puede proporcionar información relativa a la autentificación.
Un servidor puede cancelar su registro con el conector si ya no está preparado para
prestar algún servicio.
El cliente localiza al servidor de la siguiente manera:
Cuando el cliente llama a alguno de los procedimientos remotos por primera vez:
El resguardo del cliente:
Ve que aún no está conectado a un servidor.
Envía un mensaje al conector solicitando la importación de cierta versión de cierta
interfaz.
El conector verifica si uno o más servidores ya han exportado una interfaz con ese
nombre y versión.
Si ninguno de los servidores en ejecución en ese momento soporta esa interfaz, la
llamada fracasa.
Si existe un servidor adecuado, el conector proporciona un asa e identificador
único al resguardo del cliente, que utiliza el asa como la dirección a la cual enviar el
mensaje solicitado.
La ventaja es que es un esquema muy flexible pero el conector puede ser un cuello de
botella con altas cargas de trabajo.
17. RPC Síncrono
– Las llamadas tradicionales a procedimiento remoto son síncronas, lo que
requiere que el proceso llamador espere hasta que el proceso llamado
devuelva un valor.
– Se comporta de manera muy parecida a una llamada a subrutina.
Figura 8. RPC síncrona
RPC Asíncrono
Optimización de RPC que permite que el cliente no tenga que esperar a que termine el
procedimiento, pero sí debe esperar un mensaje de respuesta.
– No bloquea al llamador.
– Permite que un cliente invoque repetidamente a un servidor, generando
una serie de peticiones de una vez.
Figura 9. RPC asíncrono
18. Diferencias entre RP síncrono y RPC asíncrono.
Las RPC asíncronas no bloquean al llamador.
RPC asíncronas ofrecer una mayor flexibilidad en el sentido de paralelismo.
En RPC asíncronas permiten que la ejecución de los clientes continúe localmente y
en paralelo con la invocación al servidor.
Las RPC síncronas requiere que el proceso llamador espere hasta que el proceso
llamado devuelva un valor.
Portmapper
Portmapper: proceso responsable de la localización de procedimientos remotos.
– Responsable de las tareas de registro y binding.
– Los servidores registran con el portmapper los procedimientos Remotos que
exportan.
– El portmapper queda a la escucha (puerto 111) y re direcciona las peticiones de
accesos a procedimientos hacia sus respectivos puertos locales de escucha.
Figura 10. Esquema Portmapper.
19. 1. Cuando un servidor establece una dirección de escucha de requerimientos,
registra los puertos al portmapper, también registra los programas RPC y números
de versiones, estos números pueden ser arbitrarios.
2. Antes de que un cliente pueda hacer una llamada remota, se consulta el
portmapper del servidor que identifica el número de puerto que por el cual recibe
los mensajes RPC.
3. El cliente y el servidor establecen un canal a través del cual se comunican para
ejecutar llamadas a procedimientos remotos.
Cada vez que se arranca uno de los servicio RPC en un servidor, se registra en el
servicio portmapper de dicho host asociándole un determinado valor de puerto a
dicho servicio.
Un cliente RPC contacta con el servicio Portmapper para obtener el valor del puerto
para un determinado RPC. Después envía el RPC a dicho puerto.
Figura 11.Ejemplo Portmapper
20. Anexos
Implementaciones más populares:
ONC-RCP (Open Network Computing, ONC-RCP), desarrollada por Sun Microsystem y
distribuida con casi todos los sistemas UNIX.
DCE-RPC (DCE, Distributed Computing Enviroment) definido por la Fundación de Software
Abierto (OSF, Open Software Foundation) e incluida en los sistemas operativos Windows.
Semántica de Fallos
A continuación se explicaran las soluciones a cada fallo:
21. (1) El Cliente No Puede Localizar al Servidor
El servidor podría estar inactivo.
El servidor podría estar utilizando una nueva versión de la interfaz y nuevos resguardos,
que no serían compatibles con la interfaz y los resguardos del cliente.
En el servidor, cada uno de los procedimientos regresa un valor:
Generalmente el código -1 indica un fallo.
También se suele utilizar una variable global (UNIX) errno a la que se asigna un
valor que indica el tipo de error.
Un tipo de error sería “no se pudo localizar al servidor”.
Otra posibilidad para el tratamiento de los errores es mediante una excepción provocada
por el error:
Se codifican procedimientos especiales que son llamados ante errores específicos.
El problema es que se puede destruir la transparencia deseada, ya que se dificulta
mantener la similitud entre procedimientos locales y remotos.
(2) Se pierde el mensaje de petición del cliente al servidor
El núcleo (kernel) debe inicializar un cronómetro al enviar la solicitud; si el tiempo se
termina antes de que regrese una respuesta o reconocimiento, el núcleo vuelve a enviar el
mensaje.
Si el mensaje realmente se perdió, el servidor no podrá indicar la diferencia entre la
retransmisión y el original y todo funcionará bien.
Si el número de mensajes perdidos supera cierto límite, el núcleo puede asumir que el
servidor está inactivo y se regresa a la situación “no se pudo localizar al servidor”.
(3) Se pierde el mensaje de respuesta del servidor al cliente
La pérdida de respuestas genera mayores problemas que la pérdida de solicitudes.
Se utiliza un cronómetro:
Si no llega una respuesta en un período razonable, se debe volver a enviar la
solicitud.
22. El problema es que el núcleo del cliente no está seguro de la razón por la que no
hubo respuesta.
Ciertas operaciones se pueden repetir con seguridad tantas veces como sea necesario sin
que ocurran daños; una solicitud con esta propiedad es idempotente.
Otras operaciones no son idempotentes, por ej. la transferencia de dinero:
Se emite una solicitud a un servidor bancario para transferir cierta suma de dinero.
La solicitud llega y se efectúa pero se pierde la respuesta.
El cliente considera que la solicitud se perdió y la emite nuevamente.
El servidor recibe la nueva solicitud y la ejecuta al no saber que es un reenvío de la
anterior.
Una forma de resolver el problema consiste en lo siguiente:
El núcleo del cliente asigna a cada solicitud un número secuencial.
El núcleo del servidor mantiene un registro del número secuencial de recepción
más reciente de cada uno de los núcleos de clientes que lo utilicen.
El núcleo del servidor podrá indicar la diferencia entre una solicitud original y una
retransmisión y puede rechazar la realización de cualquier solicitud por segunda
vez.
Una protección adicional es tener un bit en el encabezado del mensaje para distinguir las
solicitudes de las retransmisiones.
(4) El servidor falla después de recibir una petición
Un fallo del servidor también se relaciona con la idempotencia pero no se puede resolver con
números secuenciales
El problema es que el núcleo del cliente no puede decidir si se ha presentado la segunda o
la tercera situación.
Las posibles soluciones son las siguientes:
Semántica al menos una:
o Esperar hasta que el servidor vuelva a arrancar (o se reconecte a un nuevo
servidor) e intente realizar de nuevo la operación.
o Mantener el intento hasta recibir una respuesta para dársela al cliente.
o Garantiza que la RPC se ha realizado al menos una vez, pero es posible que
se realice más veces.
23. Semántica a lo más una:
o No se reintenta y se informa del fallo.
o Garantiza que la RPC se realiza a lo más una vez, pero es posible que no se
realice ni una sola vez.
Semántica de no garantizar nada:
o Cuando un servidor falla, el cliente no obtiene ayuda o alguna promesa.
o La RPC se puede realizar en cualquier lugar, un número de veces que va
desde “0” hasta “n”.
o Resulta fácil de implantar.
Semántica de exactamente una:
o Es la solución deseable pero generalmente no existe forma de garantizar
esto.
o El procedimiento de recuperación depende totalmente del momento en
que ocurre el fallo.
o El cliente no tiene forma de descubrir ese instante.
La posibilidad de fallos del servidor distingue de manera clara los sistemas con un único
procesador de los sistemas distribuidos:
Con un único procesador el fallo de un servidor implica un fallo del cliente y la
recuperación no es ni posible ni necesaria.
Con sistemas distribuidos es posible y necesario realizar cierta acción.
(5) El cliente falla después de enviar una petición
La cuestión es qué ocurre si un cliente envía una solicitud a un servidor y falla antes de que
el servidor responda.
Se genera una solicitud de trabajo o cómputo que al fallar el cliente ya nadie espera; se
dice que se tiene un cómputo huérfano.
Los principales problemas generados por cómputos huérfanos son los siguientes:
Desperdicio de ciclos de cpu.
Posible bloqueo de archivos.
Apropiación de recursos valiosos.
24. Posible confusión cuando:
o El cliente rearranca y efectúa de nuevo la RPC.
o La respuesta del huérfano regresa inmediatamente luego.
Las soluciones a los cómputos huerfanos son las siguientes:
Exterminación:
o Se crea un registro que indica lo que va a hacer el resguardo del cliente
antes de que emita la RPC.
o El registro se mantiene en disco.
o Luego del rearranque se verifica el contenido del registro y se elimina el
huérfano explícitamente.
o La desventaja es la sobrecarga en e / s generada por la grabación previa a
cada RPC.
o Fallaría si los huérfanos generan RPC, creando huérfanos de huérfanos:
Sería imposible localizarlos.
Ante ciertos fallos en la red sería imposible eliminarlos aunque se
los localice.
Reencarnación:
o Resuelve los problemas anteriores sin necesidad de escribir registros en
disco.
o Consiste en dividir el tiempo en épocas numeradas de manera secuencial.
o Cuando un cliente rearranca envía un mensaje a todas las máquinas
declarando el inicio de una nueva época.
o Al recibirse estos mensajes se eliminan todos los cómputos remotos.
o Si se divide la red mediante particiones por fallas, podrían sobrevivir ciertos
huérfanos:
Cuando se reconecten y vuelvan a reportarse sus respuestas
contendrán un número de época obsoleto y se los podrá detectar y
eliminar.
25. Reencarnación sutil:
o Cuando llega un mensaje de cierta época:
Cada máquina verifica si tiene cómputos remotos:
En caso afirmativo intenta localizar a su poseedor.
Si no se localiza al poseedor se elimina el cómputo.
Expiración:
o A cada RPC se le asigna una cantidad estándar de tiempo “t” para que
realice su trabajo.
o Si el tiempo es insuficiente debe pedir explícitamente otro quantum, pero
esto es un inconveniente.
o Si luego del fallo el servidor espera “t” antes de rearrancar, todos los
huérfanos habrán desaparecido.
o El problema es elegir un “t” razonable, ya que pueden existir RPC con
requisitos diversos.
26. Glosario
Asa (Handle): se conoce como handle a un tipo particular de punteros
"inteligentes". Los handles son utilizados cuando un programa hace referencia a
bloques de memoria u objetos controlados por otros sistemas, tales como una
base de datos o un sistema operativo.
IIOP: (Internet Inter-Orb Protocol) es la implementación de GIOP para TCP/IP. Es
una realización concreta de las definiciones abstractas de GIOP.
Marshalling: empaquetado de argumentos
NFS (Network System File): es un protocolo de nivel de aplicación, según el
Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de
red de computadoras de área local. Posibilita que distintos sistemas conectados a
una misma red accedan a ficheros remotos como si se tratara de locales.
Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de
que sea independiente de la máquina, el sistema operativo y el protocolo de
transporte, esto fue posible gracias a que está implementado sobre los protocolos
XDR (presentación) y ONC RPC (sesión).
Sockets: Los sockets no son más que puntos o mecanismos de comunicación entre
procesos que permiten que un proceso hable (emita o reciba información) con
otro proceso incluso estando estos procesos en distintas máquinas. Esta
característica de interconectividad entre máquinas hace que el concepto de socket
nos sirva de gran utilidad.
UDDI: son las siglas del catálogo de negocios de Internet denominado Universal
Description, Discovery and Integration.
UDP: el protocolo de datagramas de usuario (UDP) es un protocolo que
intercambia datos sin acuse de recibo ni garantía de entrega. UDP se apoya en las
aplicaciones para manejar la retrasmisión y el procesamiento de errores.
Unmarshalling: desempaquetado de argumentos