1. MODELOS DE LOS
SISTEMAS
DISTRIBUIDOS
ING. MA. MARGARITA LABASTIDA
ROLDÁN

2. AGENDA
 Introducción
 Modelos Arquitectónicos
 Modelos Fundamentales
 Networking e Internetworking
 Comunicación entre procesos
 Objetos Distribuidos e invocación remota.

3. Introducción
 Un modelo arquitectónico de un sistema
distribuido trata sobre la colocación de sus
partes y las relaciones entre ellas.
 Modelo Cliente – Servidor.
 Modelo de procesos peer to peer.
 Los modelos fundamentales están implicados
en una descripción más formal de las
propiedades que son comunes en todos los
modelos arquitectónicos.

4. Introducción
 Algunos problemas como la falta de
sincronización de relojes y la pérdida de
mensajes se consideran en tres modelos:
 El modelo de interacción, que trata de las
prestaciones y de la dificultad de poner límites
temporales en un sistema distribuido.
 El modelo de fallos que intenta dar una
especificación de los fallos que se producen en los
procesos y en los canales de comunicación.
 El modelo de seguridad que discute sobre las
posibles amenazas para los procesos y los canales
de comunicación.

5. MODELOS
ARQUITECTÓNICOS

6. Modelos Arquitectónicos
 La arquitectura de un sistema es su estructura en
términos de componentes especificados por
separado.
 Un modelo simplifica y abstrae las funciones de
los componentes individuales del sistema en
cuestión y considera:
 La ubicación de los componentes en la red,
definiendo los patrones utilizables para la distribución
de datos y carga de trabajo.
 Las interrelaciones entre los componentes, sus
papeles funcionales y los patrones de comunicación
entre ellos.

7. Modelos Arquitectónicos
 Un primer acercamiento es clasificar los procesos
entre servidores, clientes e iguales, lo que permite
identificar las responsabilidades de cada uno y
ayuda a valorar sus cargas de trabajo y a
determinar el impacto de los fallos en cada uno
de ellos.
 Los resultados de este análisis puede ser
utilizado para especificar la distribución de los
procesos de forma que concuerde con los
objetivos de prestaciones y fiabilidad del sistema
resultante.

8. Modelos Arquitectónicos
 Se pueden construir otros sistemas dinámicos
como variaciones del modelo cliente servidor:
 La posibilidad de mover código de un proceso a otro
permite que un proceso delegue tareas en otro
(ejecución local). Los objetos y el código puede
reubicarse para reducir los retardos de acceso y
minimizar el tráfico de la comunicación.
 Algunos sistemas se diseñan para permitir que las
computadoras y otros dispositivos móviles se añadan
o eliminen sin incidencias, permitiendo el
descubrimiento de servicios disponibles y ofrecer sus
servicios a otros.

9. Capas de Software
 El término arquitectura de
software se refiere a la
estructura del software
como capas o módulos en
una única computadora y
más recientemente en
términos de los servicios
ofrecidos y solicitarlos
entre procesos localizados
en el mismo o diferentes.
 Esta vista orientada a
procesos y a servicios
puede expresarse en
términos de capas de
servicio.
Aplicación de
servicios
Middleware
Sistema Operativo
Computadora y
Hardware de red
P
L
A
T
A
F
O
R
M
A

10. Capas de Software
Plataforma
• Se considera el nivel de hardware y las capas más bajas de software.
• Estas capas proporcionan servicios a las que están por encima de ellas, y
que son implementadas independientemente en cada computadora,
proporcionando una interfaz de programación del sistema.
Middleware
• Se representa mediante procesos u objetos en un conjunto de
computadoras que interactúan entre sí para implementar mecanismos de
comunicación y recursos compartidos para aplicaciones distribuidas.
• Mejora el nivel de las comunicaciones soportando abstracciones como:
procedimiento de invocación remota, comunicación entre un grupo de
procesos, notificación de eventos, replicación de datos compartidos y
transmisión de datos multimedia en tiempo real.

11. Capas de Software
 Considere a CORBA, ofrece una variedad de
