Apuntes Sistemas Distribuidos

Alex Marqués Fernández

Tema 1: Introducción a los S. Distribuidos

De sistemas centralizados a sistemas distribuidos:

De 1949 aproximadamente a 1985 funcionábamos principalmente con mainframes,

minicomputadores y supercomputadores, que costaban de entre 10 millones de $ a 10.000$

Tenían una interfaz de texto para aplicaciones científicas, de investigación y empresariales.

A partir de 1985, todo cambia, aparece el microprocesador, que aumenta drásticamente la

velocidad de computación, reduciendo el coste y facilitando la unión entre sistemas
favoreciendo la aparición de los sistemas distribuidos, a su vez que las LAN y WAN (también el
internet por supuesto).
Dicho por tanembaum:

“Un sistema distribuido es aquel que se ejecuta en una colección de máquinas enlazadas
mediante una red pero que actúa como un único procesador virtual.”

Clasificación de Flynn (1972)

Es una forma de clasificación de los sistemas en base a su flujo de instrucciones y de datos.

 SISD: Single Instruction, Single Data

o Un flujo de instrucciones, un flujo de datos.
o Por ejemplo, un mainframe de los años 60.
 SIMD: Single Instruction, Multiple Data
o Un flujo de instrucciones, varios flujos de datos
o Por ejemplo, una computadora de cálculo vectorial
 MISD: Multiple Instrucción, Single Data
o No hay conocidos
 MIMD: Multiple Instruction, Multiple Data
o Múltiples flujos de instrucciones y datos
o Un sistema distribuido ejemplar
Aspectos de diseño de los sistemas distribuidos

Transparencia:

Flexibilidad:

Confiabilidad: Asegurar el funcionamiento del sistema en todo momento, se divide en

disponibilidad y tolerancia a fallos.
Disponibilidad

 No se debe exigir el funcionamiento simultáneo de componentes críticos

 Redundancia, duplicar piezas clave del hardware y del software
 Problemas:
o Consistencia de los datos
o Seguridad, fichero y recursos deben ser protegidos contra el uso no autorizado
 Autenticación

Tolerancia a fallos: ¿Qué ocurre si falla un servidor de manera súbita?

Desempeño:

 Ancho de banda consumido y rendimiento (throughput)

 Tiempo de respuesta y Uso del sistema

Claves y problemas:

 La comunicación entre procesos es el factor más importante en los S.D.

o El envío de mensajes a través de la red es costoso, aunque cada vez menos
 Rendimiento (Tamaño de grano)
o Paralelismo de grano fino: Un gran número de cálculos pequeños y una alta
tasa de interacción entre los resultados no suele ser lo más adecuado
o Paralelismo de grano grueso: Cálculos costosos y una baja tasa de interacción
entre los resultados puede infrautilizar los recursos disponibles

Estabilidad: ¿Qué ocurrirá cuando el S.D. alcance su máximo crecimiento?

Desafíos en la construcción de Sistemas Distribuidos

 Heterogeneidad
o Diferentes redes de comunicación
o Diferentes sistemas operativos
o Diferente hardware
o …
 Extensibilidad
o Necesidad de publicar los interfaces
o Integración de componentes creados por diferentes programadores
 Seguridad
o Proporcionar una protección adecuada: encriptación
o Mantener el secreto de la información que se transmite
o Evitar los ataques que deniegan el servicio
 Escalabilidad
o El coste de añadir un nuevo usuario debe ser constante
 Tratamiento de fallos
o Un proceso, un nodo, la red, etc. Pueden fallas de forma independiente
 Concurrencia
o Los S. D. son fuentes de peticiones concurrentes
  Transparencia
o Muchos aspectos deben aparecer ocultos al programador
o No debemos preocuparnos de la ubicación ni de los detalles de los accesos a
los recursos

Anexo II: Nociones básicas de Threads

En este anexo antes de continuar con el Tema 2, vamos a tratar un poco de entender el
concepto de paralelismo, métodos para conseguirlo (memoria compartida y flujos de
ejecución) y entender su necesidad, así como aprender lo más básico sobre los threads en
POSIX.

La CPU utiliza el valor de PC para determinar cuál es la siguiente instrucción por ejecutar:

- A tal secuencia resultante la llamaremos hilo o flujo de ejecución del programa

- Un thread o flujo de ejecución de un programa está representado por la secuencia de
direcciones tomadas por el PC durante la ejecución del programa

Entonces, si entendemos los threads como una extensión del proceso, podemos “mezclar” los
threads, para ejecutar diferentes procesos, dando así al CAMBIO DE CONTEXTO, el cual es
realizado por el SO.

Utilizar los threads para conseguir paralelismo con baja sobrecarga en la aplicación y en el
sistema, sin embargo, aparecen problemas causados por la concurrencia.

Aun así, con esto ganamos el que podamos evitar los cambios de contexto, es decir, aunque
sólo se esté ejecutando una instrucción a la vez, a efectos prácticos se están ejecutando varios
programas simultáneamente.

Multiprocesamiento simétrico
Más de un thread permiten aprovechar el hardware al máximo, además, la mayoría de los SO y
algunas aplicaciones requieren de este tipo de técnicas para su funcionamiento.

Cada THREAD contiene: Pila de ejecución Valor de PC Conjunto de registros y estado de

ejecución

Un proceso consiste en un entorno de ejecución, formado por uno o más threads.

Definición: un entorno de ejecución es una colección de recursos locales gestionados por el

núcleo sobre los que tienen acceso los threads
Notar que es mejor hacer threads vs procesos, puesto que su creación y gestión es más barata,
además, comparten los recursos de forma más eficiente puesto que comparten el entorno de
ejecución.

Creación de proceso Creación de Thread

Para crear un proceso, debemos de crear un - Asignar una región para la pila
entorno de ejecución incluyendo las tablas - Asignar valores iniciales
del espacio de direcciones - Colocar un id, para gestionarlo
posteriormente

Podemos dar muchos usos a los threads, como evitar esperas activas, para simplificar
problemas de la programación. Aunque tenemos problemas de concurrencia puesto que
comparten los recursos de su entorno.

En conclusión, mucho cuidado con las condiciones de carrera en threads, pueden darse muy
fácilmente y causar problemas muy difíciles de depurar.
El estándar POSIX, para la creación de threads
Permite crear threads de forma transparente al usuario, con llamadas al sistema para creación
y destrucción dinámica de threads, mecanismos para la exclusión mutua, contiene también
llamadas al sistema para el manejo de variables condición. En resumen, todo lo que
necesitamos para gestionar la concurrencia de forma eficiente.

INCLUIDO EN LA LIBRERÍA POSIX.1c

Funciones:

Un proceso puede tener asociados múltiples threads.

Todos los threads comparten el espacio de direcciones del proceso, pueden modificar
variables globales, acceder a descriptores de ficheros abiertos por el proceso y los threads
existentes pueden interferir entre ellos.

La creación de los threads es dinámica, esto significa que:

- Un thread se puede crear en cualquier momento durante la ejecución del proceso

- El número de threads no necesita ser especificado por adelantado
- Los threads se crean dinámicamente, llamando a la función thread_create ();
o Esta función los crea y lo sitúa en la ready queue.

SE PUEDE MIRAR EL EJEMPLO QUE TENEMOS EN LOS APUNTES DE THREADS, EL EJEMPLO DE

COPYFILE Y SU VERSIÓN AUMENTADA DE MÚLTIPLES DESCRIPTORES DE FICHERO
Threads de usuario y de kernel
A nivel de usuario, los threads se ejecutan por encima del SO, siendo invisibles para el kernel.
Además, estos compiten por los recursos del proceso que los ha creado y son gestionados de
forma transparente por el runtime system (tanto para usuario como SO). Esto implica que
producen una sobrecarga a nivel de sistema y de proceso.

A nivel de kernel, se reconocen como una entidad a gestionar por el scheduler (como si un
proceso se tratara), compiten por los recursos a nivel de sistema, no de proceso, sin embargo,
compartir datos y sincronizarlos es menos costoso, pero su coste general es más alto.

Después tenemos los threads híbridos, que tienen las ventajas de ambos, que se implementan
partiendo de los threads de usuario, pero se configuran las unidades de planificación de kernel
se asocian a este, transformándolos en entidades manejadas por el kernel durante la ejecución
del proceso. El cómo se gestionan depende de la implementación.

Threads en Solaris

En solaris, los threads de usuario son threads y los de kernel, procesos ligeros. Su configuración
puede ser muy variada:

Threads de POSIX.1c

Tiene un modelo de soporte híbrido, soportando tanto threads a nivel de usuario como de
kernel.

Su modelo tiene dos niveles de scheduling, separando threads y las demás entidades de kernel

