Tema6 llamadas a procedimientos...

Tema 6

Llamadas a procedimientos remotos

F. García-Carballeira, Mª. Soledad Escolar,

Luis Miguel Sánchez, Fco. Javier García

Sistemas Distribuidos

Grado en Ingeniería Informática

Universidad Carlos III de Madrid

Contenidos

� Remote Procedure Call (RPC)

� Conceptos básicos

� Aspectos relacionados con las RPCs

� RPC de Sun Microsystems

� Biblioteca de funciones de RPC

F. García-Carballeira, Mª. Soledad Escolar, Luis Miguel Sánchez, Fco. Javier García

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España.

� Biblioteca de funciones de RPC

� Compilar un programa

� Ejemplo de RPC

� Invocación de métodos remotos

� RPC (Remote Procedure Call): llamadas a procedimientos remotos

� Por Birrel y Nelson (1985) en “Implementing Procedure Calls”

� Híbrido:� Llamadas a procedimientos en local

� Paso de mensajes

� Las RPC constituyen el núcleo de muchos SSDD

� Llegaron a su culminación con DCE (Distributed Computing Environment)

� Han evolucionado hacia orientación a objetos� Invocación de métodos remotos (CORBA, RMI)

� Las RPCs ofrecen una interfaz sencilla para construir aplicaciones distribuidas sobre TCP/IP

RMI and RPC

Aplicaciones/servicios

Sockets

Aplanamiento (marshalling), representación externa

de datos

Protocolo de transporte

UDP y TCP

RPCs en la pila de protocolos

� RPC:� En el nivel de sesión en OSI

� En el nivel de aplicación en TCP/IP

� Independientes del

� Independientes del protocolo de transporte� TCP

� UDP

� Fiabilidad no garantizada� Depende del protocolo de

transporte

RPC de Sun Microsystems

� La versión 2 de RPC, descrita en la RFC 1057, fue estandarizada por Sun Microsystems

� Se ocupa:� Especificación e interpretación de mensajes

� NO se ocupa:� Cómo se realiza el intercambio de mensajes entre los procesos

� Restricciones de la capa de transporte utilizado

Binding entre un cliente a un servicio

� Binding entre un cliente a un servicio

� La sintaxis y el formato de los mensajes se define mediante IDL (Interface Definition Language):� Lenguaje de especificación de RPC

� Lenguaje de especificación de datos XDR

Comunicación cliente-servidor

� Protocolo petición-respuesta

Mensaje de peticiónSolicitar operación Recibir petición

Seleccionar servicio

ServidorCliente

(esperar)

(continúa)

Mensaje de respuestaEjecutar servicio

Seleccionar servicio

Enviar respuesta

Estructura de los mensajes

petición-respuesta

Id. De petición

Id. De operación

argumentos

Resultado

Funcionamiento de las RPC

� El proceso que realiza la llamada empaqueta los argumentos en un mensaje, se los envía a otro proceso y espera el resultado

� El proceso que ejecuta el procedimiento extrae los argumentos del mensaje, realiza la llamada de forma local, obtiene el resultado y se lo envía de vuelta al proceso que realizó la llamada

� Objetivo: acercar la semántica de las llamadas a procedimiento convencional a un entorno distribuido (transparencia)

