El paradigma RPC

1. petición respuesta El paradigma RPC Conceptos teóricos de base

2. (leer FA45 de arch1) cliente servidor (ack) cliente servidor (34759037F3247A) cliente servidor (ack) cliente servidor Cliente/Servidor: envío/recepción mensajes

3. Desventajas modelo de paso de mensajes • Paradigma del tipo Entrada/Salida • procedimientos send() receive() están dedicados a realizar E/S • E/S no es un concepto clave para los sistemas centralizados; pero sí para la computación o cálculo distribuido • Objetivo: hacer el cálculo distribuido como si fuera cálculo centralizado • Cálculo centralizado: llamadas de procedimientos y/o funciones

4. Ejecución de una llamada de procedimiento local main() { : count = read(fd, bytes, buf) : } main() { : count = read(fd, bytes, buf) : } main() { : count = read(fd, bytes, buf) : } SP Variableslocales al main SP Variables locales al main Variables locales al main bytes buf SP fd dirección regreso a) Stack antes llamada read b) Stack durante ejecución read c) Stack después llamada read

5. Tipos depaso de parámetros • Por valor • en el stack se copia el valor del parámetro • valor de salida es igual al valor de entrada • Por referencia • en el stack se almacena la dirección de la variable • es posible modificar el valor del parámetro • call-by-copie/restore • se copia el valor de la variable en el stack, (como en paso por valor) • al final de la ejecución local se copia el valor que tiene la variable dentro del procedimiento, en el stack • el procedimiento que mandó llamar al procedimiento copia el valor final • en condiciones normales tiene el mismo efecto que el paso por referencia

6. El RPC • Creado por Bireel & Nelson en 1984 • Permiten a los programas llamar procedimientos localizados en otras máquinas • Un proceso x en una máquina A, puede llamar un procedimiento localizado en una máquina B • Información puede llevarse del proceso invocador al invocado dentro de los parámetros • Ningún mensaje u operación de E/S es visible para el programador • Problemas a resolver: • procedimientos invocador e invocado se ejecutan en diferentes máquinas, i.e. diferentes direcciones y posiblemente diferentes arquitecturas • ambas máquinas pueden fallar

7. Principio funcionamiento del RPC Máquina Cliente Máquina Servidor stub del cliente stub del servidor call call Pack parámetros Unpack parámetros cliente servidor Unpack resultado Pack resultado return return kernel kernel Mensaje transportado en la red

8. Proveniencia de los stubs • Varios sistemas: generados automáticamente • rpcgen de Sun • generación archivos esqueleto, para cliente y servidor, a partir de un compilador y de la especificación del servicio • Rutinas de especificación de stubs • rutinas de alto y bajo nivel • posibilidad de definir más aspectos • timeouts • protocolos

9. El paso de parámetros stubs Máquina Cliente Máquina Servidor mensaje mensaje sum(i,j) int i,j; { return(i+j); } : : n=sum(4,7); : : sum sum 4 4 7 7 kernel kernel

10. Aspectos a considerar en el paso de parámetros • Tipos de paso de parámetros • por valor • por referencia • call-by-copy/restore • Problemas a resolver • diferencias entre representación de datos • diferencias en formatos • paso de apuntadores, (estructuras complejas) • Optimización • especificación parámetros de entrada y salida • registros para paso de apuntadores

11. Binding dinámico: especificación formal servidor #include <header.h> specification of file_server, version 3.1 long read(in char name[MAX_PATH], out char buf[BUF_SIZE], in long bytes, in long position); long write(in char name[MAX_PATH], in char buf[BUF_SIZE], in long bytes, in long position); int create(in char[MAX_PATH], in int mode); int delete(in char[MAX_PATH]); end.

12. Registro del servidor Binder SERVIDOR Nombre Num. versión Id.único Manejador, (handler) Otros (autentificación) Sistema Distribuido

13. error Petición cliente 3 servicio NO disponible Binder 1 proceso solicitante 2 servicio disponible 3’ stub cliente Nombre, Num. versión, Id.único, Manejador

14. Parámetros entrada/salida de la interfaz binder Acción Parámetros Entrada Salida Registrar Nombre, versión, manejador, id único Suprimir Nombre, versión, id único Buscar Nombre, versión Manejador, id único

15. Registro y localización de un servidor RPC Paso 1: ‘Este es PRIMEPROG Version 1, Estoy usando el puerto 1061’’ Puerto 111 Servidor Portmapper Paso 2: ‘Donde esta PRIMEPROG Version 1?’ Puerto 1061 Prog Vers Puerto Paso 4: ‘Llama procedimiento 1. Aquí están los datos Paso 3: ‘Esta en el puerto 1061’ Cliente

16. Pasos de una Llamada a un Procedimiento Remoto Máquina Servidora Programa Servidor procedimientos servicio Portmapper función dispatch callrpc () errores o resultados host, programa, versión, procedimiento, argumentos Programa Cliente Máquina Cliente