Los threads son análogos a los threads de usuario, mientas que las entidades de kernel son
manejadas por el scheduler a nivel de kernel.

La biblioteca de threads decide cuántas entidades de kernel necesita y cómo se asignarán.

Atributos de los Thread
Para representar y asignar propiedades a los threads se hace de forma parecida a los objetos.

Cada thread tiene asociado un objeto atributo con sus propiedades, pudiendo este estar
asociado a múltiples threads.

Existen funciones para crear, configurar y destruir el objeto atributo

Un programa puede agrupar threads y asociarles el mismo objeto atributo

Estos objetos atributo son del tipo “pthread_attr_t”

ATRIBUTOS:

- Thread Scheduling Contention Scope: Mecanismo que permite al programador

controlar la gestión de la asignación de entidades de kernel a los threads. POSIX, no
especifica cómo compiten con threads externos a su proceso. Este tipo de threads
pueden ser de tipo usuario estricto o pueden ser asignados a un “pool” de entidades
kernel de maneras más complicadas.
- Atributo Contention Scope: Determina con “quién” compiten por los recursos
o PHTREAD_SCOPE_PROCESS: Con el resto de threads del proceso llamador
o PTHREAD_SOCPE_SYSTEM: Compiten por recursos a nivel de sistema.

- pthread_attr_init: inicializa el objeto atributo del thread con los valores por defecto
- pthread_attr_destroy: Invalida los valores del objeto atributo del thread
o Se puede examinar y alterar de un thread su pila y dirección de pila con:
 pthread_attr_setstacksize
 pthread_attr_setstackaddr
 pthread_attr_getstacksize
 pthread_attr_getstackaddr
- pthread_attr_setdetachstate y pthread_attr_getdetachscte
o Permiten modificar y examinar el atributo detachstate de un thread
o Este puede tener estos valores
 PTHREAD_CREATE_JOINABLE: Se puede esperar su terminación
mediante la función pthread_join (default)
 PTHREAD_CREATE_DETACHED: No se puede esperar su terminación
(está desanclado), para liberar sus recursos se deberá llamar a
pthread_detach
- Pthread_attr_setscope y pthread_attr_getsocpe
o Permiten alterar y examinar el contentionscope (MENCIONADO
ANTERIORMENTE)
 PTHREAD_SCOPE_PROCESS
 PTHREAD_SCOPE_SYSTEM
- Pthread_setincheritsched y pthread_getinheritshced
o Modifican o examinan el atributo inheritsched que controla los parámetros de
scheduling:
 Pueden ser heredados del thread creador: PTHREAD_INHERIT_SCHED
 Deben se explícitamente especificados: PTHREAD_EXPLICITI_SCHED
- Pthread_attr_setschedparam y pthread_attr_getschedparam
o Modifican u obtienen la estructura de datos de sctruct sched_param
o La política se scheduling se almacena en el miembro sched_policy de la
estructura struct shced_param
o Sched_policy puede tener valores
 SCHED_FIFO
 SCHED_RR
 SCHED_OTHER
- Pthread_attr_setschedpolicy y pthread_attr_getshcedpolicy
o Permiten cambiar u obtener el miembro sched_policy de la estructura de
datos struct sched_param asociada al scheduling del thread
Tema 2: Modelos de Sistemas Distribuidos

“Un sistema distribuido es aquel en el que los componentes hardware y software localizados
en computadores, conectados en red, comunican y coordinan sus acciones únicamente
mediante el paso de mensajes.”

Por ejemplo, internet, una red local, sistemas industriales, etc.

En este tema estudiaremos las partes de un SD y la relación entre ellas teniendo en cuenta que
está vinculadas con la red de computadores subyacentes.

Características generales de los SD

 Concurrencia global:
Los elementos del sistema se ejecutan realmente en paralelo
 No existe un reloj común:
Afecta a cualquier aspecto de coordinación y mensajes
 Fallos independientes:
Los modos de fallo del sistema pueden ser locales a un subconjunto de sus
componentes

Dificultades y amenazas para los SD

 Modos de utilización muy variables

Componentes del sistema muy utilizados y otros nada utilizados
Aplicaciones para comunicaciones de ancho de banda grande y latencia baja
 Rangos de entornos amplios
Un SD debe acoplar el hardware, el software y las redes de interconexión
 Problemas internos
Relojes NO sincronizados
Consistencia de datos
Fallos hardware y software
 Amenazas externas
Ataques a la integridad de los datos
Ataques a la privacidad de los datos
Accesos denegados a servicios

Modelo Arquitectónico
Su función principal es simplificar y abstraer las funciones de los componentes individuales del
sistema. Para ellos debemos considerar:

- La ubicación de los componentes en la red de computadores

- Las relaciones entre los componentes

Nota: se trata de identificar clientes y servidores en el sistema

El modelo arquitectónico: Capas de software
Analizaremos las distintas capas de este esquema:

Platform:

- Proporciona servicios a las capas superiores

- Se implementa de forma independiente para cada computador
- Proporcionan una interfaz de programación que facilita la comunicación y
sincronización entre procesos

Middleware:

- Capa de software que oculta el sistema que la soporta

- Implementa mecanismos de comunicación y recursos compartidos para las
aplicaciones distribuidas
- Simplifica la programación de los SD, pero algunos de los aspectos de confiabilidad de
los SD necesitan un soporte a nivel de aplicación
- Ejemplos: Sun RPC, CORBA, Java-RMI, etc.
El modelo arquitectónico: Arquitecturas de los sistemas

Modelo Cliente / Servidor:

Servicios proporcionados por múltiples servidores:

Servidores proxy y caches

Servidor proxy: Tiene por objetivo incrementar la disponibilidad y prestaciones del servicio que
ofrece. Puede ser utilizado como cortafuegos en el acceso a los servidores.

Servidor caché: Guardan objetos para que su acceso sea más rápido, poniéndose en medio en
la red para evitar “viajes de la información” más largos. Pueden estar ubicadas en los clientes o
en un servidor proxy compartido para diferentes tipos de servicios.

Aplicaciones peer to peer

El modelo arquitectónico: Variaciones en el modelo C / S

Factores de variación en el modelo cliente / servidor

- El uso de código y agentes móviles

- Las necesidades de los usuarios
o Computadores de bajo coste
o Hardware Limitado
o Aplicaciones sencillas de utilizar
- Necesidades de añadir o eliminar dispositivos móviles

En el caso del código móvil, tenemos los applets, que tienen como ventaja una buena
respuesta interactiva, y como desventaja, que son una potencial brecha de seguridad en
nuestro sistema.
Agentes móviles

Entendemos por agente móvil como un programa en ejecución, que incluye código y datos que
se trasladan de un computador a otros a través de la red realizando una tarea.

- Utilidades: Recopilar información e instalar y mantener el software en los

computadores de una organización
- Ventaja: Reduce el coste de comunicación ya que se sustituyen las llamadas remotas
por locales
- Desventaja: Vuelve a ser una potencial brecha de seguridad en nuestro sistema.

Computadores de red

Una intranet típica: El SO y el software de aplicación es local al computador, pero la gestión de

ficheros de aplicación y el mantenimiento del software local precisa gran esfuerzo técnico, cosa
que el usuario, no suele estar dispuesto a ofrecer. Características:

 El SO y cualquier aplicación software que se necesite se descarga de un servidor de

ficheros remoto
 Las aplicaciones se lanzan en local, los ficheros se gestionan desde un servidor de
ficheros remotos
 Se pueden ejecutar aplicaciones en red
 Los usuarios pueden migrar de un computador de red a otro
 La capacidad del procesador y de la memoria principal se pueden reducir para reducir
costes

Clientes Ligeros

 Capa de aplicación que soporta una interfaz de usuario, normalmente basada en

ventanas sobre un computador local
 Los programas de aplicación se ejecutan en un computador remoto, como, por
ejemplo, esquinazo (DEP)
 Desventaja: las aplicaciones gráficas interactivas ya que, los usuarios pueden sufrir
retardos considerables
Dispositivos móviles y enlace espontáneo a red

Hoy en día casi todos los dispositivos, sobre todo los móviles (celulares, tabletas, smartwatch,
etc.) permiten una conexión a una red sin cables. Esto requiere de un SERVICIO DE
DESCUBRIMIENTO, que admite usuarios y busca recursos.

Este servicio de descubrimiento ofrece una fácil conexión e integración a la red local,
perdiendo a cambio la seguridad de la conectividad, seguridad y privacidad (en cierto grado).

El modelo arquitectónico: Interfaces y objetos

Interfaces: Especifican el conjunto de funciones que se pueden invocar sobre un proceso.
Estas son ESTÁTICAS