servicios que proporcionan a las aplicaciones
funciones que incluyen la gestión de nombres,
seguridad, transacciones, almacenamiento
persistente y notificación de eventos.
 Los servicios de la capa superior son servicios
específicos del domino que utiliza el
middleware, sus operaciones de comunicación
y sus propios servicios.

12. Arquitecturas de Sistema
 La división de responsabilidades entre los
componentes del sistema (aplicaciones,
servidores y otros procesos) y la ubicación de
los componentes en las computadoras en red,
es el aspecto más evidente del diseño de un
sistema distribuido.
 Sus implicaciones fundamentales están en las
prestaciones, fiabilidad y seguridad del sistema
resultante.
 En un sistema distribuido, los procesos con
responsabilidades bien definidas interactúan
con los otros para realizar una actividad útil.

13. Modelo cliente – servidor
 Históricamente es la más importante, el fin
principal es acceder a los recursos compartidos
que ellos gestionan.
 Los servidores pueden, a su vez, ser clientes de
otros servidores.
 Los buscadores, que permiten a los usuarios buscar
resúmenes de la información disponible en las
páginas web de los sitios de Internet.
 Los resúmenes están realizados por programas
denominados escaladores, que se ejecutan en
segundo plano en el sitio del buscador utilizando
peticiones HTTP para acceder a los servidores web
en Internet.

14. Modelo cliente – servidor
 Las tareas del servidor (responder a las consultas
de usuarios) y las tareas de los escaladores
(hacer peticiones a otros servidores web) son
totalmente independientes; pueden ejecutarse
concurrentemente.
 Un buscador típico debiera incluir muchos hilos
de ejecución concurrente, algunos sirviendo a
sus clientes y otros ejecutando escaladores web.

15. Modelo cliente – servidor

16. Servicios proporcionados por
múltiples servidores
 Los servidores pueden implementarse como
distintos procesos de servidor en
computadoras separadas interaccionando,
para proporcionar un servicio a los procesos
clientes.
 Los servidores pueden dividir el conjunto de
objetos en los que está basado el servicio y
distribuírselos entre ellos mismos, o mantener
copias replicadas de ellos en varias máquinas.

17. Servicios proporcionados por
múltiples servidores

18. Servicios proporcionados por
múltiples servidores
 La web maneja una partición de datos en el
que cada servidor web administra su propio
conjunto de recursos.
 Un usuario puede emplear un navegador para
acceder al recurso en cualquiera de los
servidores.
 La replicación se utiliza para aumentar las
prestaciones y disponibilidad y para mejorar la
tolerancia a fallos.
 Proporciona múltiples copias consistentes de
datos en procesos que se ejecutan en
diferentes computadoras.

19. Servicios proporcionados por
múltiples servidores

20. Servidores proxy y cachés
 Un caché es un almacén de objetos de datos
utilizados recientemente, y que se encuentran
más próximo que los objetos en sí.
 Al recibir un objeto nuevo en una computadora
se añade al caché, reemplazando, si fuera
necesario algunos objetos existentes.
 Cuando se necesita un objeto en un proceso
cliente, el servicio caché comprueba inicialmente
la caché y le proporciona el objeto de una copia
actualizada.
 Si no, se buscará una copia actualizada

21. Servidores proxy y cachés
 Las cachés pueden estar en cada cliente o en
un servidor proxy que puede compartirse
desde varios clientes.
 Los navegadores mantienen una caché de las
páginas visitadas recientemente, y de otros
recursos web, en el sistema local de ficheros
del cliente; utilizan una petición HTTP para
comprobar si dichas páginas han sido
actualizadas.
 Los servidores proxy para el web proporcionan
una caché compartida de recursos web a las
máquinas cliente de uno o más sitios.

22. Servidores proxy y cachés
 El propósito de los servidores proxy es
incrementar la disponibilidad y prestaciones
del servicio, reduciendo la carga en redes de
área amplia y en servidores web.

23. Servidores proxy y cachés

24. Procesos <<de igual a igual>>
 En esta arquitectura todos los procesos
desempeñan tareas semejantes,
interactuando cooperativamente como iguales
para realizar una actividad distribuida sin
distinción entre clientes y servidores.
 El código en los procesos parejos o