17. Niveles del Protocolo TCP/IP 5-7. SESIÓN Aplicación Usuario 4. TRANSPORTE TCP UDP 3. RED IP 1-2.ENLACE / FÍSICO Interface Hardware NIVELES OSI R E D

18. Pasos en la ejecución de un RPC 1. El procedimiento del cliente llama al client-stub normalmente. 2. El client-stub construye un mensaje y lo pasa al kernel. 3. El kernel envía el mensaje al kernel remoto. 4. El kernel remoto pasa el mensaje al server-stub. 5. El server-stub desempaca los parámetros y llama al servidor. 6. El servidor realiza el trabajo y regresa el resultado al stub. 7. El server-stub lo empaqueta en un mensaje y lo pasa al kernel. 8. El kernel remoto envía un mensaje al cliente. 9. El kernel del cliente le da el mensaje al client-stub. 10. El stub desempaca el resultado y lo regresa al cliente.

19. Ruta crítica de cliente a servidor Máquina Cliente Máquina Servidor Cliente Servidor Llamar procedimientos stub Realizar sevicio Servidor Preparar mensaje buffer Marshall los parámetros en el buffer Poner los encabezados a los mensajes Pasar al kernel Llamar al servidor Poner los parámetros en el stack Unmarshall parámetros Server Stub Stub Cliente Contexto switch al kernel Copiar mensaje en el kernel Determinar direcciones destino Poner dirección en encabezado mensaje Establecer la interfaz de la red Echar a andar el timer Switch contexto a server stub Copiar mensaje en server stub Ver si stub esta esperando Decidir a que stub darselo Checar el paquete para validación Interrupción de proceso Kernel Máquina Kernel Máquina

20. ¿ ? El RPC en presencia de fallas Consecuencias y comportamiento

21. Posibles fallas en un RPC 1. El cliente es incapaz de localizar al servidor. 2. El mensaje de petición del cliente al servidor se perdió. 3. El mensaje de respuesta del servidor al cliente se perdió. 4. El servidor falló (crashes) después de recibir una petición. 5. El cliente falló (crashes) después de enviar una petición.

22. 1. Cliente incapaz localizar servidor • Uso de timeouts • Cliente puede recibir un -1 en caso de falla, y usar errno para aclaración • Problema: que pasa si el resultado del servicio es el mismo que el código de error • Alternativa: alcanzar una excepción (no todos los lenguajes soportan excepciones) • Lenguaje ADA lo soporta • La excepción es alcanzada por el stub del cliente no por el proceso cliente

23. 2. Pérdida mensaje petición • Kernel empieza un timer cuando se envía el mensaje • Si el timer expira antes de recibir respuesta o un ack el kernel envía la petición de nuevo • No se alcanza una excepción, ya que es el kernel el que retransmite • Si el mensaje se perdió: el servidor no podrá establecer la diferencia entre el primer mensaje enviado y el resto

24. 3. Pérdida mensaje respuesta • Más difícil de tratar • Solución obvia: timer • Problema: kernel cliente no sabe por qué no hay respuesta • Característica petición: idempotencia • Otra solución: numeración de las peticiones de tal forma que el servidor pueda diferenciar las peticiones • Otra más: usar un bit en el encabezado del mensaje para diferenciar peticiones iniciales de las retransmisiones

25. Pet Pet Recibir Ejecutar Contestar Recibir Ejecutar Crash No Resp Resp (a) Caso Normal (b) Crash después ejecución Pet Recibir Crash No Resp (c) Crash antes ejecución 4. Caída del servidor

26. Estrategias caída servidor • At least once (semántica de al menos una vez) • esperar a que el servidor reviva • At most once (semántica de a lo más una vez) • se da por vencido inmediatamente • Ninguna garantía • servidor no reporta nada • Exactamente una vez • todo bien y a la primera

27. 5. Caída del cliente • ¿ A quién se le entrega el resultado del servicio solicitado? • La comunicación está activa y ningún cliente está esperando el resultado • El proceso o la comunicación reciben el nombre de huérfano, con los siguientes problemas. • desperdicio ciclos CPU • bloqueo recursos • confusión cuando el cliente se recupera • Detección caída cliente: timeouts o esperar que el cliente reinicialice y anuncie su presencia

28. Tratamiento de huérfanos • Exterminación • Cliente realiza copias en disco de todas sus peticiones • Reencarnación • Se divide el tiempo en épocas secuencialmente numeradas • Reencarnación gentil • Verifica si el dueño de las comunicaciones remotas existe, si no es el caso elimina la petición • Expiración • Cada RPC cuenta con un quantum de atención • Adopción • Otro proceso da un seguimiento a la petición

29. La implementación de un RPC Aspectos a considerar

30. Aspectos a considerar • Tipo de conexión • orientado conexión • orientado no conexión • Tipo de protocolo • definido por el usuario • uso de uno ya existente • Manejo de acknowledges • protocolo blast • protocolo stop-and-wait