Objetos: Los procesos distribuidos que ofrecen servicios pueden ser construidos encapsulando
multitud de objetos. Las referencias a estos objetos se pasan a otros procesos para que se
pueda accedes a sus métodos mediante invocaciones remotas. Los objetos son DINÁMICOS.
El modelo arquitectónico: Requisitos de diseño para arquitecturas distribuidas

Prestaciones: Capacidad de respuesta

Entendemos como capacidad de respuesta como el tiempo que tarda un sistema en comenzar
un trabajo computacional.

Tiene una serie de factores que influyen como:

- Carga y prestaciones del servidor

- La red
- Los retardos en los componentes software
- La comunicación entre los SO del cliente y del servidor
- Los servicios del middleware
- Código del proceso del servicio

En definitiva, podemos entender que cuantas menos capas de software tengamos mejor,
porque si no tenemos que repetir una y otra vez los dato que se pasan entre cada una de las
capas: los enlaces tienen coste. También podemos deducir que cuantos menos datos
transferidos mejor, estos resuelven en que cuantos menos datos y menos se tengan que repetir
estos, mejor.

Prestaciones Rendimiento (throughput)

Entendemos como rendimiento al tiempo que tarda un sistema en realizar un trabajo

computacional. Esto se ve afectado por factores como:

- Velocidad de ejecución de los clientes

- Velocidad de ejecución del servidor
- Tasa de transferencia de datos

En definitiva, influye el rendimiento de cada una de las capas de SW que interviene y la red que
los interconecta, viéndose está limitada por el nodo más débil de éstos (cuello de botella).

Prestaciones: Balanceo de las cargas computacionales

Los servidores de un SD tratan de explotar los recursos disponibles, en especial, procesadores,

memoria, red, etc.
Calidad de Servicio

Afecta tanto a los SO como a las redes

- Fiabilidad, requisito general de un dominio de aplicación:

o Actividades de control y gobierno
o Aplicaciones comerciales (comercio en Internet)
- Seguridad, afecta a las necesidades de ubicar los datos y los recursos en computadores
con sistemas eficaces contra ataques
- Plazos de ejecución (deadline), se trata de satisfacer límites de tiempo
- Adaptabilidad

Esto afecta tanto a los SO como a las redes.

Tenemos la tolerancia a fallos, esto significa que las aplicaciones deben continuar funcionando
en presencia de fallos tanto hardware como software y también fallos de red.

Esto se suele conseguir mediante replicación o redundancia.

Modelos de sistema
Presentando el entorno general tenemos un conjunto de procesos que se comunican unos con
otros mediante el envío de mensajes en una red de computadores

En el diseño de todos los componentes se debe tener en cuenta:

- Prestaciones y fiabilidad de los procesos

- Prestaciones y fiabilidad de las redes
- Seguridad de los recursos

Deben pues, responderse las siguientes cuestiones:

- ¿Cuáles son las entidades principales en el sistema?

- ¿Cómo interactúan?
- ¿Cuáles son las características que afectan a su comportamiento individual y colectivo?

Aspectos claves que deben tratar el modelo de sistema

- Interacción, mediante el paso de mensajes, tratando tanto la comunicación como la

sincronización entre los procesos.
- Fallos: el modelo de fallos debe definir y clasificar los fallos de un S. Distribuido
- Seguridad, el modularidad y su extensibilidad expone a los SD a ataques tanto externos
como internos, el modelo de seguridad definirá y clasificará los modos de ataque y
diseñar sistemas capaces de resistirlos.
Modelos de sistema: de Interacción
El modelo de interacción debe tratar tanto la comunicación como la sincronización entre
procesos, como, por ejemplo:

- Múltiples procesos servidores pueden cooperar entre sí para proporcionar un servicio

- Un conjunto de procesos coopera entre sí para lograr una meta común

Algoritmo secuencial vs Algoritmo distribuido, siendo el secuencial una secuencia de pasos y el

otro una sincronización y comunicación entre procesos.

El modelo de interacción debe tratar tanto la comunicación como la sincronización ente

procesos. Entenderemos los siguientes como factores clave del modelo de interacción:

 Latencia: retardo entre el envío de un mensaje y su recepción, esta incluye:

o El tiempo que tarda una traza en llegar a su destino
o El tiempo de acceso a la red
o El tiempo de los servicios de comunicación del SO
 Ancho de banda: cantidad de información que puede transmitirse en un intervalo dado
de tiempo
 Fluctuación: variación en el tiempo invertido en completar el reparto de una serie de
mensajes

En el modelo de interacción se debe tratar tanto la comunicación como la sincronización entre

los procesos.

Como NO EXISTE UN RELOJ GLOBAL, cada computador de un S. Distribuido tiene su propio

reloj.

Diferenciamos entonces entre dos tipos de S. Distribuidos:

1. SD Síncronos, donde
a. El tiempo de ejecución de cada etapa de un proceso tiene límites superiores e
inferiores conocidos
b. Cada mensaje transmitido sobre un canal se recibe en un tiempo conocido
c. Cada proceso tiene un reloj local cuya diferencia al tiempo global es conocida
2. SD Asíncronos, donde no existen limitaciones sobre
a. La velocidad de proceso
b. Los retardos en la transmisión de mensajes
c. El reloj

En ambos tipos de SD, necesitamos un sistema que nos permita llevar una Ordenación de
eventos, donde es interesante saber cuándo ha ocurrido un evento en un proceso.

La ejecución de un S. Distribuido se puede describir como un conjunto ordenado de

eventos, incluso careciendo de reloj global
Modelos de sistema: de fallo
El modelo de fallo define las formas en las que puede ocurrir un fallo y así entender los efectos
de los fallos.

En un S. Distribuido puede fallar tanto la ejecución de los procesos como los canales de
comunicación. Tenemos diferentes clases de fallos:

- Por omisión
- Fallos arbitrarios
- Fallos de temporización

Fallos por omisión

Se refiere a los casos en los que los procesos o canales de comunicación no consiguen llevar a
cabo su tarea. Distinguimos dos subtipos de fallos:

- Fallo por omisión de procesos: “fallo parado”, es decir, el proceso se para

- Fallo por omisión de comunicaciones: “perder mensajes”, el mensaje no se transporta
desde el buffer de mensajes salientes al buffer de mensajes entrantes, todo esto
ocurre dentro de la máquina.

Fallos arbitrarios

Describen la peor semántica de fallos posible, esta puede suceder en:

- Procesos: el proceso no se ejecuta correctamente

- Canales de comunicación: el mensaje que se envía se corrompe

Este tipo de fallos están principalmente dictados por las leyes de probabilidad y estadística.
Fallos de temporización

Se aplican a los S. Distribuidos síncronos, como es razonable. Estos se producen cuando se

establecen límites de tiempo y no se cumplen, ya sea en:

- La ejecución de un proceso
- En los repartos de los mensajes

Enmascaramiento de fallos

Cada componente de un S. Distribuido se construye a partir de componentes ya existentes en

el sistema, esto significa que:

- Si se conocen las características de fallo de un componente se puede crear un nuevo

servicio que oculte el fallo
- Un servicio “enmascara un fallo” ocultándolo completamente o convirtiéndolo en un
fallo más aceptable

Fiabilidad y comunicación uno a uno

Los canales de comunicación pueden presentar fallos por omisión, pero se pueden construir
servicios de comunicación para enmascarar algunos de esos fallos

- Comunicación fiable: Una comunicación es fiable, si es válida e íntegra, entendiendo

así:
o Validez: Cualquier mensaje en el buffer de mensajes salientes se hará llegar al
buffer de mensajes entrantes
o Integridad: El mensaje recibido es idéntico al enviado, y no se envían mensajes
duplicados
Modelos de sistema: de seguridad
El modelo de seguridad define la seguridad de un S. Distribuido protegiendo las componentes
principales: procesos, canales de comunicación y objetos.

Entonces la pregunta es: ¿Cómo conseguimos un S. Distribuido seguro?

- Asegurando los procesos

- Asegurando los canales de comunicación empleados
- Protegiendo los objetos que encapsulan servicios

Es decir, asegurando las componentes principales del S. Distribuido

Y otra pregunta: ¿De qué debemos protegerlos? De los accesos no autorizados

Protección de objetos

- Los “derechos de acceso” especifican a quien se le permite realizar operaciones con un

objeto
- Cada invocación lleva asociado la autoridad que la ordena. La autoridad pudiera ser un
usuario, un proceso, etc.
- El servidor es responsable de verificar la identidad de esa autoridad en cada invocación
- El cliente puede comprobar la identidad del servidor una vez obtenida la respuesta

Asegurar los procesos y sus interacciones