main(){...r = sumar (4, 5);...

sumar(int a, int b)int r;r = a + b;return r;

…send(a, b);receive(r);…

receive(4,5)…send (r)

Llamada local

main(){...r = sumar (4, 5);...

sumar(int a, int b)int r;r = a + b;

Pila del proceso

r = a + b;return r;

Registro de activación

Dir retorno

Llamada a procedimiento remoto

main(){...r = sumar (4, 5);...

Dir retorno

Cliente

servidor

Stub sumar(int a, int b)send(a, b);receive(r);

main(){receive (4, 5)...r = sumar (4, 5);send (r)

sumar(int a, int b)int r;r = a + b;return r;

servidorreceive(r);return(r);

}peticion

respuesta

Conceptos básicos

� Una RPC tiene dos participantes:

� Un cliente activo, que envía una RPC al servidor

� Un servidor pasivo, que calcula un resultado y lo devuelve al cliente

� Un servicio de red es una colección de uno o más programas remotos

� Un programa remoto implementa uno o más procedimientos remotos

� Un servidor puede soportar más de una versión de un programa remoto

� Un servidor puede soportar más de una versión de un programa remoto� Permite al servidor ser compatible con las actualizaciones de protocolos

� Un procedimiento remoto, sus parámetros y sus resultados se especifican en un fichero de especificación del protocolo escrito en el lenguaje de especificación de RPC y XDR

Suplentes (stubs)

� Se generan automáticamente por el software de RPC� Stub del cliente

� Stub del sevidor

� Un stub es una pieza de código usada en el cliente y el servidor

� Responsable de convertir los parámetros de la aplicación cliente/servidor durante una llamada a procedimiento remoto

Cliente

ServidorStub

durante una llamada a procedimiento remoto� Espacio de direcciones independiente del cliente y servidor

� Representaciones de datos diferentes (big-endian, little-endian)

� Los suplentes son independientes de la implementación que se haga del cliente y del servidor. � Sólo dependen de la interfaz

Suplentes (stubs)

� Funciones en el cliente:� Suplantar al procedimiento a ejecutar

� Localizar al servidor

� Empaquetar los parámetros y construir los mensajes

� Enviar el mensaje al servidor

Esperar la recepción del mensaje y devolver los resultados

Cliente

ServidorStub

� Esperar la recepción del mensaje y devolver los resultados

� Funciones en el servidor:� Realizan tareas similares

RPC: protocolo básico

cliente servidorSe registra en un servicio de nombres

Recibir la petición

localizar al servidor

prepararparámetros, enviar petición

Desempaquetar la respuesta

Ejecutar elprocedimiento

Preparar la respuestay enviar

enviar petición

Máquina servidoraMáquina cliente

Protocolo

Proceso cliente (llamador)

Proceso servidor (llamado)

Protocolo petición-respuesta

Stub Stub

Proceso cliente (llamador)� Conectar al servidor

� Invocar una llamada a procedimiento remoto

Stub o resguardo del cliente:

Máquina cliente

Proceso cliente (llamador)

� Localizar al servidor

� Empaquetar los parámetros y construir los mensajes

� Enviar los mensajes al servidor

� Bloquearse hasta esperar la respuesta

� Obtener la respuesta

Máquina servidora

� Registrar las RPCs

� Implementar los procedimientos

Stub o resguardo del servidor:� Recibir la petición del cliente

� Recibir la petición del cliente

� Desempaquetar los parámetros

� Invocar el procedimiento de manera local

� Obtener la respuesta y enviarla al cliente

Modelos de RPCs

� RPCs síncronas

� RPCs asíncronas

RPC asíncronas

� El cliente no espera la respuesta

� No admite parámetros de salida

� Ejemplo en CORBA:� Se corresponden con métodos especificados como oneway

cliente servidor

cliente servidorlocalizar al servidorprepararparámetros, enviar petición

Se registra en un servicio de nombres

Ejecutar elprocedimiento

Aspectos relacionados con las RPC

� Lenguaje de definición de interfaces (IDL)

� Generador de stubs

� Tipos de parámetros

� Transferencia de parámetros

� Protocolo de comunicación

� Enlace entre el cliente y el servidor (binding)

� Semántica de las RPC en presencia de fallos

� Autenticación

� Un Lenguaje de Definición de Interfaz (IDL) permite especificar el formato de los procedimientos remotos y otras opciones de comunicación

� La interfaz es compartida por

� Cliente

� Servidor

Cliente

ServidorStub

Lenguaje de Definición de Interfaces

<opciones de comunicación:versión interfaz, tcp/udp, …

><interfaz remota:suma (in int a, in int b, out int c) ;

>generador

� Una interfaz especifica:� Nombre de servicio que utilizan los clientes y servidores

� Nombres de procedimientos

� Parámetros de los procedimientos� Entrada

� Salida

� Tipos de datos de los argumentos

Lenguaje de Definición de Interfaces

� Tipos de datos de los argumentos

� Los compiladores pueden diseñarse para que los clientes y servidores se escriban en lenguajes diferentes

� Tipos de IDL� Integrado con un lenguaje de programación (Cedar, Argus)

� Lenguaje de definición de interfaces específico para describir las interfaces entre los clientes y los servidores (RPC de Sun y RPC de DCE)

Tipos de parámetros

� Parámetro de entrada (in)� El parámetro se envía del cliente al servidor

� Parámetro de salida (out)� El parámetro se envía del servidor al cliente

� Parámetro de entrada/salida (inout)

Parámetro de entrada/salida (inout)

Transferencia de parámetros

� Una de las funciones de los suplentes es empaquetar los parámetros en un mensaje: aplanamiento (marshalling)

� Problemas en la representación de los datos:� Servidor y cliente pueden ejecutar en máquinas con arquitecturas

distintas (ordenamiento de bytes)� Problemas con los punteros

� Una dirección sólo tiene sentido en un espacio de direcciones

� Ejemplos de esquemas de representación de datos:� XDR (eXternal Data Representation) es un estándar que define la

representación de tipos de datos (RFC 1832)� Representación común de datos de CORBA (CDR)� Serialización de objetos de Java� XML (eXtensible Markup Language ) es un metalenguaje basado en

etiquetas definida por W3C

Ejemplo de representación de datos

� Mensaje: ‘Smith’, ‘London’, 1934

8–11

12–15

"Smit""h___"

index in sequenceof bytes 4 bytes

length of string

‘Smith’

length of string

XDR CDR

16–19

24–27

"Lond"

"on__"

‘London’

unsigned long

<name>Smith</name>

<place>London</place>

</person>

Protocolo

� Entre cliente y servidor debe establecerse un protocolo:� Formato de los mensajes

� Formato de representación

Enlace (Binding)

� Enlace: asociación entre el cliente y el servidor� Implica localizar al servidor que ofrece un determinado

servicio� El servidor debe registrar su dirección en un servicio de

nombres (binder)

Enlazador dinámico

� Enlazador dinámico (binder): es el servicio que mantiene una tabla de traducciones entre nombres de servicio y direcciones.

� Incluye funciones para:� Registrar un nombre de servicio

� Eliminar un nombre de servicio

Eliminar un nombre de servicio� Buscar la dirección correspondiente a un nombre de servicio

� Cómo localizar al enlazador dinámico:1. Ejecuta en una dirección fija de un computador fijo2. El sistema operativo se encarga de indicar su dirección

3. Difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecución.

Esquema de registro y enlace

cliente servidor

1 Obtiene dirección

binder

2 Registra dirección

3 Busca servidor

4 Devuelve dirección

5 Petición

6 Respuesta

7 Borra dirección (fin del servicio)

Tipos de enlace

� Enlace no persistente: el binding entre el cliente y el servidor se establece en cada RPC� Más tolerante a fallos� Permite migración de servicios

� Enlace persistente: el binding se mantiene después de la

� Enlace persistente: el binding se mantiene después de la primera RPC� Útil en aplicaciones con muchas RPC repetidas� Problemas si lo servidores cambian de lugar

� Modelos híbridos

Fallos que pueden aparecer con las RPC

� El cliente no es capaz de localizar al servidor

� Pérdidas de mensajes� Se pierde el mensaje de petición del cliente al servidor

� Se pierde el mensaje de respuesta del servidor al cliente

� El servidor falla después de recibir una petición

El servidor falla después de recibir una petición

� El cliente falla después de enviar una petición

Cliente no puede localizar al servidor

� Posibles causas:� El servidor puede estar caído

� El cliente puede estar usando una versión antigua del servidor� La versión ayuda a detectar accesos a copias obsoletas

Cómo indicar el error al cliente

� Cómo indicar el error al cliente� Devolviendo un código de error (-1)

� No es transparente � Ejemplo: sumar(a,b)

� Elevando una excepción� Necesita un lenguaje que tenga excepciones

Pérdida de mensajes del cliente

� Es la más fácil de tratar

� Se activa una alarma (timeout) después de enviar el mensaje

� Si pasado el timeout no se recibe una respuesta se retransmite el mensaje

Pérdidas en los mensajes de respuesta� Más difícil de tratar� Se pueden emplear alarmas y retransmisiones, pero:

� ¿Se perdió la petición?� ¿Se perdió la respuesta?� ¿El servidor va lento?

� Algunas operaciones pueden repetirse y devolverán el mismo resultado (operaciones idempotentes)

(operaciones idempotentes)� Una transferencia bancaria no es idempotente� La suma de dos números es idempotente

� La solución con operaciones no idempotentes es descartar peticiones ya ejecutadas � Un número de secuencia en el cliente� Un campo en el mensaje que indique si es una petición original o una

retransmisión

Fallos en los servidores

� El servidor no ha llegado a ejecutar la operación� Se podría retransmitir

� El servidor ha llegado a ejecutar la operación� El cliente no puede distinguir los dos� ¿Qué hacer?

� No garantizar nada

� No garantizar nada� Semántica al menos una vez

� Reintentar y garantizar que la RPC se realiza al menos una vez� No vale para operaciones no idempotentes

� Semántica a lo más una vez

� No reintentar, puede que no se realice ni una sola vez

� Semántica de exactamente una

� Sería lo deseable

Fallos en los clientes

� La computación está activa pero ningún cliente espera los resultados (computación huérfana)� Gasto de ciclos de CPU

� Si el cliente rearranca y ejecuta de nuevo la RPC se pueden crear confusiones

Estrategias ante fallos

� Cliente RPC:� Cuando no se recibe la respuesta

� Reenviar la petición

� Incluir identificador de petición (número de secuencia)

� Servidor RPC:

� Servidor RPC:� Para hacer frente a peticiones duplicadas

� Filtrar las peticiones (números de secuencia, etc.)

� Si se necesita reenviar una respuesta de una petición no idempotente:� Guardar un histórico de las peticiones anteriormente ejecutadas y su

respuesta para no ejecutar de nuevo la petición.

Aspectos de implementación

� Protocolos RPC

� Orientados a conexión� Fiabilidad se resuelve a bajo nivel

� Peor rendimiento

� No orientados a conexión

� Uso de un protocolo estándar o uno específico

� Uso de un protocolo estándar o uno específico� Algunos utilizan TCP o UDP como protocolos básicos

Programación con un paquete de RPC

� El programador debe proporcionar:� La definición de la interfaz (IDL)

� Nombres de los procedimientos

� Parámetros que el cliente pasa al servidor

� Resultados que devuelve el servidor al cliente

� El código del cliente

� El código del servidor

� El compilador de IDL genera :� El resguardo (stub) del cliente

� El resguardo (stub) del servidor

Desarrollo de la aplicación con RPC

DESARROLLODE LA

INTERFAZ

COMPILADOR IDL

SUPLENTEEN SERVIDOR

SUPLENTEEN CLIENTE

CABECERA

FICHERODE DEFINICIÓNDE INTERFAZ

COMPILADOR C COMPILADOR C

COMPILADOR CCOMPILADOR C

CABECERA CABECERAFICHEROSFUENTE DEL

CLIENTE

FICHEROSOBJETO DEL

CLIENTE

FICHEROSOBJETO DEL

SERVIDOR

EJECUTABLEDEL

CLIENTE

EJECUTABLEDEL

SERVIDOR

FICHEROSFUENTE DELSERVIDOR

OBJETOSUPLENTEEN CLIENTE

OBJETOSUPLENTE

EN SERVIDOR

MONTADOR MONTADOR

BIBLIOT.RPC

DESARROLLODEL

CLIENTE

DESARROLLO

SERVIDOR

@Fuente: Jesús Carretero, Félix García, Pedro de Miguel y Fernando Pérez. Mc Graw Hill

RPC de SUN Microsystems

� Diseñado para el sistema de ficheros NFS

� Descrito en RFC 1831

� También se denomina ONC-RPC (Open network computing)

� Se puede elegir UDP oTCP� Cliente y servidor deben estar de acuerdo en el protocolo de transporte a

utilizar

Utiliza la semántica al menos una vez

� Utiliza la semántica al menos una vez

� Utiliza un lenguaje de definición de interfaces denominado XDR

� Soporte:� Para C a través del compilador rpcgen en UNIX/Linux

� Para Java � http://acplt.plt.rwth-aachen.de/ks/english/remotetea.html

� Para plataformas Windows

RPC de SUN y el modelo OSI

aplicación

7. Aplicación

6. Presentación

5. Sesión

TCP UDP

Interfaz HW

4. Transporte

3. Red

1-2 Enlace de datosY físico

Lenguaje XDR� XDR (eXternal Data Representation) es un estándar que define la representación de

tipos de datos (RFC 1832)� Utilizado inicialmente para representaciones externas de datos� Se extendió a lenguajes de definición de interfaces� Una interfaz contiene:

� Un número de programa � Un número de versión del programa� Un conjunto de procedimientos remotos:

Un conjunto de procedimientos remotos:� Un nombre y un número de procedimiento� Los procedimientos sólo aceptan un parámetro de entrada (se encapsulan en una

estructura)� Los parámetros de salida se devuelven mediante un único resultado

� El lenguaje ofrece una notación para definir:� constantes� definición de tipos� estructuras, uniones� programas

Formato de definición de interfaz program-def :

" program " identifier " { "

version-def

version-def *

" } " " =" constant " ; “ /* Number of program */

version-def :

" version " identifier " { "

procedure-def

procedure-def *

" } " " =" constant " ; " /* Number of version */

procedure-def :

type-specifier identifier " ( " type-specifier

(" , " type-specifier )* " ) "

" =" constant ";“ /* Number of procedure */

Ejemplo:

especificación del programa ping/* Simple ping program */

program PING_PROG{

/* Latest and greatest version */

version PING_VERS_PINGBACK{

PINGPROC_NULL(void) = 0;

* Ping the caller, return the round-trip time (in microseco nds).

Returns -1 if the operation timed out.

PINGPROC_PINGBACK(void) = 1;

} = 2;

/* Original version */

version PING_VERS_ORIG {

PINGPROC_NULL(void) = 0;

} = 1;

const PING_VERS = 2; /* latest version */

Identificación de llamadas a RPC

� Un mensaje de llamada de RPC se identifica unívocamente mediante tres campos enteros sin signo:

(NUM-PROG, NUM-VERSION, NUM-PROCEDURE)

NUM-PROG es el número de programa remoto,

NUM-VERSION es el número de versión de programa,

NUM-PROCEDURE es el número de procedimiento remoto

� Detalles de implementación:� NUM-PROG se definen en la RFC 1831

� http://www.ietf.org/rfc/rfc1831.txt

� La primera implementación (versión) de un protocolo deber ser la 1

� Los números de procedimientos se especifican por el programador

El proceso portmapper� El enlace en las RPC de sun se realiza mediante un proceso denominado

portmapper

� En cada servidor ejecuta un proceso portmapper en un puerto bien conocido (111)

� El portmapper almacena por cada servicio local:� El número de programa

� El número de versión

� El número de puerto

� Enlace dinámico:� El número de puertos disponibles es limitado y el número de programas remotos

potenciales puede ser muy grande

� Sólo el portmapper ejecutará en un puerto determinado (111) y los números de puertos donde escuchan los servidores se averiguan preguntando al portmapper

� Soporta TCP y UDP (ver /etc/services)� sunrpc 111/tcp portmapper #RPC 4.0

portmapper

� sunrpc 111/udp portmapper

El proceso portmapper

� Protocolo: � Cuando un servidor arranca registra en el portmapper la información

anterior� Cuando un cliente necesita invocar un procedimiento remoto envía al portmapper del host remoto (necesita conocer la dirección IP del servidor)� El número de programa y el número de versión

� El portmapper devuelve el puerto del servidor

rpcinfo –p guernika.lab.inf.uc3m.es

./servidor &

El proceso portmapper

rpcinfo –p guernika.lab.inf.uc3m.esprograma vers proto puerto

100000 2 tcp 111 portmapper100000 2 udp 111 portmapper…

100024 1 udp 32772 status100024 1 tcp 59338 status

99 1 udp 4693699 1 tcp 40427

Biblioteca de funciones de RPC

� La biblioteca de funciones de RPC � Sistemas Unix

� Servicios de RPC para construir aplicaciones � En el cliente

� Crear un manejador de cliente

Destruir un manejador de cliente

� Destruir un manejador de cliente

� En el servidor

La biblioteca de funciones

� rpc.h es una biblioteca de funciones para desarrollar aplicaciones distribuidas que usan RPC:#include <rpc/rpc.h>

� Múltiples niveles de acceso:� Interfaz simplificado

� Interfaz simplificado

� Rutinas de nivel intermedio

� Rutinas de alto nivel

Servicios de RPC

� Crear un manejador para el cliente

CLIENT *clnt_create (const char * host, const u_long prognum,

const u_long versnum, const char *nettype)

Argumentos:

� host nombre del host remoto donde se localiza el programa remoto

� prognum Número de programa del programa remoto� versnum Número de versión del programa remoto� nettype Protocolo de transporte:

NETPATH, VISIBLE, CIRCUIT_V, DATAGRAM_V, CIRCUIT_N, DATAGRAM_N, TCP, UDP

Servicios de RPC

� Destruir el manejador del cliente

void clnt_destroy (CLIENT *clnt)

Argumentos:� clnt Manejador de RPC del cliente

Servicios de RPC

� Indicar el error en un fallo de RPC:

void clnt_perror (CLIENT *clnt, char *s)void clnt_pcreateerror (CLIENT *clnt, char *s)

Argumentos:

� clnt Manejador de RPC del cliente� S Mensaje de error

Ejemplo: crear/destruir un manejador#include <stdio.h>

#include <rpc/rpc.h>

#define RMTPROGNUM(u_long)0x3fffffffL /* Define remote program number and version */

#define RMTPROGVER(u_long)0x1

main()

CLIENT *client ; /* client handle */

/* Crear el manejador del cliente */

client = clnt_create (“as400.somewhere.ibm.com”, RMTPROGNUM, RMTPROGVER, “TCP”);

if (client == NULL){

clnt_pcreateerror (client, “Could not create client\n”);

exit(1);

// Invocar procedimiento remoto

/* Destruir el manejador del cliente */

clnt_destroy (client);

exit(0);

Invocar un procedimiento (cliente)

� Un procedimiento remoto se invoca:tipo_resultado procedimiento _v (tipo_arg1 arg1,

tipo_arg2 arg2,

tipo_argn argn,

CLIENT *clnt)

donde:

donde:� procedimiento_v Nombre del procedimiento a invocar� arg1,arg2,…,argn Argumentos del procedimiento� clnt Manejador de un cliente de RPC

NOTA: v se sustituye por el número de versión que se invoca

Implementar un procedimiento

(servidor)

� Para cada procedimiento remoto, el servidor ofrece una implementación de procedimiento respetando su prototipo:tipo_resultado

procedimiento_v _svc (tipo_arg1 arg1,

tipo_arg2 arg2,

tipo_argn argn ,

struct svc_req *rqstp)

donde:� procedimiento_v_svc Nombre del procedimiento a implementar� arg1,arg2,…,argn Argumentos del procedimiento� rqstp Estructura que contiene información de la

peticiónNOTA: v se sustituye por el número de versión que se implementa

Compilador de interfaces (rpcgen)

� rpcgen es el compilador de interfaces que genera código C para:� Stub del cliente

� Stub del servidor y procedimiento principal del servidor

� Procedimientos para el empaquetado y desempaquetado XDR

Fichero de cabecera (.h) con los tipos y declaración de

� Fichero de cabecera (.h) con los tipos y declaración de prototipos de procedimientos

Sintaxis de rpcgen

� Compilar usando rpcgenrpcgen infile

rpcgen [-abkCLNTM][-Dname[=value]] [-i size] [-I [-K seconds]] [-Y path] infile

rpcgen [-c | -h | -l | -m | -t | -Sc | -Ss | -Sm] [-o outfile] [infile]rpcgen [-s nettype]* [-o outfile] [infile]rpcgen [-n netid]* [-o outfile] [infile]

infile fichero en lenguaje de definición de interfaz de RPC

� infile fichero en lenguaje de definición de interfaz de RPC (XDR en RPC de SUN)

� Algunas opciones:� -N Permite a los procedimientos tener múltiples argumentos� -a Genera todos los ficheros incluyendo código de ejemplo para

cliente y servidor� -M Genera stubs multi-thread para paso de argumentos

Ejemplo: aplicación con RPC

clientesumar(5,2)

servidor

Máquina A Máquina B

NÚCLEO Resultado = 7 NÚCLEO

@Fuente: Jesús Carretero, Félix García, Pedro de Miguel y Fernando Pérez. Mc Graw Hill

Esquema de la aplicación

rpcgensuma_xdr.c

suma_clnt.c

cliente.cArchivos para

el cliente

Archivos

suma.xrpcgen

suma_svc.c

servidor.c

suma.h

Archivoscomunes

Archivos parael servidor

Ficheros generados por el programador

Ficheros generados mediante rpcgen suma.x

struct argumentos {

int a;

int b;

program SUMAR{

version SUMAVER{

Ejemplo: suma.x

version SUMAVER{

int SUMA(argumentos) = 1;

int RESTA(argumentos) = 2;

} = 1;

} = 99;

Ejemplo: suma.h#ifndef _SUMA_H_RPCGEN

#define _SUMA_H_RPCGEN

struct argumentos {

int a;

int b;

#define SUMAVER ((u_long)99)

#define SUMA ((u_long)1)

#define RESTA ((u_long)2)

extern int * suma_1(argumentos *, CLIENT *);

extern int * suma_1_svc (argumentos *, struct svc_req *);

#endif /* !_SUMA_H_RPCGEN */

Ejemplo: servidor.c#include "suma.h"

int * suma_1_svc (argumentos *argp, struct svc_req *rqstp)

// TODO: implementación del procedimiento suma_1_sv c

static int result;

result = argp->a + argp->b;

return(&result);

int * resta_1_svc (argumentos *argp, struct svc_req *rqstp)

// TODO: implementación del procedimiento resta_1_s vc

static int result;

result = argp->a - argp->b;

return(&result);

Ejemplo: cliente.c#include "suma.h"

main( int argc, char* argv[] )

CLIENT *clnt ;

int *res;

argumentos suma_1_arg;

char *host;

if(argc < 2) {

printf("usage: %s server_host\n", argv[0]);

exit(1);

host = argv[1];

Ejemplo: cliente.c (II)/* Paso 1: localizar al servidor */clnt = clnt_create (host, SUMAR, SUMAVER, "udp");if (clnt == NULL) {

clnt_pcreateerror (host);exit(1);

suma_1_arg.a = 5;suma_1_arg.b = 2;

Binding:Se contacta con el portmapper de hostSe indica el host:API:versión:protocoloEl portmapper indica la localización (puerto)

/* Paso 2: Invocar el procedimiento remoto */res = suma_1(&suma_1_arg, clnt);if (res == NULL) {

clnt_perror (clnt, "call failed:");}printf("La suma es %d\n", *res);

/* Destruir el manejador */clnt_destroy ( clnt );

suma_xdr.c#include "suma.h"

bool_t

xdr_argumentos (XDR *xdrs, argumentos *objp)

register int32_t *buf;

if (! xdr_int (xdrs, &objp->a))

return FALSE;

if (! xdr_int (xdrs, &objp->b))

return FALSE;

return TRUE;

suma_clnt.c (stub del cliente)#include <memory.h> /* for memset */

#include "suma.h"

/* Default timeout can be changed using clnt_contro l() */

static struct timeval TIMEOUT = { 25, 0 };

int * suma_1(argumentos *argp, CLIENT *clnt)

static int clnt_res;

Cliente

Servidor

memset((char *)&clnt_res, 0, sizeof(clnt_res));

if ( clnt_call (clnt, suma,

(xdrproc_t) xdr_argumentos, (caddr_t) argp,

(xdrproc_t) xdr_int, (caddr_t) &clnt_res,TIMEOUT) ! = RPC_SUCCESS)

return (NULL);

return (&clnt_res);

int * resta_1 (argumentos *argp, CLIENT *clnt)...

suma_svc.c

(stub del servidor)int main (int argc, char **argv)

register SVCXPRT *transp;

pmap_unset (SUMAR, SUMAVER);

transp = svcudp_create (RPC_ANYSOCK);

svc_register (transp, SUMAR, SUMAVER, sumar_1, IPPROTO_UDP;

transp = svctcp_create (RPC_ANYSOCK, 0, 0);

Cliente

ServidorStub

transp = svctcp_create (RPC_ANYSOCK, 0, 0);

svc_register (transp, SUMAR, SUMAVER, sumar_1, IPPROTO_TCP;

svc_run ();

fprintf (stderr, "%s", "svc_run returned");

exit (1);

/* NOTREACHED */

suma_svc.c (II)

(stub del servidor)static void sumar_1(struct svc_req *rqstp, register SVCXPRT *transp)

union {

argumentos resta_1_arg;

} argument;

char *result;

xdrproc_t _xdr_argument, _xdr_result;

char *(*local)(char *, struct svc_req *);

Cliente

ServidorStub

char *(*local)(char *, struct svc_req *);

switch (rqstp->rq_proc) {

case NULLPROC:

(void) svc_sendreply (transp, (xdrproc_t) xdr_void, (char *)NULL);

return;

case suma:

_xdr_argument = (xdrproc_t) xdr_argumentos;

_xdr_result = (xdrproc_t) xdr_int;

local = (char *(*)(char *, struct svc_req *)) suma_1_svc ;

break;

suma_svc.c (III)

(stub del servidor)case resta:

_xdr_argument = (xdrproc_t) xdr_argumentos;

_xdr_result = (xdrproc_t) xdr_int;

local = (char *(*)(char *, struct svc_req *)) resta_1_svc ;

break;

default:

svcerr_noproc (transp); return;

memset ((char *)&argument, 0, sizeof (argument));

svc_getargs ( transp , _ xdr_argument , ( caddr_t ) &argument );

Cliente

ServidorStub

svc_getargs ( transp , _ xdr_argument , ( caddr_t ) &argument );

result = (*local)((char *)&argument, rqstp);

if (result != NULL &&

!svc_sendreply(transp, _xdr_result, result)){

svcerr_systemerr (transp);

if (!svc_freeargs (transp, _xdr_argument, (caddr_t) &argument)) {

fprintf (stderr, "%s", "unable to free arguments");

exit (1);

return;

Compilación

� gcc –c suma_xdr.c

� gcc –c suma_svc.c

� gcc –c suma_clnt.c

� gcc –c cliente.c

� gcc –c servidor.c

� gcc suma_xdr.o suma_clnt.o cliente.o –o cliente

� gcc suma_xdr.o suma_svc.o servidor.o –o servidor

Compilación

� rpcgen –a –N –M suma.x

� Opciones:� -a: genera todos los ficheros incluyendo ejemplos

� -N: permite varios argumentos

� -M: genera código multithread (código que puede ser utilizado en aplicaciones con varios threads)

en aplicaciones con varios threads)

suma.x:

Ejemplo usando nuevas opciones

program SUMAR {

version SUMAVER {

int suma(int a, int b) = 1;

int resta(int a, int b) = 2;

} = 1;

} = 99;

Nota:La opción de compilación –N permite que un procedimiento acepte más de un argumento de entrada

Ficheros que se generan

� suma.h: incluye prototipos de funciones

� suma_client.c: ejemplo de cliente.

� suma_clnt.c: stub del cliente

� suma_server.c: plantilla con las funciones a implementar en el servidor

en el servidor

� suma_svc.c: stub del servidor

� suma_xdr.c: funciones XDR

suma.h#include <rpc/rpc.h>

#include <pthread.h>

struct suma_1_argument {

int a;

int b;

typedef struct suma_1_argument suma_1_argument;

struct resta_1_argument {

int a;

int b;

typedef struct resta_1_argument resta_1_argument;

suma.h (2)#define SUMAR 99

#define SUMAVER 1

extern enum clnt_stat suma_1(int , int , int *, CLIENT *);

extern bool_t suma_1_svc (int , int , int *, struct svc_req *);

svc_req *);

extern enum clnt_stat resta_1 (int , int , int *, CLIENT *);

extern bool_t resta_1_svc (int , int , int *, struct svc_req *);

suma_client.c:

Ejemplo de cliente

#include "suma.h"

void sumar_1(char *host){

CLIENT *clnt ;enum clnt_stat retval_1;int result_1; int suma_1_a; int suma_1_b;enum clnt_stat retval_2;

enum clnt_stat retval_2;int result_2; int resta_1_a; int resta_1_b;

clnt = clnt_create (host, SUMAR, SUMAVER, “tcp");if (clnt == NULL) {

clnt_pcreateerror (host);exit (1);

retval_1 = suma_1(suma_1_a, suma_1_b, &result_1, clnt);

if (retval_1 != RPC_SUCCESS) {

clnt_perror (clnt, "call failed");

retval_2 = resta_1 (resta_1_a, resta_1_b,&result_2, clnt);

suma_client.c:

Ejemplo de cliente (2)

clnt_perror (clnt, "call failed");

clnt_destroy (clnt);

suma_server:

Plantilla de servidor#include "suma.h"

bool_t suma_1_svc (int a, int b, int *result,

bool_t retval;

* insert server code here

*result = a + b;

retval = TRUE;

return retval;

suma_server:

Plantilla de servidor (2)bool_t resta_1_svc (int a, int b, int *result,

bool_t retval;

* insert server code here

*result = a + b;

retval = TRUE;

return retval;

Autenticación

� Los mensajes de petición y respuesta disponen de campos para pasar información de autenticación

� El servidor es el encargado de controlar el acceso

� Hay distintos tipos de protocolos de autenticación:� Ninguno

� Al estilo UNIX, basado en uid y gid

� Autenticación Kerberos

� Mediante una clave compartida que se utiliza para firmar los mensajes RPC

Sintaxis de definición de un protocolo

definition-list:definition;definition; definition-list

definition:

const-definitionenum-definitionstruct-definicionunion-definitiontypedef-definition

program-definition

Definición de constantes simbólicas

� En XDRconst MAX_SIZE = 8192;

� Traducción a C:#define MAX_SIZE 8192

Tipos enumerados

� En XDR:enum color{

ROJO = 0;VERDE = 1;AZUL = 2;

� Traducción a C:

� Traducción a C:enum color{

ROJO = 0;VERDE = 1;AZUL = 2

};typedef enum color color;bool_t xdr_color();

Estructuras

� En XDR:struct punto{

int x;

int y;

� Traducción a C:struct punto{

int x;

int y;

typdef struct punto punto;

bool_t xdr_punto();

Uniones� En XDR:

union resultado switch (int error){

case 0:

int n;

default:

� Traducción a C:struct resultado {

int error;

union {

int n;

} resultado_u;

typdef struct resultado resultado;

bool_t xdr_resultado();

Definición de tipos

� En XDR:typedef punto puntos[2];

� Traducción a C:� Pasan sin modificación

� Pasan sin modificacióntypedef punto puntos[2];

Definición de programasprograma-def: "program" identifier "{"

version-defversion-def *

"}" "=" contant ";"

version - def :program SUMAR {

"version" identifier "{"procedude-defprocedure-def *

"}" "=" constant ";“

procedure-def:type-ident procedure-ident "("type-ident")" "="value

program SUMAR {

version SUMAVER {

int suma(int a, int b) = 1;

} = 1;

} = 99;

Tipos de datos básicos

� Los tipos de datos básicos de C

� Ejemplos:

Enteros con signo:

Declaración: int a;

Equivalente en C: int a;

Equivalente en C:

Enteros sin signo:

Declaración: unsigned a;

Equivalente en C: unsigned a;

Números en coma flotante:

Declaración: float a;

Equivalente en C: float c;

Principales tipos de datos en XDRNúmeros en coma flotante:

Declaración: float a;Equivalente en C: float c;

Cadenas de bytes de longitud fija:Declaración: opaque a[20];Equivalente en C: char a[20];

Cadenas de bytes de longitud variable:Declaración: opaque a<37>;

opaque b<>;Equivalente en C: struct {

int a_len;char *a_val;

Principales tipos de datos en XDR

Cadenas de caracteres:

Declaración: string a<37>;

string b<>;

Equivalente en C: char *a;

char *b;

Vectores de tamaño fijo:

Declaración: int a[12];

Equivalente en C: int a[12];

Principales tipos de datos en XDR

Vectores de tamaño variable:Declaración: int a<12>;

float b<>;

Equivalente en C: struct {int a_len ;

int a_len ;int *a_val;

} a;struct {

int b_len;float *b_val;

Principales tipos de datos en XDREstructuras:

Declaración: struct t {int c1;string c2<20>;

};t a;

Equivalente en C: struct t {

Equivalente en C:int c1;string *c2;

};typedef struct t t;t a;

Constantes:

Declaración: const MAX = 12;Equivalente en C: #define MAX 12

Mensajes de petición-respuesta

� Mensaje petición-respuesta

struct rpc_msg {

unsigned int xid;

union switch (msg_type mtype) {

Id. de transacción

union switch (msg_type mtype) {

case CALL:

call_body cbody;

case REPLY:

reply_body rbody;

} body;

enum msg_type {

CALL = 0,

REPLY = 1

Formato de los mensajes

MsgType = CALL

RPCVersion = 2

Programa

Versión

MsgType = REPLY

Status = ACCEPTED

Versión

Procedimiento

Credenciales (variable)

Verfificador (variable)

Evolución de las RPC

Paradigmas de

procedimientos/métodos remotos

Espacio de objetos, aplicaciones colaborativas

Servicios de red, object request broker, agentes móviles

procedimientos remotos, métodos remotos

Cliente-servidor, peer-to-peer

Paso de mensajes

� Objetivo: hacer que el software distribuido se programe igual que una aplicación no distribuida

� Mediante el modelo RPC la comunicación se realiza conceptualmente igual que la invocación de un procedimiento local

procedimiento local

proc1(arg1, arg2)

proc2(arg1)

proc3(arg1,arg2,arg3)

Proceso A proceso B

� Pasos:� A llama al procedimiento remoto de B

� La llamada dispara una acción de un procedimiento de B

� Al finalizar el procedimiento, B devuelve el valor a A

� Simplifica la comunicación entre procesos y la sincronización de eventos.

la sincronización de eventos.

� Ejemplos: � Open Network Computing Remote Procedure Call, desarrollada a partir del API

RPC de Sun Microsystems a comienzo de los años 80

� Distributed Computing Environment (DCE) RPC de Open Group

� Simple objeto Access Protocol (SOAP)

Llamada a métodos remotos

� Primera aproximación al uso de un modelo orientado a objetos sobre aplicaciones distribuidas

� Objetos distribuidos dentro de una red� Los objetos proporcionan métodos, los cuales dan acceso a los servicios

los cuales dan acceso a los servicios

� Ejemplo:� Remote method invocation (RMI) de Java

Remote method invocation (RMI)

� Modelo equivalente a las llamadas a procedimientos remotos

� Proceso invoca un método local de otro proceso� Se envían tanto los argumentos del método como el valor devuelto por el mismo

método1método2

Proceso 1Proceso 2

Objeto remoto

Entornos donde se usa Java RMI

Modelo de objetos en sistemas distribuidos

Máquina A Máquina B Máquina C

� El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes java.rmi y java.rmi.server.

� RMI ofrece:

� Mecanismos para crear servidores y objetos cuyos métodos se puedan invocar remotamente.

Java RMI (Remote Method Invocation)

invocar remotamente.

� Mecanismos que permiten a los clientes localizar los objetos remotos.

� Servicio de directorios:

� rmiregistry, servicio de directorios de Java

� Se ejecuta en la máquina servidor objeto

Comparación RMI y sockets

� Ventajas:� Los programas RMI son más sencillos de diseñar

� Servidor RMI concurrente

� Inconvenientes:� Sockets tienen menos sobrecarga� RMI sólo para plataformas Java

Arquitectura de RMI

Cliente de

objetos

Servidorde objetos

Servicio de directorios

Referencia remota

Transporte

skeleton

Referencia remota

Transporte

Ruta de datos lógica

Ruta de datos física

Arquitectura de RMI

� Nivel de resguardo o stub� Se encarga del aplanamiento de los parámetros.

� Stub: resguardo local. Cuando un cliente realiza una invocación remota, en realidad hace una invocación de un método del resguardo local.

� Nivel de gestión de referencias remotas

Referencia remota

Transporte

skeleton

Referencia remota

Transporte

Cliente deobjetos

Servidor

de objetos

Servicio de directorios

� Nivel de gestión de referencias remotas

� Interpreta y gestiona las referencias a objetos remotos.

� Invoca operaciones de la capa de transporte.

� Nivel de transporte� Se encarga de las comunicaciones y

de establecer las conexiones necesarias.

� Basada en protocolo TCP.

Arquitectura de RMI

skeleton

marshalEnvío petición

unmarshalInvoca método

MétodoRemoto

tiempo

Invoca métodoEjecución del códigoDevuelve valor

Recibe el valor retornomarshalEnvía la respuesta

unmarshallDevuelve el valor retorno

Diseño de aplicaciones RMI

(.java)

4(.class)

Implementación de la interfaz remota

Definición de la interfaz remota

(.java)

usaCliente

EjectuarCliente

CLIENTE SERVIDOR

(.class)

Esqueleto(.class)

stub(.class)

Servidor(.class)

Arrancar RMIRegistry

Crear los objetos

Registrar los objetos

(.java)

4(.class)

(.java)

usaCliente

EjectuarCliente

CLIENTE SERVIDOR

(.class)

Esqueleto(.class)

stub(.class)

Servidor(.class)

Crear los objetos

� Interfaz remota:� Clase que sirve de plantilla para otras clases.

import java.rmi.*;

public interface SomeInterface extends Remote {

// Cabecera del primer método remoto

public String someMethod1( )

throws java.rmi.RemoteException;

// Cabecera del segundo método remoto

public int someMethod2( float parameter) throws java.rmi.RemoteException;

� Implementación de la interfaz remota� Realizado por el servidor

import java.rmi.*;import java.rmi.server.*;

public class SomeImpl extends UnicastRemoteObject

public class SomeImpl extends UnicastRemoteObjectimplements SomeInterface

{ public SomeImpl() throws RemoteException { super( ); }

public String someMethod1( ) throws RemoteException{ /* Código fuente */ }

public int someMethod2(float a) throws RemoteExcepti on{ /* Código fuente */ }

UnicastRemoteObjectSomeInterface

Method1Method2...

SomeImpl

Method2Method1

(.java)

4(.class)

(.java)

EjectuarCliente

CLIENTE SERVIDOR

(.class)

Crear los objetos

ClienteEsqueleto

(.class)stub

(.class)

Servidor(.class)

� Diseño por parte del servidor:� Implementación de la interfaz remota

� Generar el resguardo y el esqueleto

# rmic SomeImpl# ls SomeImp*.class

…………SomeImpl_skel.classSomeImpl_skel.classSomeImpl_skel.classSomeImpl_skel.classSomeImpl_stub.classSomeImpl_stub.classSomeImpl_stub.classSomeImpl_stub.class

nombre de la clase de la implementación de la interface remota

Invocación remota

Servidor de objetos

SomeInterface.class

Cliente de objetos

SomeInterface.class

SomeImpl.class

SomeServer.class

Skel.class

SomeClient.class

SomeInterface.class

Stub.class

(.java)

4(.class)

(.java)

EjectuarCliente

CLIENTE SERVIDOR

(.class)

Esqueleto(.class)

stub(.class)

Crear los objetos

rmic Servidor(.class)

Cliente

Plantilla de clase de servidor de objeto

import java.rmi.*;import java.rmi.server.*;

import java.rmi.registry.Registry;

import java.rmi.registry.LocateRegistry;

public class SomeServer {

public static void main(String args[]) {

SomeImpl exportedObj = new SomeImpl();

int portNum=1099;

startRegistry(portNum );

registryURL = "rmi://localhost:"+portNum+"/some";

Naming.rebind(registryURL, exportedObj);

System.out.println("Some Server ready.");

}catch (Exception ex) {

System.out.println(“Exception: “+ex);}

Plantilla de clase de servidor de objeto

private static void startRegistry(int RMIPortNum)throws RemoteException

{try {

Registry registry= LocateRegistry.getRegistry(RMIPo rtNum);registry.list( );

}catch ( RemoteException ex)

catch ( RemoteException ex) {

System.out.println("RMI registry cannot be located at port" + RMIPortNum);Registry registry= LocateRegistry.createRegistry(RM IPortNum);System.out.println("RMI registry created at port " + RMIPortNum);

Alternativa: activar el registro manualmente conrmiregistry <número de puerto>

Plantilla de clase de cliente de objeto

import java.rmi.*;

public class SomeClient{

try {int portNum=1099;String registryURL ="rmi://serverhost:" + portNum + "/some";

String registryURL ="rmi://serverhost:" + portNum + "/some"; SomeInterface h = (SomeInterface)Naming.lookup(regis tryURL);

String message = h.someMethod1();System.out.println(message);

} catch (Exception e) {

System.out.println("Exception in SomeClient: " + e) ;}

Invocación remota

rmiregistryRMI

Máquina 1Máquina 2

Cliente

Servidor

rmiregistryRMI

RMI RMI

Ejemplo (RMI)

resultado = 7

Modelización de la interfaz remota

(Sumador)

public interface Sumador

extends java.rmi.Remote

public int sumar(int a, int b)

Clase que implementa la interfaz

(SumadorImpl)

import java.rmi.*;

import java.rmi.server.UnicastRemoteObject;

public class SumadorImpl

extends UnicastRemoteObject implements Sumador {

public SumadorImpl(String name) throws RemoteExcept ion {

super();

System.out.println("Rebind objeto " + name);

Naming.rebind(name, this);

} catch (Exception e) {

System.out.println("Exception: " + e.getMessage());

e.printStackTrace();

public int sumar (int a, int b) throws RemoteExcept ion

{ return a + b; }

Registro del servicio

� Cualquier programa que quiera instanciar un objeto de esta clase debe realizar el registro con el servicio de nombrado. Ejemplo:

Sumador misuma =

Sumador misuma = (Sumador) Naming.lookup("rmi://" + args[0] + "/” + "MiSumador");

� Antes de arrancar el cliente y el servidor, se debe arrancar el programa rmiregistryen el servidor para el servicio de nombres.

Código del servidor

(SumadorServer)

import java.rmi.*;import java.rmi.server.UnicastRemoteobjeto;public class SumadorImpl

extends UnicastRemoteobjeto implements Sumador {public SumadorImpl(String name)

throws RemoteException {super();try {

System.out.println("Rebind objeto " + name);Naming.rebind(name, this);

import java.rmi.*;

import java.rmi.server.*;

public class SumadorServer {

public static void main (String args[]) {

SumadorImpl misuma = new SumadorImpl("rmi://localhost/MiSumador");

} catch(Exception excr) {

System.out.println("Excepcion: "+excr);

Código en el cliente

(SumadorCliente)

public interface Sumador

extends java.rmi.Remote

public int sumar(int a, int b)

import java.rmi.*;

public class SumadorClient {

int res = 0;

System.out.println ("Buscando Objeto ");

Sumador misuma = (Sumador)Naming.lookup("rmi://" + args[0] + "/" +"MiSumador");

res = misuma.sumar(5, 2);

System.out.println("5 + 2 = " + res);

} catch(Exception e) { System.err.println(" System exception");

System.exit(0);

Invocación remota

Servidor de objetos

SumadorInterface.class

Cliente de objetos

SumadorImpl.class

SumadorServer.class

Skel.class

SumadorCliente.class

Stub.class

¿Cómo se ejecuta?

1. Compilación� javac Sumador.java� javac SumadorImpl.java� javac SumadorClient.java� javac Sumador Server.java

2. Generación de los esqueletos� rmic SumadorImpl

� rmic SumadorImpl3. Copiar SumadorImpl_Stub.class e

interfaz remota a clientes

4. Ejecución del programa de registro de RMI� rmiregistry

5. Ejecución del servidor� java SumadorServer

6. Ejecución del cliente� java SumadorCliente <host-del-servidor>

Tema6 llamadas a procedimientos...

Documents

Transcript of Tema6 llamadas a procedimientos...

TRABAJO DE CORBA

TEMA6-REFLEXIONES INTERNAS

Especificados tecnicas

Powerpoint tema6

Corba 02 Ejemplo Java

Tema6 f 12

SISTEMAS DISTRIBUIDOS EN CORBA

Invocación Dinámica en CORBA

Common Object Request Broker Architecture CORBA Computación de objetos distribuidos y CORBA CORBA es una solución para la distribución de objetos OMG.

Middleware & Corba

Tema6 y7geología

Tema6 avirtual

Tema6 Termodinamica

CORBA - unice.frbaude/AppRep/corbasimpleGris.pdf · 2013. 5. 6. · CORBA Common Object Request Broker Architecture : CORBA Plate-forme client/serveur orientée objets Un standard

Tema6 MOTIVACIÓN

Tema6 opinionpublica

tipos corba

Tema6 Protidos

Corba brief.ppt [Modo de compatibilidad] - CINVESTAVvjsosa/clases/sd/Corba_brief.pdf · CORBA CORBA 2.0 define la IOR para referencia a objetos en entornos multi-ORB Para portabilidad

Tema6 potx