La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "El paradigma RPC Conceptos teóricos de base petición respuesta."— Transcripción de la presentación:

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

2 cliente servidor (ack) clienteservidor ( F3247A) clienteservidor (ack) clienteservidor (leer FA45 de arch1) 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 Variables locales al main Variables locales al main Variables locales al main bytes buf fd dirección regreso SP a) Stack antes llamada readb) Stack durante ejecución readc) Stack después llamada read 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) : }

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 Máquina ClienteMáquina Servidor kernel stub del cliente stub del servidor cliente call return Pack parámetros Unpack resultado Unpack parámetros Pack resultado servidor cal l return Mensaje transportado en la red Principio funcionamiento del RPC

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 Máquina ClienteMáquina Servidor sum mensaje stubs sum(i,j) int i,j; { return(i+j); } : n=sum(4,7); : El paso de parámetros

10 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 Aspectos a considerar en el paso de parámetros

11 #include 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. Binding dinámico: especificación formal servidor

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

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

14 Parámetros entrada/salida de la interfaz binder Acción Parámetros Entrada Salida RegistrarNombre, versión, manejador, id único SuprimirNombre, versión, id único BuscarNombre, versión Manejador, id único

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

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

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

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 Máquina ClienteMáquina Servidor Cliente Stub Cliente Kernel Máquina Llamar procedimientos stub Preparar mensaje buffer Marshall los parámetros en el buffer Poner los encabezados a los mensajes Pasar al kernel 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 Realizar sevicio Servidor Llamar al servidor Poner los parámetros en el stack Unmarshall parámetros 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 Servidor Server Stub Kernel Máquina Ruta crítica de cliente a servidor

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 Recibir Ejecutar Contestar Pet Resp (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 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 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 4k Datos a enviar (a) Mensaje 4k Cliente Servidor ack 0-3 (c) Protocolo tipo blast Cliente Servidor Ack 0 Ack 1 Ack 2 Ack 3 (b) Protocolo stop-and-wait Protocolos blast vs stop-and-wait

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ó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 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 (x Cs mod M )y (x Sp 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 "El paradigma RPC Conceptos teóricos de base petición respuesta."

Presentaciones similares


Anuncios Google