<<iguales>> mantiene la consistencia de los
recursos y sincroniza las acciones a nivel de
la aplicación cuando es necesario.

25. Procesos <<de igual a igual>>
 En general n procesos parejos podrán interactuar entre
ellos, dependiendo el patrón de comunicación de los
requisitos de la aplicación.
 La eliminación del proceso servidor reduce los retardos
de comunicación entre procesos al acceder a objetos
locales.

26. Procesos <<de igual a igual>>
 Considerando una aplicación de pizarra
distribuida que permite que usuarios en varias
computadoras vean y modifiquen
interactivamente un dibujo que se comparte.
 Se puede implementar con un proceso de
aplicación en cada sitio y que se basa en capas
de middleware para realizar notificación de
eventos y comunicación a grupos para indicar a
todos los procesos de la aplicación de los
cambios en el dibujo.
 Proporciona a los usuarios de objetos distribuidos
una respuesta interactiva mejor que la que se
puede obtener con una arquitectura basada en

27. INTERFACES Y OBJETOS

28. Interfaz
 Se conoce como la especificación del conjunto
de funciones que se pueden invocar sobre él.
 En la forma básica de la arquitectura cliente –
servidor, se considera cada proceso servidor
como una entidad aislada con una interfaz
prescrita que define las funciones que ofrece.

29. Requisitos para el diseño de
arquitecturas distribuidas
 La idea de compartir se logró, en los sistemas
de tiempo compartido de los años 70 con la
utilización de los archivos compartidos.
 Los beneficios se explotaron en sistemas
operativos como Oracle para permitir que los
procesos compartieran recursos, dispositivos
y procesos de aplicación para compartir
objetos de aplicación.

30. Diseño de Arquitecturas
Distribuidas
Prestaciones
Capacidad de
Respuesta
Productividad
Balance de
Carga

31. Diseño de Arquitecturas
Distribuidas
Calidad de Servicio
Propiedades no
funcionales:
*fiabilidad
*seguridad
*prestaciones
La facilidad de
adaptación
para adecuar
configuraciones
variables de
sistema y
disponibilidad.
Algunas
aplicaciones
mantienen
datos críticos
en el tiempo,
flujos de datos
que precisan
ser procesados
o transferidos
de un proceso
a otro
Implica un
requisito para
que el sistema
proporcione
recursos
garantizados de
computación y
comunicación
que sean
suficientes para
permitir a las
aplicaciones
finalizar cada
tarea a tiempo
Cada recurso
crítico debe
reservarse para
las aplicaciones
que requieren
QoS y deben
ser los gestores
de los recursos
los que
proporcionen
las garantías.
Las solicitudes
de reserva se
pueden
rechazar

32. MODELOS DE INTERACCIÓN
MODELOS DE FALLO
MODELOS DE SEGURIDAD
MODELOS
FUNDAMENTALES

33. Modelos fundamentales
 Todas las arquitecturas comparten algunas
propiedades fundamentales:
 Procesos que se comunican por paso de mensajes a
través de una red de computadores
 En particular, trataremos con tres aspectos
 Interacción: el modelo debe definir y clasificar la
comunicación entre elementos del sistema
 Fallos: el modelo debe definir y clasificar los fallos
que pueden darse en el sistema.
 Seguridad: el modelo debe definir y clasificar los
tipos de ataque que pueden afectar al sistema.

34. Modelo de interacción
 Respecto a la interacción, los sistemas
distribuidos deben tener en cuenta que
 Hay limitaciones debidas a la comunicación
 Es imposible predecir el retraso con el que llega un
mensaje
 Es imposible tener una noción global de tiempo
 La ejecución es no determinista y difícil de depurar
 Algoritmo distribuido
 Definición de los pasos que hay que llevar a cabo por
cada uno de los procesos del sistema, incluyendo los
mensajes de transmisión entre ellos

35. Modelo de interacción
Prestaciones del canal de comunicación
 Latencia
 Retardo entre el envío de un mensaje y su
recepción
 Ancho de banda
 Información que puede transmitirse en un
