Sistemas Informáticos Industriales

Transcripción

1 Escuela Técnica Superior de Ingeniería y Diseño Industrial Universidad Politécnica de Madrid Llamadas a Procedimientos Remotos (RPC) Sistemas Informáticos Industriales 2017/2018 Raquel CEDAZO LEÓN <raquel.cedazo@upm.es>

2 Mi agradecimiento a los profesores del Departamento de Arquitectura y Tecnología de Sistemas Informáticos (Facultad de Informática UPM) por el préstamo del material de la asignatura Sistemas Operativos Distribuidos impartida por Fernando Pérez Costoya y José Mª Peña, con su correspondiente permiso. 2

3 Provisión de servicios en un S. no Distribuido 3

4 Provisión de servicios (C/S) en SD 4

5 Cliente-servidor con paso de mensajes Provisión de servicios en SD tiene mayor complejidad Programador tiene que ocuparse de aspectos como: Operaciones de mensajería Marshalling/Unmarshalling Con conversión de formatos si el sistema de comunicación no lo hace Realizar binding Gestión de esquema de concurrencia elegido Asegurar semántica de comportamiento ante fallos Gestión de conexiones (si se usa esquema con conexión) Si comunicación no fiable, garantizar envío correcto de mensajes Si limitación en tamaño de mensajes, fragmentación y compactación 5

6 Fundamento de las RPC Código añadido a provisión de servicios en SD Es independiente de la implementación del cliente y del servidor Sólo depende de la interfaz de servicio Sólo hay que programar bibliotecas de servicio y aplicaciones Puede generarse automáticamente a partir de la misma Objetivo de las RPC: Provisión de servicios igual que en sistema no distribuido 6

7 Provisión de servicios en SD con RPC 7

8 Componentes de un sistema de RPC En tiempo de construcción del programa: Generador automático de código: Compilador de IDL En tiempo de ejecución del programa: Resguardos Módulos que se incluyen en cliente y en servidor Ocultan comunicación dando abstracción de llamada a procedimiento Runtime de RPC Capa que proporciona servicios que dan soporte a RPC Binding, conversión datos, autenticación, comportamiento ante fallos... Binder: Localización de servicios Ámbito no global: ID servicio+dir. Servidor (Sun/ONC RPC) 8

9 Pila de comunicación en RPC 9

10 Resguardo del cliente (stubs) Proporciona transparencia en el lado del cliente Ofrece la misma API que el servicio Usa servicios de runtime de RPC Tareas realizadas por el stub: Localiza al servidor usando el binder (identificador del servicio) Empaqueta los parámetros de entrada (marshalling) en un formato común para cliente y servidor Envía el mensaje al servidor Espera la recepción del mensaje de respuesta Extrae los resultados (unmarshalling) y los devuelve al cliente que hizo la llamada 10

11 Resguardo del servidor (skeleton) Proporciona transparencia en el lado del servicor Programa que se enlaza en servidor con biblioteca de servicio Usa servicios de runtime de RPC Tareas realizadas por el skeleton: Registra el servicio en el binder Ejecuta bucle de espera de mensajes Recibe petición Desempaqueta el mensaje (unmarshalling) Determina qué método concreto invocar Invoca el procedimiento con los argumentos recibidos y recupera el valor devuelto Empaqueta resultados (marshalling) Envía mensaje al stub del cliente 11

12 12

13 Lenguajes de definición de interfaces Los resguardos se generan a partir de la interfaz de servicio Se deben definir entidades tales como: Un tipo interfaz de servicio con un número de versión asociado Prototipos de funciones, constantes, tipos de datos, Tipos de parámetros: de entrada, de salida o de entrada/salida Sólo definiciones, nunca implementación Lenguaje de definición de interfaces independiente del lenguaje de programación: IDL (Interface Definition Language) Compilador IDL (por ejemplo para C): Fichero IDL fichero.h + resguardo cliente + resguardo servidor Ejemplos: XDR usado en Sun-RPC 13

14 Funcionamiento del compilador de interfaces 14

15 RPC de Sun/ONC Estándar (RFC 1831) y disponible en muchas plataformas Conocido como ONC-RPC (Open Network Computing RPC) Sun emplea XDR (External Data Representation, RFC 1832) Define IDL y formato de representación externo Es independiente de nivel de transporte subyacente (TCP/UDP) Hay distintos tipos de autenticación de cliente: Sin autenticación Modelo UNIX (uid:gid) Basado en cifrado (Secure RPC) Comportamiento ante fallos: Si se implementa sobre TCP: como mucho una vez Sobre UDP, runtime de RPC retransmite petición si no respuesta Permite activar una caché de respuestas en servidor 15

16 Direccionamiento en RPC de Sun/ONC Servicio identificado por nº de programa (32 bits) + versión De 0 a 1FFFFFFF reservados por Sun ID de servicio no tiene ámbito global (ID + dir. Máquina) 1 binder (portmap rpcbind) por máquina en puerto 111 Modo de operación: Resguardo de servidor se da de alta en binder local: Nº de programa + versión + protocolo + puerto (efímero) Cliente especifica: máquina + nº de programa + versión + protocolo Resguardo de cliente contacta con binder de máquina Nº de programa + versión + protocolo puerto Herramienta rpcinfo permite contactar con binder para: obtener lista de servicios dados de alta, ejecutar el procedimiento nulo de un servicio para comprobar si servidor arrancado, etc. 16

17 XDR de RPC de Sun/ONC Extensión de C, permite definir: Un programa (interfaz) y su nº de versión Constantes, tipos y funciones (hay que asignarles un número) Restricción: función con 1 sólo argumento y 1 sólo valor de retorno Compilador rpcgen: Además de.h y resguardos, genera ficheros de marshalling (.xdr) Algunos tipos específicos de XDR: Vectores de tamaño variable: String tipo_elem vector<>; tipo_elem vector<tam_max>; Union distinta de la de C: registro variante union nombre_tipo switch (int discriminante) { case valor1: declaración1; case valor2: declaración2; default: declaraciónn; } 17

18 Servidores Deben implementar cada una de las funciones especificadas en el fichero de definición de interfaces. Estas funciones tienen la forma: tipo_resultado *procedimiento_v_svc(tipo_argumento arg, struct svc_req *sr); Al nombre del procedimiento se le añade el nº de versión y el sufijo svc. El segundo argumento permite acceder a diferentes características como el número de versión o el número de procedimiento. 18

19 Clientes El cliente debe establecer una conexión con el cliente, antes de ejecutar un procedimiento remoto, mediante el servicio: CLIENT *clnt_create(char *host, u_long prognum,u_long versnum, char *protocol); El primer argumento es la máquina donde ejecuta el servidor. Los dos siguientes son el número de programa y el número de versión del procedimiento a ejecutar El último argumento especifica el protocolo de transporte (UDP o TCP) El prototipo que usa el empleo para las llamadas es: tipo_resultado *procedimiento_v(tipo_argumento arg, CLIENT *cl); Donde el sufijo V representa el número de versión. 19