- Los procesos interaccionan enviando mensajes que viajan por la red, bajo un servicio
de comunicación abierto
- Los clientes y servidores son receptores de mensajes
Otras amenazas de un “enemigo”

- Servicio denegado: El objetivo es retrasar o impedir las acciones de otros usuarios

El enemigo interfiere con las actividades de los usuarios autorizados mediante un
número excesivo de invocaciones sin sentido sobre los servicios o sobre la red
El resultado es una sobrecarga de los recursos físicos
- Código móvil Este código juega el papel de un “caballo de Troya”
Este modificaría los recursos que están disponibles legítimamente para los procesos del
host.

Técnicas para vencer las amenazas de seguridad

- Criptografía y secretos compartidos

Basada en algoritmos de encriptación que emplea claves secretas para transformar los
datos. Sólo se puede invertir el proceso con la clave de desencriptado

Def: - La criptografía es la ciencia de mantener los mensajes seguros

Def: - La encriptación es el proceso de modificar el mensaje de modo que quede
oculto su contenido

- Autenticación
La base de la autenticación la forman el uso de los secretos compartidos y la
encriptación, se trata de incluir en un mensaje un fragmento encriptado que contenga
suficiente contenido del mensaje para garantizar su autenticidad.

- Canales seguros
Se trata de formar una capa de servicio sobre los servicios de comunicación existentes
mediante encriptación y autenticación
Cada proceso conoce bien a la identidad del proceso que solicita la ejecución de sus
servicios
Un canal seguro garantiza la privacidad y la integridad de la información transmitida
por él
Cada mensaje incluye una marca temporal para evitar el reenvía y para permitir la
ordenación de los mensajes

En conclusión, la obtención de un S. Distribuido seguro debería ser un objetivo evidente.

Implica el control de acceso a los objetivos y el empleo de canales de comunicación seguros.

Claro está, esto viene a un alto coste de proceso y administración.

El soporte del sistema operativo: Sistemas monolíticos versus Sistemas
micronúcleo

Sistemas Operativos con núcleo monolítico: UNIX

- Realizan todas las funciones básicas del SO

- Pueden contener algunos procesos servidores: servidores de ficheros y de red

Ventaja

- La invocación a las aplicaciones es relativamente eficiente

Sistemas Operativos micronúcleos: Windows

- Realizan todas las funciones básicas del SO

- Proporcionan las abstracciones más básicas del sistema:
o Espacio de direcciones
o Threads
o Comunicación local entre procesos
- Los servicios del sistema los proporcionan servidores que se cargan dinámicamente en
los nodos que lo requieran
- Los clientes acceden a los servicios del sistema utilizando los mecanismos de
invocación

Ventaja:

- Son extensibles
- El modularidad es fácil de mantener
El soporte del sistema operativo: Funciones básicas del sistema operativo

Se pueden comprimir en:

- Gestor de procesos
Gestiona la creación y las diferentes operaciones sobre procesos

Def: - Un proceso es una unidad de gestión de recursos que posee un espacio de

direcciones y uno o más threads

- Gestor de threads
Gestiona la creación, sincronización y planificación de threads

Def: - Un thread es una actividad planificable asociada a un proceso

- Gestor de comunicaciones
- Gestor de memoria
Gestiona la memoria física y virtual
- Supervisor
Gestiona la resolución de interrupciones: Llamadas al sistema y excepciones
Controla la unidad de memoria y las caches, manipula la unidad de punto flotante y los
registros del procesador.

El soporte del Sistema Operativo: Protección del sistema

- Los recursos necesitan protección contra los accesos no permitidos

- Es interesante utilizar lenguajes de programación con sistemas de tipos seguros, como

Java y C o C++
- Es interesante utilizar el soporte hardware para proteger los módulos de programación
entre sí
Protección del Sistema: dos niveles de ejecución:

Un registro o un bit de modo determina si pueden ejecutarse instrucciones privilegiadas

- Nivel de núcleo: se puede ejecutar todo el repertorio de instrucciones

Un proceso de sistema operativo se ejecuta en modo supervisor / privilegiado
- Nivel de usuario: sólo se puede ejecutar un subconjunto de instrucciones
Un proceso de usuario se ejecuta en modo usuario
- Nivel de núcleo:
o El núcleo es un programa cuyo código siempre se ejecuta con privilegios
completos de acceso a los recursos físicos en el computador
o Impiden que cualquier otro código acceda a los recursos físicos de la máquina
de forma inapropiada
o Pueden controlar la unidad de gestión de memoria, escribir en los registros,
etc.
o El núcleo gestiona el espacio de direcciones para protegerse a sí mismo
o La forma de acceder a los recursos gestionados por el núcleo es a través de una
llamada al sistema

Los servicios del SO dan soporte al middleware de un S. Distribuido

- El sistema Operativo
Facilita la encapsulación y protección de los recursos en los servidores
Soporta los mecanismos de invocación requeridos para el acceso a dichos recursos
(comunicación y planificación)
Dos niveles de ejecución para protección del sistema:
o A nivel de núcleo (kernel)
o A nivel de usuario
Proporcionar las abstracciones de los recursos físicos subyacentes:
o Comunicaciones
o Memoria
o CPU
o Dispositivos de almacenamiento
Sistemas operativos en Red vs. Sistemas Distribuidos
Los S. Distribuidos necesitan compartir sus recursos

Podemos comparar las características de un SO en red y un SO Distribuido

Sistemas Operativos en Red

- Tienen la capacidad de acceder a la red

- Pueden realizar accesos a recursos remotos (NFS: sistema de ficheros en red)
- Cada nodo mantiene la autonomía para la gestión de sus propios recursos
- Existen múltiples imágenes del sistema, una por cada nodo
- Un usuario puede acceder de forma remota a otros computadores y lanzar procesos,
sin embargo, los procesos no pueden planificarse ente los diferentes nodos
- Los usuarios deben decidir en qué nodo se ejecutan sus programas
Sistemas Operativos Distribuidos

- Tiene la capacidad de acceder a la red

- Existe una única imagen del sistema
- El SO controla todos los nodos del sistema y distribuye de forma transparente los
procesos entre los nodos según su política de planificación
- Los usuarios no deben preocuparse del nodo que ejecutará sus programas
- En cada nodo se ejecutará únicamente el software de sistema que sea necesario
- Permite cambiar cualquier servicio de forma independiente
- Proporciona diferentes alternativas del mismo servicio
- Se pueden añadir nuevos servicios
- El núcleo sólo proporciona los mecanismos básicos para que un nodo implemente las
tareas para la gestión de los recursos
- Los módulos de servicio se deben cargar dinámicamente bajo demanda

El soporte del Sistema Operativo: Arquitecturas para procesos multi-threads

Arquitecturas para servidores multi-thread

- Arquitectura de asociación de trabajadores

El servidor durante la inicialización crea un conjunto finito de threads (trabajadores)
para procesar las solicitudes.
- Arquitectura de thread-por-solicitud
El servidor por cada solicitud genera un nuevo thread de trabajo
Ventaja: Se pueden crear tantos trabajadores como solicitudes pendientes
existan
Desventaja: Hay una sobrecarga debido a las operaciones de creación y
destrucción de threads en el “entorno de ejecución”.
- Arquitectura de thread por conexión
El servidor crea un nuevo thread trabajador cuando el cliente realiza múltiples
solicitudes
Asocia un thread a cada conexión
- Arquitectura de thread-por-objeto
Se asocia un thread a cada objeto remoto
Desventaja: Puede haber threads sin trabajo que realizar
 - Threads dentro de clientes
Un proceso cliente puede añadir threads para invocar a los métodos remotos y así
conseguir que el thread que genera los resultados pueda seguir con su trabajo.

Comunicación en S. Distribuidos: IPC

Introducción al IPC: Comunicación entre Procesos

 IPC: “Interprocess Communication”
 Dos tipos de comunicación:
o Basada en variables compartidas
Requiere que el usuario introduzca código para gestionar los buffers de
comunicación
Inconveniente: Los procesos deben residir en la misma máquina
o Basada en el paso de mensajes

Permite comunicar procesos sin recurrir a variables compartidas

Ventaja: Los procesos pueden residir en diferentes máquinas

 El IPC proporciona un mecanismo que permite la comunicación y sincronización entre

procesos mediante el paso de mensajes
o Estructura básica del IPC
 Operación send(mensaje)
 Operación receive(mensaje)
o Proceso de comunicación
 Establecer el enlace de comunicación o link
Realización física: memoria compartida, bus, red, etc.
Realización lógica: Socket, RPCs, RMIs, etc.
 Intercambiar mensajes vía operaciones send/receive
Los mensajes pueden ser de longitud fija o variable

El problema del Productor / Consumidor