intervalo de tiempo
 Fluctuación (jitter)
 Variación del tiempo invertido en repartir una
serie de mensajes

36. Modelo de interacción
Relojes y eventos de tiempo
 Cada computador tiene su propio reloj interno
(reloj local)
 Puede usarse en procesos locales para marcas de
tiempo
 Tasa de deriva de reloj (clock drift rate)
 Diferencia entre un reloj local y un reloj de referencia
“perfecto”
 Receptores GPS
 Network Time Protocol (NTP)
 Mecanismos de ordenación de eventos
 Dos tipos de modelo de interacción
 Síncrono y asíncrono

37. Modelo de interacción
Modelos síncronos
 Conocimiento de características temporales:
 El tiempo de ejecución de cada etapa de un proceso tiene
ciertos
 límites inferior y superior conocidos
 Cada mensaje transmitido sobre un canal se recibe en un
tiempo límite conocido
 Cada proceso tiene un reloj local cuya tasa de deriva
sobre el tiempo de referencia tiene un límite conocido
 A nivel teórico, podemos establecer unos límites para
tener una idea aproximada de cómo se comportará el
sistema
 A nivel práctico, es imposible garantizar esos límites
siempre
 Aunque a veces se pueden utilizar, por ejemplo como

38. Modelo de interacción
Modelos asíncronos
 No hay limitaciones en cuanto a
 Velocidad de procesamiento
 Retardos en la transmisión de mensajes
 Tasas de deriva de los relojes
 Los sistemas distribuidos reales suelen ser
asíncronos
 Por ejemplo, Internet
 Una solución válida para un sistema asíncrono
lo es también para uno síncrono

39. Modelo de interacción
Ordenación de eventos
 Podemos describir un sistema en términos de
eventos, solucionando así la falta de precisión de
los relojes
 Imaginemos un grupo de usuarios de correo (X, Y,
Z, A)
 X manda un mensaje m1 con el asunto Reunión
 Y y Z responden con mensajes m2 y m3,
respectivamente y en ese orden, con el asunto Re:
Reunión
 Debido a la independencia en los retardos de cada
envío, el usuario A podría ver lo siguiente:

40. Modelo de interacción
Ordenación de eventos

41. Modelo de interacción
Ordenación de eventos
 Si los relojes de X, Y y Z estuvieran sincronizados,
podríamos incluir el tiempo local t1, t2, t3 en los
mensajes m1, m2, m3
 Estaríamos seguros de que t1 < t2 < t3
 Podríamos ordenar los mensajes en concordancia
 Pero los relojes no suelen estar sincronizados
 Lamport [1978] propuso un modelo de tiempo lógico
 Infiere el orden de los mensajes sin recurrir al tiempo físico
 Se basa en las siguientes afirmaciones
 Un mensaje siempre se recibe después de enviarlo
 X manda m1 antes de que Y reciba m1
 La réplica no se envía hasta que no se ha recibido el original
 Y recibe m1 antes de que envíe m2

42. Modelo de interacción
Ordenación de eventos

43. Modelo de fallo
 Estudio de las causas posibles de fallo
 Para poder comprender sus consecuencias
 Tipo de fallo según la entidad
 Fallos de proceso
 Fallos de comunicación
 Tipo de fallo según el problema
 Fallos por omisión
 No se consigue realizar una acción que se debería poder
hacer
 Fallos arbitrarios (bizantinos)
 Errores de cualquier tipo, fuera del esquema de mensajes
 Fallos de temporización
 Superación de tiempos límite en un sistema síncrono

44. Modelo de fallo
Fallo por omisión en procesos
 Fallo del procesamiento (crash)
 Detección del fallo por timeouts (síncrono)
 Si el proceso no responde, consideramos que ha
habido un fallo
 En sistemas asíncronos, nunca podemos estar
seguros
 Fallo-parada (fail-stop)
 Fallo de procesamiento que puede ser detectado
con certeza por el resto de procesos

45. Modelo de fallo
Fallo por omisión en comunicaciones

46. Modelo de fallo
Fallos arbitrarios o bizantinos
 En proceso:
 Se omiten pasos necesarios o deseables del
