El paradigma RPC

Conceptos teóricos de base

petición

respuesta

cliente servidor(ack)

cliente servidor(34759037F3247A)

cliente servidor(ack)

cliente servidor(leer FA45 de arch1)

Cliente/Servidor: envío/recepción mensajes

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

Variables locales al main

Variables locales al main

Variables locales al main

bytesbuffd

dirección regreso

SP SP

SP

a) Stack antes llamada read b) Stack durante ejecución read c) 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) :}

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

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

Máquina Cliente Máquina Servidor

kernel kernel

stub delcliente

stub delservidor

cliente

call

return

Packparámetros

Unpackresultado

Unpackparámetros

Packresultado

servidor

call

return

Mensaje transportado en la red

Principio funcionamiento del RPC

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

kernel kernel

Máquina Cliente Máquina Servidor

sum sum

47

47

mensaje mensaje

stubs

sum(i,j)int i,j;{ return(i+j);}

: :n=sum(4,7); : :

El paso de parámetrosEl 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

Aspectos a considerar en el paso de parámetros

#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.

Binding dinámico: especificación formal servidor

SERVIDORBinder

Sistema DistribuidoNombreNum. versiónId.únicoManejador, (handler)Otros (autentificación)

Registro del servidorRegistro del servidor

procesosolicitante

stubcliente

Binder

serviciodisponible

servicio NOdisponible

error

Nombre, Num. versión,Id.único, Manejador

1

2

3

3’

Petición clientePetición cliente

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

Prog Vers Puerto

Paso 1: ‘Este es PRIMEPROG Version 1,Estoy usando el puerto 1061’’

Paso 2: ‘Dondeesta PRIMEPROGVersion 1?’

Puerto1061

Paso 4: ‘Llamaprocedimiento 1.Aquí están losdatos

Paso 3: ‘Esta en el puerto 1061’

Puerto111

Registro y localización de un servidor RPC

Servidor Portmapper

Cliente

Máquina ServidoraPrograma 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

AplicaciónUsuario

InterfaceHardware

UDPTCP

IP

1-2.ENLACE / FÍSICO

3. RED

4. TRANSPORTE

5-7. SESIÓN

R E D

NIVELESOSI

Niveles del Protocolo TCP/IP

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.

Máquina Cliente Máquina Servidor

Cliente

StubCliente

KernelMáquina

Llamar procedimientos stub

Preparar mensaje bufferMarshall los parámetros en el bufferPoner los encabezados a los mensajesPasar al kernel

Contexto switch al kernelCopiar mensaje en el kernelDeterminar direcciones destinoPoner dirección en encabezado mensajeEstablecer la interfaz de la redEchar a andar el timer

Realizar sevicio Servidor

Llamar al servidorPoner los parámetros en el stackUnmarshall parámetros

Switch contexto a server stubCopiar mensaje en server stubVer si stub esta esperandoDecidir a que stub darseloChecar el paquete para validaciónInterrupción de proceso

Servidor

ServerStub

KernelMáquina

Ruta crítica de cliente a servidor

El RPC en presencia de fallas

Consecuencias y comportamiento

?¿

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.

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

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

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

RecibirEjecutarContestar

Pet

Resp(a) Caso Normal

RecibirEjecutarCrash

Pet

NoResp (b) Crash después ejecución

RecibirCrash

Pet

No Resp (c) Crash antes ejecución

4. Caída del servidor

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

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

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

La implementación de un RPCLa implementación de un RPC

Aspectos a considerar

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

4k Datosa enviar

0 1 2 3

(a) Mensaje 4k

Cliente Servidor

0

1

2

3

ack 0-3(c) Protocolo tipo blast

Cliente Servidor

0

1

2

3

Ack 0

Ack 1

Ack 2

Ack 3

(b) Protocolo stop-and-wait

Protocolos blast vs stop-and-wait

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

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.

La seguridad y el RPCLa seguridad y el RPC

Características y repercusiones

¿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.

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

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

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

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

• 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

• 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

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