31. Cliente Servidor 0 Ack 0 1 Ack 1 2 Ack 2 3 Ack 3 (b) Protocolo stop-and-wait Protocolos blast vs stop-and-wait 4k Datos a enviar 0 1 2 3 (a) Mensaje 4k Cliente Servidor 0 1 2 3 ack 0-3 (c) Protocolo tipo blast

32. Ventajas/desventajas uso protocolos no conocidos • Protocolos adaptados a las verdaderas necesidades del sistema • Posible mejoramiento del desempeño • Menor número de mensajes • Mensajes más pequeños • Complejidad en el diseño • Difícil el depuramiento de problemas

33. Ventajas elección protocolo conocido (p.e. TCP/IP) 1. Protocolo ya fue diseñado, ahorrando trabajo. 2. Muchas implementaciones están disponibles. 3. Paquetes pueden enviarse y recibirse por casi todos los sistemas Unix. 4. Los paquetes IP y UDP son soportados por muchas redes existentes.

34. La seguridad y el RPC Características y repercusiones

35. ¿Por qué es importante la seguridad ? • RPC es una forma de ejecución que permite que los programas o comandos sean ejecutados en otros sistemas. • RPC introduce vulnerabilidad ya que abre puertas para ataques de usuarios no amigables • RPC se ha convertido en la piedra angular del cálculo cliente/servidor. Todos los aspectos de seguridad de un sistema computacional tienen que construirse sobre un RPC seguro.

36. Aspectos a cuidar • RPC esta basado en intercambio de mensajes entre cliente y servidores • La autentificación del cliente y servidor • Autenticidad y confindencialidad de los mensajes • Control de la autorización de acceso del cliente al servidor

37. Características protocolos de autenticación • Autenticación mutua: las identidades del cliente y servidor son verificadas • la petición fue verdaderamente generada por el cliente y es dirigido al servidor • el mensaje de respuesta es verdaderamente generado por el servidor y es dirigido al cliente • la autenticidad se debe asegurar para los mensajes y los procesos comunicantes • Integridad, confidencialidad y originalidad de los mensajes • mensajes de petición/respuesta no han sido modificados (integridad) • contenido mensajes no ha sido revelado (confidencialidad) • el mismo mensaje no ha aparecido más de dos veces

38. Ejemplo protocolo autentificaciónSun´s Secure RPC • Se asume la existencia de un NIS confiable en lugar de un servidor de autentificación • NIS: contiene una base de datos donde se almacenan los registros de los nombres de los usuarios de la red así como las llaves públicas y privadas • Las llaves NO son usadas para encriptación/desencriptación: • son usadas para generar una sesión criptográfica • llaves públicas: información pública • llaves secretas: son transformadas en secretas aplicando el algoritmo DES y el password del usuario como llave

39. El protoclo de RPC seguro • Cuando un usuario firma (login) en una estación que corre el RPC seguro, el programa login contacta el NIS para obtener registro de la llave usuario • Una vez obtenido lo anterior el programa le solicita al usuario su password • El password es usado para desencriptar la llave secreta encriptada • Se descarta el password inmediatamente • Hay que notar que, en ningún momento, el password viajó por la red • Después de un login exitoso el proceso cliente intenta establecer una sesión de comunicación con el proceso servidor

40. El programa login deposita la llave secreta del cliente Cs en la memoria del servidor de llaves • Algo similar ocurrió en el sitio servidor • Los procesos servidor de llaves en el cliente y en el servidor son responsables de generar una llave de sesión común al cliente y servidor. • Esto se hace a través de un intercambio exponencial de llave. • Un par de llaves públicas y secretas son asignadas a cada cliente y servidor (Cs, Cp) y servidor (Ss,Sp) • Llaves son generadas de la siguiente forma: • Cs y Ss son números random de 128 bits • Cp y Sp se calculan a partir de (xCs mod M )y (xSp mod M) respectivamente, donde x y M son constantes • Dichas llaves son registradas en el sistema

41. Una vez que las llaves has sido generadas las llaves secretas son borradas de la memoria del servidor NIS • La llave obtenida en sesión de acuerdo establece una autenticidad mutua del cliente y servidor, ya que solo puede ser generada a partir de las llaves secretas • Cada mensaje es autentificado por una llave de conversación Ck, (número random de 56 bits generado por el cliente y enviado al servidor usando la llave de sesión) • Llave conversación es mantenida en el servidor de llaves y es usada en la sesión entera entre cliente y servidor • Llave sesión es usada muy poco en la red: cuando la llave de conversación es transmitida • La razón de utilizar una llave de conversación en los siguientes RPCs es que no es derivada de las llaves secretas y por lo tanto es más segura por un periodo largo. • Es diferente para cada sesión

42. Otros tipos de información dentro del RPC • Un RPC puede contener más información • Timestamps (estampillas de tiempo) • usados para la expiración de mensajes • Nonce (versión) • protección en contra de replicas mensajes • Message digest (firma) • valor hash de datos de mensajes, usado para detectar cualquier alteración de mensajes • La encriptación de la información anterior a través de una llave de conversación proporciona autenticidad y confidencialidad de mensajes