procesamiento
 Se realizan pasos innecesarios o indeseables en el
procesamiento
 Se omite arbitrariamente la respuesta a mensajes
 En canales de comunicación
 Corrupción de mensajes
 Reparto de mensajes inexistentes
 Duplicación del reparto de mensajes auténticos
 Origen: problema de los generales bizantinos
 Lamport, Shostak and Pease (1982). “The Bizantine
Generals’ Problem”. ACM Transaction on
Programming Languages and Systems 4 (3): 382-401

47. Modelo de fallo
Fallos bizantinos
 El problema es encontrar un algoritmo para
asegurar que los “generales leales” lleguen a
un acuerdo.
 Se muestra que, usando sólo los mensajes
orales, este problema tiene solución si y sólo
si hay más de dos tercios de los generales
son leales

48. Modelo de fallo
Fallo por omisión y arbitrarios (resumen)

49. Modelo de fallo
Fallos de temporización
 Sistemas síncronos
 Sistemas asíncronos
 No existen fallos de temporización, ya que no se
ha dado ninguna garantía al respecto

50. Modelo de fallo
Enmascaramiento de fallos
 Construcción de servicios fiables a partir de
componentes que presenten fallos
 Por ocultación del error
 Por conversión a fallos más aceptables
 Por ejemplo:
 Checksum a de fallo arbitrario a fallo por
omisión
 +retransmisión a de fallo por omisión a
ocultación

51. Modelo de fallo
Comunicación fiable entre dos procesos
 Debe cumplir con dos criterios:
 Validez
 Cualquier mensaje en el búfer de mensajes salientes
llegará, eventualmente, al búfer de mensajes
entrantes
 Es decir, no hay fallos por omisión en el canal
 Integridad
 El mensaje recibido es idéntico al enviado, y no se
repiten mensajes
 Protocolo que adjunta números de secuencia a los
mensajes
 Canales de comunicación seguros
 No hay fallos bizantinos en el canal

52. Modelo de seguridad
 La seguridad en un sistema distribuido se
basa en la seguridad de los procesos y
canales utilizados
 Entendida como seguridad de objetos
 Almacenados e invocados por los procesos
 Transmitidos a través de los canales
 Se logra mediante un sistema de derechos de
acceso y distintos tipos de autoridad

53. Modelo de seguridad
Principal y derechos de acceso
 Principal: autoridad con la que se ordena
cada invocación de objetos o sus resultados
 Se contrasta con los derechos de acceso de
dicho objeto

54. Modelo de seguridad
Modelo de enemigo
 Entidad
 Cualquier máquina conectada (de forma autorizada o
no) a la red
 Enemigo: entidad capaz de
 Enviar cualquier mensaje a cualquier proceso
 Leer o copiar cualquier mensaje compartido entre dos
procesos
 Leer mensajes o emitir mensajes falsos de petición
de servicios

55. Modelo de seguridad
Amenazas
 Amenazas a servidores
 Ciertos servicios no comprueban la identidad del cliente
 Si la comprueban, no suele ser difícil suplantarla (spoofing)
 En vez de una petición de servicio auténtica se busca, p.
ej., obtener información no autorizada o bloquear el
servicio (DoS)
 Amenazas a clientes
 Reciben un resultado falso de la invocación al servicio
 Generalmente, acompañado de suplantación de identidad
 Amenazas a canales de comunicación
 Inyección, copia o alteración de mensajes que viajan por el
canal
 Por ejemplo: obtener un mensaje de transferencia de
dinero, cambiar la cuenta y reenviarlo después

56. Modelo de seguridad
Técnicas de seguridad
 Autenticación: comprobación de la identidad del
proceso
 Criptografía: uso de claves públicas y privadas
 Canales seguros: canal de comunicación sobre
el que dos procesos han establecido una capa de
seguridad basada en criptografía + autenticación:
 Se garantiza la identidad fiable de servidores y
clientes
 Se garantiza la integridad y privacidad de los
mensajes enviados
 Los mensajes incluyen una marca de tiempo para
prevenir su repetición o reordenación maliciosa