La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Conceptos teóricos de base

Presentaciones similares


Presentación del tema: "Conceptos teóricos de base"— Transcripción de la presentación:

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

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

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 Variables locales al main Variables locales al main SP 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 de paso 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 kernel kernel Principio funcionamiento del RPC Máquina Cliente
Máquina Servidor stub del cliente stub del servidor call Pack parámetros Unpack parámetros call 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 kernel kernel 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], int create(in char[MAX_PATH], in int mode); int delete(in char[MAX_PATH]); end.

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

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

14 Acción Parámetros Entrada Salida
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 R E D Niveles del Protocolo TCP/IP NIVELES OSI Aplicación Usuario TCP
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 Kernel Ruta crítica de cliente a servidor Máquina Cliente
Máquina Servidor Cliente Llamar procedimientos stub Servidor 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 4. Caída del servidor Recibir Ejecutar Contestar Pet Resp Recibir
(a) Caso Normal Recibir Ejecutar Crash Pet No Resp (b) Crash después ejecución Recibir Crash Pet No Resp (c) Crash antes ejecución

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 Tipo de protocolo
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 Protocolos blast vs stop-and-wait
4k Datos a enviar Cliente Servidor 1 2 3 Ack 0 Ack 1 Ack 2 Ack 3 (b) Protocolo stop-and-wait (a) Mensaje 4k Cliente Servidor 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 Características y repercusiones
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ón Sun´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 Algo similar ocurrió en el sitio servidor
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


Descargar ppt "Conceptos teóricos de base"

Presentaciones similares


Anuncios Google