Claves en el diseño de un mecanismo de IPC
- Características del enlace de comunicación
o ¿Cómo se establecen los enlaces de comunicación?
o ¿Puede un enlace de comunicación estar asociado a más de dos procesos?
o ¿cuántos enlaces de comunicación puede haber entre dos procesos=
o ¿Qué capacidad tiene el enlace de comunicación?
o ¿El enlace de comunicación es “uni-“ o “bi-“ direccional?
- Características de las operaciones send / receive
o ¿Cuál es el tamaño del mensaje?
o ¿Los mensajes serán de tamaño fijo o de tamaño variable?

Ejemplo de comunicación SIMÉTRICA

Ejemplo de comunicación ASIMÉTRICA

Comunicación indirecta:
- Los mensajes son enviados y recibidos a través de mailboxes o puertos

Def.- Un mailbox es un objeto abstracto donde los procesos depositan y

extraen mensajes

- Cada mailbox tiene un identificador único

- Dos procesos pueden comunicarse sólo si comparten un mailbox
- Primitivas para la comunicación:
o Send(A, mensaje)
o Receive(A, mensaje)
o Crear / Destruir un mailbox
Propiedades del enlace de comunicación:

Los enlaces de comunicación se establecen solamente si los dos procesos comparten

un mailbox

Un enlace de comunicación puede estar asociado con muchos procesos

Cada pareja de procesos puede compartir varios enlaces de comunicación

El enlace de comunicación puede ser unidireccional o bidireccional

“El problema de compartir los enlaces de comunicación”

P1, P2 y P3 comparten el mailbox A

P1 realiza una operación send a A

P2 y P3 realizan una operación receive de A

¿Quién obtiene el mensaje?

A esto tenemos varias soluciones, como no permitir más de dos procesos por mailbox, permitir
que sólo se pueda hacer una receive a la vez o, permitir al sistema escoger quien de los dos
recibe el mensaje de forma arbitraria si P2 o P3, pero no ambos.

NOTA: TANTO RECEIVE COMO SEND PUEDEN SER BLOQUEADORAS O NO, ADEMÁS SEND
PUEDE SER POR COPIA O POR REFERENCIA

Limitaciones del enlace de comunicación

Def.- Capacidad de un enlace de comunicación es el número de mensajes que puede

contener temporalmente

El buffering se puede ver como una cola de mensajes asociada al enlace de

comunicación:

o Con capacidad 0
 Los procesos deben sincronizarse para que la transferencia tenga lugar:
rendezvous – comunicación síncrona
o Con capacidad limitada (longitud máxima = n)
 Relación Productor / Consumidor: el proceso que envía, si el enlace
está lleno, debe esperar
o Con capacidad ilimitada (sin longitud máxima)
 El proceso que envía nunca debe esperar
Los enlaces de comunicación con capacidad no-nula tienen el problema de que el
proceso no sabe cuándo ha sido leído su mensaje, además, cuando ocurre un fallo
debe manejar las excepciones.
IPC en Unix: socket: La familia de protocolos TCP/IP
NOTAS:

Internet es una red que NO respeta el modelo OSI

Ahora discutiremos cómo funciona a diferentes niveles para llegar a un mejor entendimiento

Nivel de red: IP
- Proporciona un servicio sin conexión NO seguro
o No garantiza que todos los mensajes lleguen a su destino.
- Los mensajes no tienen por qué llegar en orden de envío
- IP acepta mensajes de cualquier tamaño < 64kb, los troceará si es necesario para
enviarlos
- Cada host de Internet debe tener una dirección de 32 bits única

Como programar una transferencia entre dos sistemas que sólo ofrecen IP

- Dos funciones, enviar y recibir, a las que pasaríamos las direcciones origen y destino
del mensaje
- Si el tamaño es grande, deberíamos trocear nuestro mensaje
- La aplicación debería estar preparada para reordenar los trozos a la llegada
- La aplicación debería tener algún método de detección y corrección de errores
- Hay que implementar algún método para identificar varios destinos dentro de una
máquina

Nivel de transporte: UDP y TCP

Servicio UDP: User Datagram Protocol

- Servicio no orientado a conexión

- Mismos servicios que IP
- Ofrece la posibilidad de detección de errores
- Puede llegar a perder mensajes enteros, además, si esto sucede, no nos avisa
- Permite gestionar los números de puertos permitiendo varias comunicaciones
simultáneas en la misma máquina
Servicio TCP: Transmission Control Protocol

- Servicio orientado a conexión

- Ofrece primitivas para establecer la conexión y desconexión
- Ofrece primitivas de envío y recepción
- Acepta mensajes de longitud arbitraria
- Garantiza el orden de los paquetes
- Entrega los mensajes completos y libres de errores
- Utiliza números de 16 bits para identificar el destino en una misma máquina: port
Numbers

Requisitos para definir una comunicación sobre el nivel de transporte

- Definición del protocolo de transporte a utilizar: UDP o TCP

- Definición de dirección y puerto en la máquina local y remota
- {protocolo, @host-local, port-local, @host-remoto, port-remoto}
- Notar que los detalles del interfaz TCP/IP dependen de la arquitectura del S.O. que los
implementa

La abstracción socket: Interfaz con TCP/IP

- El interfaz de sockets fue creado en el entorno BSD de Unix
- Fue creado como un interfaz usuario / programador para usar los servicios de red de
las familias de protocolos UNIX, INTERNET, XEROX
- El interfaz tiene todas las primitivas necesarias para la correcta y total utilización de los
servicios que ofrecen estos protocolos
- Las aplicaciones basadas en sockets son fácilmente portables de un sistema a otro

La abstracción socket: El modelo cliente / servidor

- A través de TCP / IP y del interfaz socket se pueden desarrollar aplicaciones para
intercambiar información entre procesos que residan en la misma máquina o que
residan en máquinas remotas
- Toda aplicación distribuida se divide en dos partes:
o Un cliente: Programa que inicia la comunicación con el servidor
o Un servidor: Programa que espera la solicitud de un servicio por parte del
cliente

Problema: Sincronización:

Esto se soluciona asegurando que una de ellas arranca su ejecución y espera indefinidamente
al contacto de la otra

Tenemos modelos de clientes estándar como TELNET(23), FTP(21), E-MAIL(25) etc. y no

estándar que es básicamente cualquier otro

También podemos distinguir entre iterativos y concurrentes

Tipos de modelos de servidores
Con conexión: TCP
TCP proporciona toda la seguridad necesaria
para comunicar a través de una red:
- Verifica la recepción de los datos
- Retransmisiones
- Checksum sobre los datos
- Número de secuencia. Orden de la
información
- Control de flujo
- Informa del estado de la red
Iterativo
- Sirve peticiones en serie: una tras
otra
- Sólo se utilizan si la respuesta puede
ser elaborada en un tiempo
conocido no muy largo
Sin conexión: UDP
- UDP no garantiza una entrega fiable
de los mensajes
- Un mensaje puede perderse, llegar
duplicado o modificado por la red sin
que UDP lo pueda saber
Concurrente
- Cada vez que llega una petición se
crea un proceso hijo que la atiende
- Los nuevos hijos servirán la petición
directamente y finalizarán
- El proceso padre siempre
permanecerá esperando nuevas
peticiones
IPC en Java: socket
Esta sección está dada en las prácticas, si quieres ver el código lo tienes desde la página 41
hasta la 55 del temario (Tema 3-1)

Comunicación en grupo
Los mensajes multidifusión proporcionan una buena infraestructura para construir S.D.

Características:
- Tolerancia a fallos basada en servicios replicados:
o La solicitud de un cliente se dirige a todos los servidores para que realicen la
petición
o Necesitaremos que todos los servidores reciban las solicitudes de servicio en el
mismo orden
- Búsqueda de servidores en redes espontáneas:
o Los clientes pueden utilizar multidifusión para localizar servicios disponibles y
registrar sus interfaces
o La pérdida de una petición no representa un problema
- Los mensajes multidifusión proporcionan una buena infraestructura para construir SD
 Buenas prestaciones en datos replicados:
o Cuando se produce una actualización de datos, se debe comunicar a los
procesos que mantienen las réplicas de datos mediante multidifusión
 Propagación de las notificaciones de eventos:
o Sistema de noticias, cada vez que se produce una noticia, el sistema avisa a los
usuarios interesados

Tenemos ejemplos de multidifusión en Java de la página 58 a la 60 del temario (Tema 3-1)

De las RPCs a las RMIs
IPCs en Sistemas Distribuidos
Capas de servicio software y hardware

El Middleware
Def.- Capa de software cuyo propósito es enmascarar la heterogeneidad del sistema
subyacente y proporcionar un modelo de programación conveniente para los programadores
de aplicaciones

Proporciona el soporte para las siguientes abstracciones:

- Procedimiento remoto
- Comunicación entre un grupo de procesos
- Notificación de eventos
- Replicación de datos compartidos
- Transmisión de datos multimedia en tiempo real

Capas de Middleware
Ejemplos:

- Paquete RPC (Remote Proceudre Call) de Sun Microsystems

- Sistemas de comunicación en grupo: ISIS
- CORBA (Common Object Request Boker Architecture) de OMG (Object Management
Group)
- RMI (Remote Method Invocation) para Java
- DCOM (Modelo Común de Objetos Distribuidos de Microsoft

Características

- Fiabilidad, un servicio de mensajes punto a punto es fiable si se garantiza la entrega de

los mensajes
- Ordenación, se necesita que los mensajes sean entregados en el orden en el que fuero
transmitidos por el emisor
Notar que, la entrega de mensajes desordenados se considera un fallo

Representación externa de datos

Tenemos una serie de problemas al intercambiar datos entre dos computadores

- Los mensajes de transferencia consisten en una secuencia de bytes

- El empaquetado de datos consiste en coger una colección de datos y unirlos para
construir un mensaje para la transmisión
o Representación de caracteres

ASCII 1 byte
Unicode 2 bytes
o Representación de enteros
 big-endian
 little-endian

A lo que proponemos una serie de soluciones

- Utilizar un formato externo: “Representación externa de datos”

Antes de la transmisión convertir los datos al formato externo que entenderá el
receptor
- Transmitir los datos indicando el formato utilizado
El receptor deberá convertir los datos si es necesario

Notar que, la tarea de empaquetado y desempaquetado de los datos la realiza el middleware y

es transparente al programador
También tenemos otras alternativas como:

- Representación común de los datos

o XDR de Sun
o CDR de CORBA

Notar que, la representación little-endian // big-endian, se especifica en el mensaje

- Serialización de objetos Java: RMI

Las RPCs en Unix: representación XDR

RPC – Remote Procedure Call

Las RPC constituyen el núcleo de muchos SO Distribuidos, son una mezcla entre llamadas a
procedimientos y el paso de mensajes

- Evolución:
o RPC
o Invocación de métodos remotos en CORBA
o RMI en Java

Notar que, utilizando RPCs el programador no necesita preocuparse de cómo se realiza la

comunicación entre los procesos: IPC

Funcionamiento de las RPC

Un proceso, cliente, para ejecutar una RPC envía un mensaje a otro proceso, servidor, y
después, esperará el resultado

El mensaje contiene el nombre del procedimiento remoto a ejecutar y los argumentos

El proceso servidor ejecutará el procedimiento remoto, extraerá los argumentos del mensaje,
realizará la llamada al procedimiento de forma local, obtendrá los resultados y los enviará en
otro mensaje al proceso cliente.

- Llamadas al sistema, se ejecutan en un hilo de ejecución thread, diferente al del

programa que las invoca
- Funciones ordinarias, se ejecutan en el mismo hilo de ejecución thread, del programa
que las invoca.
- RPC: Llamadas a procedimientos remotos, se ejecutan en u hilo de ejecución thread,
que pertenece al espacio de direcciones de otro proceso, servidor remoto
El proceso cliente en RPC
- Debe localizar al proceso servidor, que ejecutará el procedimiento remoto
- Debe construir un mensaje formado por:
o Procedimiento para ejecutar
o Parámetros
- Debe enviar el mensaje al proceso servidor y esperar un mensaje de éste con la
respuesta
- El proceso cliente se bloqueará a la espera de la respuesta del proceso servidor,
extrayendo posteriormente los resultados del mensaje enviado por éste

El proceso servidor en RPC

- El proceso servidor se encontrará en un bucle esperando la llegada de peticiones d
ellos procesos clientes
- Extraerá del mensaje los argumentos y el nombre del procedimiento que debe ejecutar
- Realizará la llamada al procedimiento, que ya es un procedimiento propio del servidor
- Con los resultados obtenidos, construirá un nuevo mensaje y se lo enviará al proceso
cliente

Aspectos en el diseño de RPC y RMI

El IDL: Interface Definition Language

Un interfaz especifica el nombre de un servicio que utilizarán clientes y servidores

El interfaz debe definir:

 El nombre de los procedimientos

 Parámetros de entrada
 Parámetros de salida

La base de una aplicación cliente/servidor utilizando RPC está en:

 Diseñar una interfaz

 Escribir el interfaz en algún IDL

Notar que, los resguardos del cliente y del servidor se generan automáticamente a partir de la
interfaz escrita en algún IDL
Proceso de generación de una RPC en Unix

 Client stub vs Server stub

o Los resguardos del cliente (client stub) y del servidor (server stub) se generan
de forma automática mediante el compilador de interfaces
o Client stub: el resguardo del cliente se encarga de:
 Localizar el servidor
 Empaquetar los parámetros y construir los mensajes que se envían al
servidor
 Esperar la recepción del mensaje del servidor con la respuesta
 Desempaquetar los resultados del mensaje de respuesta
o Server stub: el resguardo del servidor se encarga de:
 Localizar el cliente
 Desempaquetar los parámetros enviados por el cliente
 Empaquetar los resultados del mensaje de respuesta

Notar que, los resguardos del cliente y del servidor son independientes de sus
implementaciones, sólo dependen del interfaz
La transferencia de parámetros en las RPC Unix
¿Qué problemas aparecen al empaquetar y desempaquetar los datos en las transferencias de
los mensajes?

- La representación de los datos puede ser distinta en las máquinas del cliente y del
servidor, por ejemplo, big-endian y little-endian

Solución:

- Utilizar una representación intermedia de los datos utilizando un estándar como por
ejemplo XDR: eXternal Data Representation

El enlace dinámico en las RPC Unix

Permite la localización de los objetos con nombre en un SD

Etapas para establecer el enlace de comunicación:

1. El servidor registra en el servidor de nombres, o enlazador dinámico, los nombres de

los procedimientos que exporta junto con su dirección
Ejemplo.- Utilizando TCP/IP registraría la dirección IP y el puerto en el que se
encuentra escuchando
2. Cuando el cliente ejecuta una RPC busca en el servidor de nombres la dirección del
servidor que exporta un determinado servicio
3. El servidor de nombres envía al cliente la dirección del proceso servidor que exporta un
determinado servicio

Existen dos tipos de enlace: NO Persistente y Persistente

Enlace NO Persistente

- La conexión entre el cliente y el servidor se establece cada vez que se ejecuta una RPC
- Es ineficiente cuando el cliente ejecute muchas RPC de forma repetitiva
- Ventaja: los servidores pueden migrar de un procesador a otros y los clientes no se ven
afectados

Enlace Persistente

- La conexión entre el cliente y el servidor se mantiene después de la primera RPC

- Útil cuando las aplicaciones ejecutan muchas RPC repetidas
- Presenta problemas cuando los servidores cambian de nodo

Notar que, la localización de los servicios es una tarea del resguardo del cliente

Notar que, existen servicios que permiten dar de baja un procedimiento en el servidor de
nombres
Semántica en presencia de fallos en las RPC en Unix
Problemas que presentan las RPC

- El cliente no es capaz de localizar al servidor

- Se pierde el mensaje de solicitud del cliente
- Se pierde el mensaje de respuesta del servidor
- El servidor falla después de recibir una petición
- El cliente falla después de enviar una petición

Notar que, la semántica de las RPC determina qué ocurre cuando se repite una RPC

Tipos de semántica en presencia de fallos de las RPC

- Al menos una vez: garantizan con reintentos que la RPC se ejecuta al menos una vez
- A lo máximo una vez: no hay reintentos, puede que no se llegue a realizar la RPC ni
una sola vez
- Exactamente una vez: Se corresponde con las llamadas a procedimientos locales. Su
implementación es difícil en un S. Distribuido

Def.- Una operación es ídem potente si se puede repetir tantas veces como sea necesario sin
ocasionar ningún problema

Las transferencias bancarias NO son operaciones ídem potentes

La Utilización del paquete RPC de Sun Microsystems

- Diseñado para el desarrollo del sistema de ficheros en red NFS: Network File System
- Los formatos de datos que posee están descritos utilizando la representación XDR, que
también es de Sun
- Un programa hace referencia a un servicio
- Cada programa consta de una serie de funciones o procedimientos que pueden ser
utilizados por los clientes
- Cada programa puede tener varias versiones
- Los programas, versiones y procedimientos se identifican mediante números enteros
- La terna <programa, versión, procedimiento> identifica de forma única cada
procedimiento
La utilidad rpcgen
La utilidad rpcgen genera, a partir de un fichero que contiene las especificaciones de una
aplicación RPC, aplicación.x, los siguientes ficheros.

- Fichero .h: aplicación.h

Contiene las estructuras de datos en C equivalentes a las definidas en el fichero de
especificación
Este fichero deberá incluirse en el código del cliente y en el código del servidor

- Fichero _xdr.c: aplicación_xdr.c

Fichero con las funciones para transformar los datos a la representación XDR
Contiene una función para cada uno de los tipos de datos

- Fichero _clnt.c: aplicación_clnt.c

Fichero con el resguardo del cliente

- Fichero _svc.c: aplicación_svc.c

Fichero con el resguardo del servidor
Forma de uso:

$ rpcgen [-C][-N][-a] infile

Siendo:

 -C : Indica que se utiliza ANSI C

 -N: permite el paso de más de un argumento a las llamadas a métodos (notar que
solamente va a devolver uno)
 -a: Genera todos los ficheros de apoyo posibles
 Infile: fichero que debe tener extensión .x para indicar que es un fichero de
especificaciones de interfaces

La utilidad rpcgen en el SERVIDOR

Los servidores deben contener la implementación de cada uno de los procedimientos definidos
en el fichero de definición de interfaces

tipo_resultado *procedimiento_V_svc (tipo_argumento arg, struct svc_requ *sr)

Notar que, al nombre del procedimiento se le añade el número de versión, “V”, y el sufijo “svc”

La utilidad rpcgen en el CLIENTE

Para que un cliente pueda ejecutar un procedimiento remoto debe establecer una conexión
con el servidor mediante la llamada:

CLIENTE *clnt_create ( char *host, u_long prognum, u_long vers_num, char * protocol );

Argumentos de la llamada:

- Host: nombre de la máquina donde se ejecuta el servidor

- Prognum: número de programa del procedimiento remoto a ejecutar
- Vers_num: versión del procedimiento remoto a ejecutar
- Protocol: protocolo de transporte empleado: UDP / TCP

El prototipo que debe emplear el cliente para las llamadas a procedimientos remotos es:

Tipo_resultado *procedimiento_V ( tipo_argumento arg, CLIENTE *cl );

Siendo V el número de versión

Notar que, las RPC de Sun utilizan los números de versiones para permitir que existen
servidores que ofrezcan los mismos servicios con interfaces distintas
Pasos para convertir llamadas locales en remotas

- Lograr que los programas funcionen utilizando funciones locales

- Reestructurar las funciones para que sólo tengan un parámetro, que se pasará por
valor, y asegurar su funcionamiento local
- Crear un fichero de especificación con extensión .x
- Llamar a la utilidad rpcgen con las opciones -a, -C, -N para generar el conjunto
completo de ficheros de apoyo
- Compilar todos los ficheros fuente, utilizando el fichero makefile, para detectar
posibles errores en las definiciones de los tipos de datos definidos en el fichero de
especificación
- Insertar el código asociado al programa invocador en el fichero nombre_client.c
generado por la utilidad rpcgen
- Insertar el código de las funciones locales en el fichero nombre_server.c generado por
la utilidad rpcgen
- Compilar los fuentes definitivos utilizando el fichero makefile
- Notar que, al permitir múltiples versiones del mismo servicio, éstos se pueden
actualizar sin que haya que modificar los clientes que utilizan versiones anteriores.

Protocolos de autenticación:

Sun RPC en sus mensajes proporcionan campos para la autenticación entre cliente y servidor
(responsable del control de acceso)

- Tipos:
o Ninguno
o Unix: uid y gid del usuario
o Se establece una clave compartida para firmar los mensajes RPC
o Autenticación Kerberos (MS)

Limitaciones de las RPC de Sun:

- Limitación teórica de 64Kbytes

- Limitación práctica de 8Kbytes

Comandos interesantes asociados a rpcgen

rpcbind

Permite registrar un servicio RPC que está escuchando en un puerto

rpcinfo

Informa sobre los servicios de RPC que están disponibles en un nodo dado

El campo netid indica el proveedor de transporte subyacente, UDP o TCP

rpcinfo -d elimina un servicio (aunque no funciona siempre)

Serialización de Objetos en Java
 La interfaz Serializable:
Hay que declarar que una clase implementa la interfaz Serializable (del paquete java.io)
permite que sus instancias sean serializables
 Serialización:
Aplanar un objeto o un conjunto de datos para almacenarlos en disco o para una RMI
 El middleware realiza de forma automática la serialización de los argumentos y
resultados de una RMI
En java RMI tanto los objetos como los datos se pueden pasar como
argumentos en una invocación de métodos remotos
En Java RMI tanto un objeto como los datos pueden ser el resultado de una
invocación de un método remoto

La serialización para hacer referencias a objetos remotos

- Una referencia a un objeto remoto es un identificador para el objeto, que es válido en

todo el S. Distribuido
- Las referencias a objetos remotos se deben generar de modo que aseguren la unicidad
en el espacio y el tiempo
- Cualquier intento de invocar objetos eliminados debería producir una excepción
- En implementaciones simples de RMI, los objetos remotos viven en el proceso que los
crea y sobreviven sólo mientras el proceso sigue en ejecución

Comunicación entre Objetos Distribuidos

Programación orientada a objetos en aplicaciones distribuidas

Las aplicaciones distribuidas se componen de programas cooperantes que se ejecutan en

procesos distinto y en computadores diferentes.

Son la extensión del modelo de llamadas a procedimientos remotos (RPC) con el modelo de
programación de objetos
Ejemplos:

- RMI: Remote Method Invocation

- Extensión del modelo de programación de eventos

¿Qué proporciona el middleware?

- Transparencia en la ubicación
RPC, RMI y programas distribuidos basados en eventos no necesitan conocer la
ubicación del servidor
- Protocolos de comunicación

UDP y TCP

- Compatibilidad del hardware de los computadores

A través de los estándares comunes para la representación externa de datos
- Sistemas Operativos
Hace independientes los SO subyacentes
- Utilización de diversos lenguajes de programación
Permite que las aplicaciones distribuidas sean escritas en más de un lenguaje de
programación, como por ejemplo CORBA (Aunque para ello necesitamos un IDL:
Interface Definition Language)

Las interfaces de programación

- Permiten la comunicación entre módulos de programación en local

o Llamadas a procedimientos
o Acceso a variables de otros módulos
- Permiten la comunicación remota en sistemas distribuidos
o Llamadas a procedimientos: Los parámetros de entrada y salida deben
transmitirse en los mensajes d petición / respuesta
o Acceso a variables remotas: NO pueden pasarse punteros como argumentos o
como valores de entorno.

Tipos de interfaces de programación

- Interfaz de servicio

Especifica los procedimientos que ofrece un servidor y define los tipos de argumentos
de entrada / salida para los procedimientos

- Interfaz remota
 Especifica los métodos de un objeto disponible para su invocación por objetos de otros
procesos y define los tipos de argumentos de entrada / salida para cada método

Capas del middleware

El modelo de objetos

Un programa orientado a objetos consta de un conjunto de objetos que interaccionan entre

ellos:

El modelo de objetos: claves

- Referencias a objetos
Se puede acceder a los objetos mediante las referencias del objeto
- Interfaces
Proporcionan la definición de un conjunto de métodos sin especificar su
implementación
- Acciones
Se inicia una acción en un objeto cuando se invoca a un método de otro objeto
Para iniciar una acción es necesaria la referencia del objeto
- Excepciones
Errores y condiciones inesperadas que pueden aparecer en un programa
En una RMI puede fallar tanto el proceso como el nodo
Los IDLs permiten lanzar excepción tanto a nivel de aplicación como a nivel de
distribución
- Compactación automática de la memoria
Es necesario proporcionar mecanismos de liberación del espacio ocupado por
aquellos objetos que ya no se necesitan
Se necesita mantener una cuenta de referencias
El modelo de objetos

Claves en el modelo de objetos

- Los objetos se utilizan para encapsular los recursos de los S. Distribuidos,
proporcionándoles una interfaz definida a través de una serie de métodos
- Los objetos son la unidad de distribución: objetos diferentes pueden residir en nodos
diferentes. Los objetos pueden migrar de nodo
- La comunicación remota se basa en invocaciones a objetos. El sistema de mensajes
queda oculto por el middleware
- Los sistemas de objetos distribuidos pueden adoptar la arquitectura cliente / servidor

Dos conceptos clave en el modelo de objetos:

 Referencia de objeto remoto

Permite a un objeto invocar los métodos de un objeto remoto
Una referencia a objeto remoto es un identificador para referirse a un objeto remoto
particular y único
 Interfaz remoto
Especifica qué métodos de un objeto remoto pueden invocarse remotamente
La clase de objeto remoto implementa los métodos de su interfaz remoto
Los objetos en otros procesos sólo pueden invocar los métodos de la interfaz remota
Los objetos locales pueden invocar los métodos de la interfaz remota y los otros
métodos implementados por el objeto.
El modelo de objetos: CORBA o Java RMI

- CORBA
Proporciona un IDL que permite definir interfaces remotas
Las clases de los objetos remotos y los programas cliente y servidor pueden
implementarse en cualquier lenguaje (C++, Java ,)
- Java RMI
Define las interfaces remotas igual que cualquier interfaz en Java y adquieren su
capacidad remota al extender la interfaz Remote.

El modelo de objetos: Claves de diseño de una RMI

- Los fallos o errores

En caso de fallo es imposible distinguir entre el fallo de red y el fallo de proceso remoto
Los objetos que realicen invocaciones remotas deben ser capaces de recuperarse en
tales situaciones
- La transparencia
Ocultar el empaquetado de datos
Ocultar el paso de mensajes
Ocultar la tarea de ubicación y contacto con el objeto remoto
- La semántica de la invocación RMI: protocolo petición / respuesta
Reintento del mensaje de petición
Filtrado de mensajes duplicados
Retransmisión de resultados
- La semántica de la invocación RMI: ejecución
Quizá se ejecute una vez
o Fallos de pérdida de mensaje de solicitud o de respuesta
o Fallo por caída del servidor
Se ejecuta al menos una vez
o Fallo por caída del servidor
o Fallos arbitrarios: el mensaje de solicitud se retransmite y el método se ejecuta
varias veces
o Operaciones idempotentes / no idempotentes
Se ejecuta como máximo una vez
o El cliente recibe un mensaje de respuesta
Implementación de una RMI: Componentes Software

- Módulo de comunicación
Realiza el protocolo de petición / respuesta entre el client e/ servidor

- Módulo de referencia remota

Traduce las referencias entre objetos locales y remotos
Crea referencias a objetos remotos

- Proxy
Permite que la invocación del método remoto sea transparente para los clientes
Se comporta como un objeto local y dirige el mensaje al objeto remoto
El cliente tiene un proxy para cada objeto remoto del que dispone su referencia
Un proxy ace de intermediario entre cliente y servidor

- Dispatch
Cada servidor tiene un dispatch para cada clase que representa a un objeto remoto

- Esqueleto
Implementa los métodos de la interfaz remota para cada clase de un objeto remoto
Desempaquetar los argumentos del mensaje de petición e invoca al método en el
objeto remoto
Empaqueta el resultado y las excepciones producidas en el mensaje de respuesta

- Generación de las clases para cada proxy, dispatch y esqueleto

o En Java RMI
El compilador Java RMI genera las clases proxy, dispatch y esqueleto desde la
clase del objeto remoto
o En CORBA IDL
Empela el compilador de interfaces para generar las clases para cada proxy,
dispatch y esqueleto.
- Programas cliente y servidor
 o El servidor contiene
 Las clases para dispatch y esqueletos
 Las implementaciones de las clases de todos los objetos remotos a los
que da soporte
o El cliente contiene
 Las clases de cada proxy para todos los objetos remotos que invoque
- El enlazador
Servicio para mantener la tabla que relaciona nombres y referencias remotas
El servidor registra sus objetos remotos mediante su nombre
El cliente busca los objetos remotos por nombre

- Hilos del servidor

Evitan los retrasos en las ejecuciones, pero debemos tener en cuenta los efectos de
ejecuciones concurrentes
- Activación de objetos remotos
Los objetos remotos de poco uso pueden ser arrancados cuando los necesiten los
clientes, como, por ejemplo: FTP

- Almacenes de objetos persistentes

Los almacenes de objetos persistentes gestionan los objetos persistentes
Def.- Se denomina objeto persistente al objeto cuya vida se encuentra garantizada

- Ubicación de objetos
Un servicio de localización ayuda a los clientes a localizar los objetos remotos a partir
de sus referencias a objetos remotos

- Compartición automática de memoria

Recupera la memoria empelada por un objeto cuando ya no hay ningún otro objeto
que lo referencia
En Sistemas Distribuidos necesitamos:
o Compactador automático de memoria distribuido
o Compactador automático de memoria local

Notar que, los algoritmos distribuidos de compactación automática de memoria se basan en el

recuento de las referencias, Igual que en Java
Las RMI de Java: Implementación

Introducción
- Java RMI extiende el modelo de objetos de Java para proporcionar soporte a objetos
distribuidos
- Un objeto conoce que su destino es remoto porque debe manejar Remote Exceptions
- La principal ventaja de utilizar las RMIs de Java es que las interfaces remotas se definen
en Java
- Debemos tener en cuenta el comportamiento de un objeto remoto en un entorno
concurrente

Interfaces remotas
- Se definen mediante la extensión de una interfaz denominada Remote que
proporciona el paquete java.rmi
- Los métodos deberían lanzar Remote Exception

Paso de parámetros y resultados en Java RMI

- Los parámetros de un método son parámetros de entrada y el resultado de un método
es un único parámetro de salida
- Cualquier objeto que implementa la interfaz Serializable puede pasarse como
argumento o ser el resultado

Paso de objetos remotos: por referencia

- Si el parámetro o el resultado implementa una interfaz remota, siempre se pasas como
referencia a un objeto remoto

Paso de objetos no remotos: por valor

- Todos los objetos no remotos serializables se copian y se pasan por valor

Descarga de clases
- Ventajas
 No es necesario que todos los usuarios presenten el mismo conjunto de clases en su
entorno de trabajo
Los programas clientes y servidores pueden hacer un uso transparente de instancias a
clases nuevas cuando se quieran añadir
- RMI registry
Es el enlazador para Java RMI
En cada nodo de servicios donde se alojen objetos remotos deberá haber un ejemplar
de RMI registry
La clase Naming de Java RMIregistry
void rebind (String name, Remote obj)

- Este método es empleado por un servidor para registrar el identificador de un objeto

remoto

void bind (String name, Remote obj)

- Este método puede ser empleado por un servidor para registrar un objeto remoto
mediante su nombre
- Si el nombre ya está ligado a un objeto remoto, se lanza una excepción

void unbind (String name, Remote obj)

- Este método destruye un enlace.

Remote lookup (String name)

- Este método es usado por los clientes para buscar un objeto remoto mediante su
nombre

String [] list()

- Este método devuelve una lista de Strings que contienen los nombres enlazados del
registro

Construcción de programas clientes y servidores

El servidor

Consta de un método main() y una clase sirviente para implementar cada una de sus interfaces
remotas.

El método main del servidor necesita crear un gestor de seguridad para que la seguridad de
java aplique la protección apropiada para un servidor RMI

RMI Security Manager es el gestor de seguridad por defecto

Protege los recursos locales asegunrado que las clases que se descarguen desde
lugares remotos no tengan efecto algunos sobre ellos

El cliente

Establece un gestor de seguridad y posteriormente busca las referencias a objetos remotos

Los clientes proxy se generan mediante un compiladore denominado rmic desde las clases
compiladas del servidor y no desde la definición de la interfaz
Clases de Java que dan soporte a RMI

- UnicastRemoteObject, debe ser extendida para cualquier clase sirviente

- UnicastRemoteObject, extiende una clase abstracta llamada RemoteServer que
proporciona versiones abstractas de los métodos que requieren los servidores remotos

Notificación de eventos
Características de los S. Distribuidos basados en eventos
- Son heterogéneos
Posibilitan la interacción entre componentes del sistema que no han sido diseñados
con esa característica específica
- Son asíncronos
Las notificaciones de eventos son asíncronas

Los eventos pueden ser de varios tipos

- La información de un evento se especifica en sus atributos

Componentes que intervienen en las notificaciones

- El objeto de Interés
Objeto que experimenta cambios de estado como resultado de las operaciones que se
invocan sobre él
- Los Eventos
Un evento aparece en un objeto de interés como resultado de la finalización de la
ejecución de un método
- La Notificación
Objeto que contiene información sobreb un evento
Contiene el tipo de evento y sus atributos: identidad del objeto de interés, métodos
que se invoca, momento en que ocurre, número de secuencia, etc.
- El Suscriptor
Objeto que se ha suscrito a algún tipo de evento de otro objeto. Recibirá notificaciones
de tales eventos
- El Observador
Tiene como objetivo separar un objeto de interés de los objetos suscriptores
Tareas del objeto observador:
o Encaminamiento
o Filtrado de notificaciones
o Patrones de eventos
o Buzones de notificaciones (objetivo: retrasar las notificaciones)
- El Anunciante
Puede ser un objeto de interés o un objeto observador
Objeto que declara la generación de notificaciones de tipo concretos de eventos