Resume Nad

3/6/2021 MODELOS DE SISTEMA
Página 1
2
MODELOS DE SISTEMA
2.1 Introducción
2.2 Modelos físicos
2.3 Maquetas arquitectónicas
2.4 Modelos fundamentales
2.5 Resumen
Este capítulo proporciona una explicación de tres formas importantes y complementarias en
que el diseño de sistemas distribuidos puede describirse y discutirse de manera útil:
Los modelos físicos consideran los tipos de computadoras y dispositivos que constituyen un sistema
https://translate.googleusercontent.com/translate_f 1/62
y su interconectividad, sin detalles de tecnologías específicas.
Los modelos arquitectónicos describen un sistema en términos de computación y
tareas de comunicación realizadas por sus elementos computacionales; el computacional
elementos que son equipos individuales o agregados de ellos apoyados por
interconexiones de red. Cliente-servidor y peer-to-peer son dos de los más
formas de modelo arquitectónico de uso común para sistemas distribuidos.
Los modelos fundamentales adoptan una perspectiva abstracta para describir soluciones a
Problemas individuales que enfrentan la mayoría de los sistemas distribuidos.
No hay hora global en un sistema distribuido, por lo que los relojes en diferentes computadoras sí lo hacen.
no necesariamente dan el mismo tiempo entre sí. Toda la comunicación entre procesos
se logra mediante mensajes. Comunicación de mensajes a través de una red informática
puede verse afectado por retrasos, puede sufrir una variedad de fallas y es vulnerable a la seguridad
ataques. Estos problemas se abordan mediante tres modelos:
• El modelo de interacción se ocupa del desempeño y de la dificultad de establecer el tiempo
límites en un sistema distribuido, por ejemplo, para la entrega de mensajes.
• El modelo de falla intenta dar una especificación precisa de las fallas que pueden ser
exhibidos por procesos y canales de comunicación. Define confiable
comunicación y procesos correctos.
• El modelo de seguridad analiza las posibles amenazas a los procesos y la comunicación.
canales. Introduce el concepto de un canal seguro, que es seguro contra
esas amenazas.
37
Página 2
38 CAPÍT ULO 2 MODELOS DE SIST EMA
2.1 Introducción
Los sistemas destinados a su uso en entornos del mundo real deben diseñarse para
funcionar correctamente en la gama más amplia posible de circunstancias y frente a muchas
posibles dificultades y amenazas (para ver algunos ejemplos, consulte el cuadro al final de este
página). La discusión y los ejemplos del Capítulo 1 sugieren que los sistemas distribuidos de
diferentes tipos comparten propiedades subyacentes importantes y dan lugar a un diseño común
problemas. En este capítulo mostramos cómo las propiedades y los problemas de diseño de los
Los sistemas se pueden capturar y discutir mediante el uso de modelos descriptivos. Cada tipo
del modelo está destinado a proporcionar una descripción abstracta, simplificada pero coherente de un
aspecto relevante del diseño de sistemas distribuidos:
Los modelos físicos son la forma más explícita de describir un sistema; ellos
capturar la composición del hardware de un sistema en términos de las computadoras (y otros
dispositivos, como teléfonos móviles) y sus redes de interconexión.
Los modelos arquitectónicos describen un sistema en términos de computación y

tareas de comunicación realizadas por sus elementos computacionales; el computacional
elementos que son equipos individuales o agregados de ellos apoyados por
interconexiones de red.
Los modelos fundamentales adoptan una perspectiva abstracta para examinar

aspectos de un sistema distribuido. En este capítulo presentamos modelos fundamentales que
examinar tres aspectos importantes de los sistemas distribuidos: modelos de interacción , que
considerar la estructura y secuencia de la comunicación entre los elementos de
el sistema; modelos de falla , que consideran las formas en que un sistema puede fallar
operar correctamente y; modelos de seguridad , que consideran cómo se protege el sistema
contra los intentos de interferir en su correcto funcionamiento o de sustraer sus datos.
Dificultades y amenazas para los sistemas distribuidos • Estos son algunos de los problemas que
los diseñadores de sistemas distribuidos se enfrentan.
M odos de uso muy variados: los componentes de los sistemas están sujetos a una amplia
variaciones en la carga de trabajo - por ejemplo, se accede a algunas páginas web varios millones
veces al día. Algunas partes de un sistema pueden estar desconectadas o mal conectadas
del tiempo, por ejemplo, cuando las computadoras móviles se incluyen en un sistema. Algunos
Las aplicaciones tienen requisitos especiales para un ancho de banda de comunicación alto y bajo
latencia, por ejemplo, aplicaciones multimedia.
Amplia gama de entornos de sistema: un sistema distribuido debe adaptarse
hardware, sistemas operativos y redes heterogéneos. Las redes pueden diferir
ampliamente en rendimiento: las redes inalámbricas operan a una fracción de la velocidad de las redes locales
redes. Sistemas de escalas muy diferentes, que van desde decenas de computadoras hasta
millones de computadoras, deben ser compatibles.
Problemas internos: relojes no sincronizados, actualizaciones de datos en conflicto y muchos
modos de falla de hardware y software que involucran los componentes individuales del sistema.
Amenazas externas: ataques a la integridad y el secreto de los datos, ataques de denegación de servicio.
Página 3
SECCIÓN 2.2 MODELOS FÍSICOS 39
2.2 Modelos físicos
Un modelo físico es una representación de los elementos de hardware subyacentes de un

sistema distribuido que se abstrae de detalles específicos de la computadora y
tecnologías de redes empleadas.
M odelo físico de referencia: un sistema distribuido se definió en el Capítulo 1 como uno en el que
Los componentes de hardware o software ubicados en computadoras en red se comunican y
coordinar sus acciones sólo pasando mensajes. Esto conduce a un mínimo
modelo de un sistema distribuido como un conjunto extensible de nodos informáticos interconectados por
una red informática para el paso necesario de mensajes.
M ás allá de este modelo de línea de base, podemos identificar de manera útil tres generaciones de
sistemas.
Primeros sistemas distribuidos: estos sistemas surgieron a finales de la década de 1970 y principios de la de 1980 en
respuesta al surgimiento de la tecnología de redes de área local, generalmente Ethernet (ver
Sección 3.5). Estos sistemas normalmente constaban de entre 10 y 100 nodos.
interconectados por una red de área local, con conectividad a Internet limitada y compatible
una pequeña gama de servicios, como impresoras locales compartidas y servidores de archivos, así como correo electrónico
y transferencia de archivos a través de Internet. Los sistemas individuales eran en gran parte homogéneos y
la apertura no era una preocupación primordial. Proporcionar calidad de servicio todavía estaba muy en
su infancia y fue un punto focal para gran parte de la investigación en torno a estos primeros sistemas.
Sistemas distribuidos a escala de Internet: sobre la base de esta base, distribuidos a gran escala
Los sistemas comenzaron a surgir en la década de 1990 en respuesta al dramático crecimiento de Internet.
durante este tiempo (por ejemplo, el motor de búsqueda de Google se lanzó por primera vez en 1996). En
tales sistemas, la infraestructura física subyacente consiste en un modelo físico como
ilustrado en el Capítulo 1, Figura 1.3; es decir, un conjunto extensible de nodos interconectados por
una red de redes (Internet). Estos sistemas aprovechan la infraestructura ofrecida por
Internet para que se vuelva verdaderamente global. Incorporan una gran cantidad de nodos y
Proporcionar servicios de sistemas distribuidos para organizaciones globales y en toda la organización.
límites. El nivel de heterogeneidad en tales sistemas es significativo en términos de
redes, arquitectura informática, sistemas operativos, lenguajes empleados y
equipos de desarrollo involucrados. Esto ha llevado a un mayor énfasis en los estándares abiertos.
y tecnologías de middleware asociadas como CORBA y, más recientemente, web
servicios. Se emplearon servicios adicionales para brindar calidad de servicio de extremo a extremo.
propiedades en tales sistemas globales.
Sistemas distribuidos contemporáneos: en los sistemas anteriores, los nodos eran típicamente de escritorio.
computadoras y, por lo tanto, relativamente estático (es decir, permanecer en una ubicación física durante
períodos prolongados), discretos (no integrados en otras entidades físicas) y
autónomo (en gran medida independiente de otras computadoras en términos de su
infraestructura). Las tendencias clave identificadas en la Sección 1.3 han dado lugar a importantes
nuevos desarrollos en modelos físicos:
• La aparición de la informática móvil ha llevado a modelos físicos en los que nodos como
ya que las computadoras portátiles o los teléfonos inteligentes pueden moverse de un lugar a otro en un
sistema, lo que lleva a la necesidad de capacidades adicionales como el descubrimiento de servicios y
apoyo a la interoperación espontánea.
Página 4
• La aparición de la computación ubicua ha llevado a un movimiento de nodos discretos a

arquitecturas donde las computadoras están incrustadas en objetos cotidianos y en el
entorno circundante (por ejemplo, en lavadoras o en hogares inteligentes
más generalmente).
• La aparición de la computación en la nube y, en particular, las arquitecturas de clústeres ha llevado

a un movimiento de nodos autónomos que desempeñan una función determinada a grupos de nodos que
juntos proporcionan un servicio determinado (por ejemplo, un servicio de búsqueda ofrecido por
Google).
El resultado final es una arquitectura física con un aumento significativo en el nivel de

heterogeneidad que abarca, por ejemplo, los dispositivos integrados más pequeños utilizados en
computación ubicua hasta elementos computacionales complejos que se encuentran en Grid
informática. Estos sistemas implementan un conjunto cada vez más variado de tecnologías de red.
y ofrecer una amplia variedad de aplicaciones y servicios. Estos sistemas potencialmente involucran
hasta cientos de miles de nodos.
S istemas distribuidos de sistemas • Un informe reciente analiza el surgimiento de ultra-

sistemas distribuidos a gran escala (ULS) [ www.sei.cmu.edu ]. El informe captura el
complejidad de los sistemas distribuidos modernos al referirse a tales arquitecturas (físicas)
como sistemas de sistemas (reflejando la visión de Internet como una red de redes). A
sistema de sistemas se puede definir como un sistema complejo que consta de una serie de
subsistemas que son sistemas por derecho propio y que se unen para realizar una
tarea o tareas particulares.
Como ejemplo de un sistema de sistemas, considere una gestión ambiental
sistema de predicción de inundaciones. En tal escenario, se implementarán redes de sensores
monitorear el estado de varios parámetros ambientales relacionados con ríos, llanuras aluviales,
efectos de marea y así sucesivamente. Esto luego puede combinarse con sistemas que son responsables de
predecir la probabilidad de inundaciones, mediante la ejecución de simulaciones (a menudo complejas) en, para
por ejemplo, computadoras en grupo (como se discutió en el Capítulo 1). Otros sistemas pueden ser
establecido para mantener y analizar datos históricos o para proporcionar sistemas de alerta temprana
a las partes interesadas clave a través de teléfonos móviles.
Resumen • El desarrollo histórico general capturado en esta sección se resume

en la Figura 2.1, con la tabla destacando los desafíos importantes asociados con
sistemas distribuidos contemporáneos en términos de gestión de los niveles de heterogeneidad y
proporcionando propiedades clave como la apertura y la calidad del servicio.
2.3 Modelos arquitectónicos
La arquitectura de un sistema es su estructura en términos de componentes especificados por separado.

y sus interrelaciones. El objetivo general es garantizar que la estructura cumpla
demandas presentes y futuras sobre él. Las principales preocupaciones son hacer que el sistema sea confiable,
manejable, adaptable y rentable. El diseño arquitectónico de un edificio tiene
aspectos similares: determina no solo su apariencia, sino también su estructura general y
estilo arquitectónico (gótico, neoclásico, moderno) y proporciona un marco consistente de
referencia para el diseño.
Página 5
SECCIÓN 2.3 MODELOS ARQUIT ECT ÓNICOS 41
Figura 2.1 Generaciones de sistemas distribuidos
Sistemas distribuidos: Temprano Escala de Internet Contemporáneo
Escala Pequeña Grande Ultra-grande
Heterogeneidad Dimensiones agregadas

Limitado (típicamente Significativo en términos de
introducido incluyendo
relativamente homogéneo plataformas, idiomas
estilos radicalmente diferentes de
configuraciones) y middleware
arquitectura
Franqueza Gran desafío de investigación

Prioridad significativa
con los estándares existentes no
No es una prioridad con variedad de estándares
aún capaz de abrazar
introducido
sistemas complejos
Calidad de servicio Gran desafío de investigación

Prioridad significativa
con servicios existentes no
En su infancia con gama de servicios
aún capaz de abrazar
introducido
sistemas complejos
En esta sección describimos los principales modelos arquitectónicos empleados en distribuidos

sistemas: los estilos arquitectónicos de los sistemas distribuidos. En particular, ponemos el
base para una comprensión profunda de enfoques como los modelos cliente-servidor,
enfoques de igual a igual, objetos distribuidos, componentes distribuidos, eventos distribuidos
sistemas basados y las diferencias clave entre estos estilos.
La sección adopta un enfoque de tres etapas:
• mirar los elementos arquitectónicos subyacentes centrales que sustentan la modernidad

sistemas distribuidos, destacando la diversidad de enfoques que existen ahora;
• examinar patrones arquitectónicos compuestos que se pueden utilizar de forma aislada o, más
comúnmente, en combinación, en el desarrollo de sistemas distribuidos más sofisticados
soluciones;
• y finalmente, considerando las plataformas de middleware que están disponibles para soportar el
varios estilos de programación que surgen de los estilos arquitectónicos anteriores.
Tenga en cuenta que hay muchas compensaciones asociadas con las opciones identificadas en este capítulo.
en términos de los elementos arquitectónicos empleados, los patrones adoptados y (donde
apropiado) el middleware utilizado, por ejemplo, afectando el rendimiento y
eficacia del sistema resultante. Entender tales compensaciones es posiblemente la clave
habilidad en el diseño de sistemas distribuidos.
2.3.1 Elementos arquitectónicos
Para comprender los bloques de construcción fundamentales de un sistema distribuido, es necesario

considerar cuatro preguntas clave:
• ¿Cuáles son las entidades que se comunican en el sistema distribuido?
Página 6
• ¿Cómo se comunican o, más específicamente, qué paradigma de comunicación

se utiliza?
• ¿Qué roles y responsabilidades (potencialmente cambiantes) tienen en el

¿arquitectura?
• ¿Cómo se asignan a la infraestructura física distribuida (cuál es su

colocación )?
Entidades comunicantes • Las dos primeras preguntas anteriores son absolutamente fundamentales para una
comprensión de los sistemas distribuidos; qué se está comunicando y cómo esas entidades
comunicarse juntos definir un espacio de diseño rico para el desarrollador de sistemas distribuidos
considerar. Es útil abordar la primera pregunta desde un enfoque orientado al sistema y
Perspectiva orientada a problemas.
Desde la perspectiva del sistema, la respuesta suele ser muy clara en que las entidades
que se comunican en un sistema distribuido son típicamente procesos , lo que lleva a la
visión predominante de un sistema distribuido como procesos acoplados con
paradigmas de comunicación entre procesos (como se discutió, por ejemplo, en el capítulo 4), con
dos advertencias:
• En algunos entornos primitivos, como las redes de sensores, el
Los sistemas operativos pueden no admitir abstracciones de procesos (o de hecho cualquier forma de
aislamiento) y, por tanto, las entidades que se comunican en tales sistemas son nodos .
• En la mayoría de los entornos de sistemas distribuidos, los procesos se complementan con subprocesos ,
entonces, estrictamente hablando, son los hilos los puntos finales de la comunicación.
En un nivel, esto es suficiente para modelar un sistema distribuido y, de hecho, el fundamental

Los modelos considerados en la Sección 2.4 adoptan este punto de vista. Desde una perspectiva de programación,
Sin embargo, esto no es suficiente, y se han realizado más abstracciones orientadas a problemas.
propuesto:
Objetos : Se han introducido objetos para permitir y fomentar el uso de objetos.

enfoques orientados en sistemas distribuidos (incluido el diseño orientado a objetos
y lenguajes de programación orientados a objetos). En distribuido basado en objetos
enfoques, un cálculo consta de una serie de objetos que interactúan que representan
unidades naturales de descomposición para el dominio del problema dado. Se accede a los objetos
a través de interfaces, con un lenguaje de definición de interfaz asociado (o IDL) que proporciona un
especificación de los métodos definidos en un objeto. Los objetos distribuidos se han convertido
un área importante de estudio en sistemas distribuidos, y se le da mayor consideración a este
tema en los Capítulos 5 y 8.
Componentes : Desde su introducción, se han planteado varios problemas importantes.

identificado con objetos distribuidos, y ha surgido el uso de tecnología de componentes
como respuesta directa a tales debilidades. Los componentes se parecen a los objetos en que
ofrecen abstracciones orientadas a problemas para la construcción de sistemas distribuidos y también son
se accede a través de interfaces. La diferencia clave es que los componentes especifican no solo
sus interfaces (proporcionadas), sino también las suposiciones que hacen en términos de otras
componentes / interfaces que deben estar presentes para que un componente cumpla su función - en
En otras palabras, hacer explícitas todas las dependencias y proporcionar una descripción más completa.
contrato para la construcción del sistema. Este enfoque más contractual fomenta y
Página 7
permite el desarrollo de componentes por parte de terceros y también promueve una

enfoque compositivo para la construcción de sistemas distribuidos mediante la eliminación de ocultos
dependencias. El middleware basado en componentes a menudo proporciona soporte adicional para
áreas clave como la implementación y el soporte para la programación del lado del servidor [Heineman
y Councill 2001]. Se pueden encontrar más detalles de los enfoques basados en componentes en
Capítulo 8.
Servicios web : los servicios web representan el tercer paradigma importante para la
desarrollo de sistemas distribuidos [Alonso et al . 2004]. Los servicios web están estrechamente
relacionados con objetos y componentes, nuevamente adoptando un enfoque basado en la encapsulación
de comportamiento y acceso a través de interfaces. Por el contrario, sin embargo, los servicios web son
intrínsecamente integrado en la World Wide Web, utilizando estándares web para representar
y descubre los servicios. El consorcio World Wide Web (W3C) define una red
servicio como:
... una aplicación de software identificada por un URI, cuyas interfaces y

Los enlaces se pueden definir, describir y descubrir como XM L
artefactos. Un servicio web admite interacciones directas con otro software
agentes que utilizan intercambios de mensajes basados en XM L a través de Internet
protocolos.
En otras palabras, los servicios web están parcialmente definidos por las tecnologías basadas en web que
adoptar. Otra distinción importante se deriva del estilo de uso de la tecnología.
M ientras que los objetos y componentes se utilizan a menudo dentro de una organización para desarrollar
aplicaciones estrechamente acopladas, los servicios web generalmente se consideran servicios completos
por derecho propio que se pueden combinar para lograr servicios de valor agregado, a menudo
cruzando los límites de la organización y, por lo tanto, logrando empresa a empresa
integración. Los servicios web pueden ser implementados por diferentes proveedores y utilizando
diferentes tecnologías subyacentes. Los servicios web se tratan con más detalle en el Capítulo 9.
Paradigmas de comunicación • Ahora centramos nuestra atención en cómo las entidades se comunican en
un sistema distribuido, y considere tres tipos de paradigma de comunicación:
• comunicación entre procesos;
• invocación remota;
• comunicación indirecta.
La comunicación entre procesos se refiere al soporte de nivel relativamente bajo para

comunicación entre procesos en sistemas distribuidos, incluido el paso de mensajes
primitivas, acceso directo a la API que ofrecen los protocolos de Internet (programación de sockets)
y soporte para comunicación multidifusión. Dichos servicios se analizan en detalle en
Capítulo 4.
La invocación remota representa el paradigma de comunicación más común en
sistemas distribuidos, que cubren una gama de técnicas basadas en un intercambio bidireccional
entre entidades comunicantes en un sistema distribuido y resulta en la llamada de un
operación, procedimiento o método remoto, como se define más adelante (y se considera completamente
en el Capítulo 5):
Protocolos de solicitud-respuesta : los protocolos de solicitud-respuesta son efectivamente un patrón impuesto

en un servicio de paso de mensajes subyacente para admitir la informática cliente-servidor. En
Página 8
En particular, tales protocolos normalmente implican un intercambio de mensajes por pares de

cliente a servidor y luego de servidor a cliente, con el primer mensaje que contiene
una codificación de la operación que se ejecutará en el servidor y también una matriz de bytes
que contiene argumentos asociados y el segundo mensaje que contiene los resultados de la
operación, nuevamente codificada como una matriz de bytes. Este paradigma es bastante primitivo y
solo se utiliza realmente en sistemas integrados donde el rendimiento es primordial. La
El enfoque también se utiliza en el protocolo HTTP descrito en la Sección 5.2. La mayoría distribuida
Los sistemas optarán por utilizar llamadas a procedimientos remotos o invocación de métodos remotos, según
discutido a continuación, pero tenga en cuenta que ambos enfoques están respaldados por solicitudes subyacentes:
Intercambios de respuesta.
Llamadas a procedimiento remoto : el concepto de una llamada a procedimiento remoto (RPC), inicialmente
atribuido a Birrell y Nelson [1984], representa un gran avance intelectual
en informática distribuida. En RPC, los procedimientos en procesos en equipos remotos pueden
ser llamados como si fueran procedimientos en el espacio de direcciones local. El RPC subyacente
El sistema oculta aspectos importantes de la distribución, incluida la codificación y
decodificación de parámetros y resultados, el paso de mensajes y la preservación de la
semántica requerida para la llamada a procedimiento. Este enfoque de forma directa y elegante
Soporta computación cliente-servidor con servidores que ofrecen un conjunto de operaciones a través de un
interfaz de servicio y clientes que llaman a estas operaciones directamente como si estuvieran disponibles
en la zona. Por lo tanto, los sistemas RPC ofrecen (como mínimo) acceso y ubicación
transparencia.
Invocación de método remoto : la invocación de método remoto (RM I) se parece mucho

llamadas a procedimientos remotos pero en un mundo de objetos distribuidos. Con este enfoque, un
El
losobjeto degeneralmente
detalles llamada puede invocar
están un método
ocultos en un
al usuario. Lasobjeto remoto. Al igual
implementaciones queIcon
de RM RPC,sin
pueden, el subyacente
embargo, ir
además, al admitir la identidad del objeto y la capacidad asociada para pasar el objeto
identificadores como parámetros en llamadas remotas. También se benefician más generalmente de
mayor integración en lenguajes orientados a objetos como se discutió en el Capítulo 5.
El conjunto de técnicas anterior tiene una cosa en común: la comunicación representa un

Relación bidireccional entre un remitente y un receptor con remitentes que dirigen explícitamente
mensajes / invocaciones a los receptores asociados. Los receptores también son generalmente conscientes de
la identidad de los remitentes y, en la mayoría de los casos, ambas partes deben existir al mismo tiempo. En
Por el contrario, han surgido una serie de técnicas mediante las cuales la comunicación es indirecta,
a través de una tercera entidad, lo que permite un fuerte grado de desacoplamiento entre remitentes y
receptores. En particular:
• Los remitentes no necesitan saber a quién están enviando ( desacoplamiento de espacio ).
• No es necesario que los emisores y los receptores existan al mismo tiempo ( desacoplamiento de tiempo ).
La comunicación indirecta se analiza con más detalle en el Capítulo 6.

Las técnicas clave para la comunicación indirecta incluyen:
Comunicación grupal : la comunicación grupal se ocupa de la entrega de

mensajes a un conjunto de destinatarios y, por lo tanto, es un paradigma de comunicación multipartidista
apoyando la comunicación uno a muchos. La comunicación grupal se basa en
abstracción de un grupo que está representado en el sistema por un identificador de grupo.
Página 9
Los destinatarios eligen recibir mensajes enviados a un grupo al unirse al grupo. Remitentes
luego envíe mensajes al grupo a través del identificador de grupo y, por lo tanto, no es necesario
conocer los destinatarios del mensaje. Los grupos también suelen mantener grupos
membresía e incluir mecanismos para hacer frente a las fallas de los miembros del grupo.
Sistemas de publicación y suscripción : muchos sistemas, como el ejemplo de comercio financiero en

El Capítulo 1, puede clasificarse como sistemas de difusión de información en los que una gran
número de productores (o editores) distribuyen elementos de información de interés (eventos)
a un número igualmente grande de consumidores (o suscriptores). Seria complicado
e ineficaz para emplear cualquiera de los paradigmas de comunicación centrales discutidos anteriormente
para este propósito y, por lo tanto, sistemas de publicación-suscripción (a veces también llamados
sistemas distribuidos basados en eventos) han surgido para satisfacer esta importante necesidad [M uhl et
al . 2006]. Todos los sistemas de publicación y suscripción comparten la característica fundamental de proporcionar un
servicio de intermediación que asegura de manera eficiente que la información generada por los productores sea
dirigido a los consumidores que deseen esta información.
Colas de mensajes : mientras que los sistemas de publicación y suscripción ofrecen un estilo de uno a muchos
comunicación, las colas de mensajes ofrecen un servicio punto a punto mediante el cual el productor
Los procesos pueden enviar mensajes a una cola especificada y los procesos de consumidor pueden
recibir mensajes de la cola o ser notificado de la llegada de nuevos mensajes en el
cola. Las colas, por lo tanto, ofrecen una indirecta entre el productor y el consumidor.
Procesos.
Espacios de tupla : los espacios de tupla ofrecen un servicio adicional de comunicación indirecta mediante
apoyar un modelo mediante el cual los procesos pueden colocar elementos arbitrarios de datos estructurados,
llamadas tuplas, en un espacio de tuplas persistente y otros procesos pueden leer o eliminar
tales tuplas del espacio de tuplas especificando patrones de interés. Desde la tupla
el espacio es persistente, no es necesario que los lectores y los escritores existan al mismo tiempo. Este estilo
de programación, también conocida como comunicación generativa, fue introducida por
Gelernter [1985] como paradigma de la programación paralela. Varios distribuidos
También se han desarrollado implementaciones, adoptando un estilo cliente-servidor
implementación o un enfoque peer-to-peer más descentralizado.
Memoria compartida distribuida : los sistemas de memoria compartida distribuida (DSM ) proporcionan una
abstracción para compartir datos entre procesos que no comparten memoria física.
No obstante, a los programadores se les presenta una abstracción familiar de lectura o
escribir estructuras de datos (compartidas) como si estuvieran en sus propios espacios de direcciones locales, por lo tanto
presentando un alto nivel de transparencia en la distribución. La infraestructura subyacente
debe asegurarse de que se proporcione una copia de manera oportuna y también tratar los problemas relacionados
a la sincronización y coherencia de los datos. Una descripción general de los compartidos distribuidos
la memoria se puede encontrar en el Capítulo 6.
Las opciones arquitectónicas discutidas hasta ahora se resumen en la Figura 2.2.
Funciones y responsabilidades • En los procesos de un sistema distribuido, o incluso en los objetos,

componentes o servicios, incluidos los servicios web (pero en aras de la simplicidad utilizamos
el término proceso a lo largo de esta sección): interactúan entre sí para realizar una
actividad, por ejemplo, para apoyar una sesión de chat. Al hacerlo, los procesos adquieren una determinada
roles, y estos roles son fundamentales en el establecimiento de la arquitectura general para ser
Página 10
Figura 2.2 Entidades comunicantes y paradigmas de comunicación
Entidades comunicantes Paradigmas de comunicación

(que esta comunicando) (cómo se comunican)
Orientado al sistema Problema- Interproceso Remoto Indirecto

entidades entidades orientadas comunicación invocación comunicación
Nodos Objetos M ensaje Pedido- Grupo

paso respuesta comunicación
Procesos Componentes
Enchufes RPC Publicar-suscribirse
servicios web
M ultidifusión RM I Colas de mensajes
Espacios de tupla
DSM
adoptado. En esta sección, examinamos dos estilos arquitectónicos derivados del papel de
procesos individuales: cliente-servidor y peer-to-peer.
Cliente-servidor: esta es la arquitectura que se cita con mayor frecuencia cuando los sistemas distribuidos
son discutidos. Históricamente es el más importante y sigue siendo el más
empleado. La figura 2.3 ilustra la estructura simple en la que los procesos asumen los roles
de ser clientes o servidores. En particular, los procesos del cliente interactúan con el servidor individual.
Procesos en equipos host potencialmente separados para acceder a los recursos compartidos.
que ellos manejan.
Los servidores, a su vez, pueden ser clientes de otros servidores, como indica la figura. Para
Por ejemplo, un servidor web es a menudo un cliente de un servidor de archivos local que administra los archivos en
donde se almacenan las páginas web. Los servidores web y la mayoría de los demás servicios de Internet son clientes
del servicio DNS, que traduce los nombres de dominio de Internet a direcciones de red.
Otro ejemplo relacionado con la web se refiere a los motores de búsqueda , que permiten a los usuarios buscar
resúmenes de la información disponible en las páginas web de los sitios de Internet. Estas
Los resúmenes se realizan mediante programas denominados rastreadores web , que se ejecutan en segundo plano en
un sitio de motor de búsqueda que utiliza solicitudes HTTP para acceder a servidores web en Internet.
Por lo tanto, un motor de búsqueda es a la vez un servidor y un cliente: responde a las consultas del navegador.
clientes y ejecuta rastreadores web que actúan como clientes de otros servidores web. En este ejemplo,
las tareas del servidor (responder a las consultas de los usuarios) y las tareas del rastreador (realizar solicitudes a
otros servidores web) son totalmente independientes; hay poca necesidad de sincronizarlos y
pueden ejecutarse al mismo tiempo. De hecho, un motor de búsqueda típico normalmente incluiría muchos
subprocesos de ejecución concurrentes, algunos sirven a sus clientes y otros ejecutan web
rastreadores. En el ejercicio 2.5, se invita al lector a considerar el único problema de sincronización
que surge para un motor de búsqueda concurrente del tipo que se describe aquí.
Página 11
Figura 2.3 Los clientes invocan servidores individuales
Cliente invocación Servidor

invocación
resultado resultado
Servidor
Cliente
Clave:
Proceso: Ordenador:
Peer-to-peer: en esta arquitectura todos los procesos involucrados en una tarea o actividad juegan
roles similares, interactuando cooperativamente como compañeros sin ninguna distinción entre el cliente
y los procesos del servidor o las computadoras en las que se ejecutan. En términos prácticos, todos
Los procesos participantes ejecutan el mismo programa y ofrecen el mismo conjunto de interfaces para cada
otro. Si bien el modelo cliente-servidor ofrece un enfoque directo y relativamente simple a la
el intercambio de datos y otros recursos, escala deficientemente. La centralización del servicio
la prestación y la gestión que implica la colocación de un servicio en una única dirección no
escalar mucho más allá de la capacidad de la computadora que aloja el servicio y el ancho de banda
de sus conexiones de red.
Varias estrategias de ubicación han evolucionado en respuesta a este problema (ver
la discusión de la ubicación a continuación), pero ninguno de ellos aborda el tema fundamental
- la necesidad de distribuir los recursos compartidos de manera mucho más amplia para compartir la
cargas informáticas y de comunicación incurridas en el acceso a ellos entre un mucho más grande
número de computadoras y enlaces de red. La idea clave que condujo al desarrollo de
sistemas peer-to-peer es que la red y los recursos informáticos propiedad de los usuarios de
también se podría utilizar un servicio para respaldar ese servicio. Esto tiene la consecuencia útil
que los recursos disponibles para ejecutar el servicio crezcan con el número de usuarios.
La capacidad de hardware y la funcionalidad del sistema operativo del escritorio actual.
computadoras excede la de los servidores de ayer, y la mayoría están equipadas con
Conexiones de red de banda ancha siempre activas. El objetivo de la arquitectura peer-to-peer es
explotar los recursos (tanto de datos como de hardware) en un gran número de participantes
computadoras para el cumplimiento de una determinada tarea o actividad. Aplicaciones de igual a igual y
Se han construido con éxito sistemas que permiten decenas o cientos de miles de
computadoras para proporcionar acceso a datos y otros recursos que almacenan colectivamente y
gestionar. Uno de los primeros casos fue la aplicación Napster para compartir información digital.
archivos de música. Aunque Napster no era una arquitectura puramente peer-to-peer (y también ganó
notoriedad por razones ajenas a su arquitectura), su demostración de viabilidad ha
resultó en el desarrollo del modelo arquitectónico en muchas direcciones valiosas. A
Una instancia más reciente y ampliamente utilizada es el sistema de intercambio de archivos BitTorrent (discutido en
más profundidad en la Sección 20.6.2).
Pagina 12
Figura 2.4a Arquitectura de igual a igual Figura 2.4b Un servicio proporcionado por varios servidores
Compañero 2
Compañero 1
Servicio
Aplicación
Aplicación
Compartible
objetos
Servidor
Compañero 3 Cliente
Aplicación
Servidor
Cliente
Servidor
Compañeros 4 .... N
La figura 2.4a ilustra la forma de una aplicación de igual a igual. Las aplicaciones son
compuesto por un gran número de procesos de pares que se ejecutan en equipos separados y el
El patrón de comunicación entre ellos depende completamente de los requisitos de la aplicación.
Se comparte una gran cantidad de objetos de datos, una computadora individual contiene solo una pequeña
parte de la base de datos de la aplicación y las cargas de almacenamiento, procesamiento y comunicación
para acceder a los objetos se distribuyen a través de muchas computadoras y enlaces de red. Cada
El objeto se replica en varias computadoras para distribuir aún más la carga y proporcionar
resiliencia en caso de desconexión de equipos individuales (como es inevitable en el
redes grandes y heterogéneas a las que se dirigen los sistemas peer-to-peer). La necesidad de
colocar objetos individuales y recuperarlos y mantener réplicas entre muchos
Las computadoras hacen que esta arquitectura sea sustancialmente más compleja que la del cliente-servidor.
arquitectura.
El desarrollo de aplicaciones peer-to-peer y middleware para soportarlas es
descrito en profundidad en el Capítulo 10.
Colocación • La última cuestión a considerar es cómo entidades como objetos o servicios

mapear en la infraestructura distribuida física subyacente que consistirá en un
potencialmente gran número de máquinas interconectadas por una red de arbitrarias
complejidad. La ubicación es crucial en términos de determinar las propiedades de la distribución
sistema, más obviamente en lo que respecta al rendimiento, pero también a otros aspectos, como
Fiabilidad y seguridad.
La cuestión de dónde colocar un cliente o servidor dado en términos de máquinas y
Los procesos dentro de las máquinas es una cuestión de diseño cuidadoso. La ubicación debe tener en cuenta
cuenta los patrones de comunicación entre entidades, la confiabilidad de
máquinas y su carga actual, la calidad de la comunicación entre diferentes
máquinas y así sucesivamente. La ubicación debe determinarse con un sólido conocimiento de la aplicación,
y existen pocas pautas universales para obtener una solución óptima. Nosotros por lo tanto
centrarse principalmente en las siguientes estrategias de ubicación, que pueden alterar significativamente la
características de un diseño dado (aunque volvemos a la cuestión clave del mapeo para
infraestructura física en la Sección 2.3.2, donde analizamos la arquitectura por niveles):
Página 13
Figura 2.5 Servidor proxy web
Cliente Web
servidor
Apoderado
servidor
Cliente Web
servidor
• mapeo de servicios a múltiples servidores;
• almacenamiento en caché;
• código móvil;
• agentes móviles.
Asignación de servicios a varios servidores: los servicios se pueden implementar como varios servidores
Procesos
procesos endelcomputadoras
cliente (Figurahost separadas
2.4b). que interactúan
Los servidores según el
pueden dividir seaconjunto
necesario
depara proporcionar
objetos en los queun servicio a
el servicio se basa y distribuye esos objetos entre ellos, o pueden mantener
copias replicadas de ellos en varios hosts. Estas dos opciones se ilustran con la
siguientes ejemplos.
La web proporciona un ejemplo común de datos particionados en el que cada web
El servidor gestiona su propio conjunto de recursos. Un usuario puede utilizar un navegador para acceder a un
recurso en cualquiera de los servidores.
Un ejemplo de un servicio basado en datos replicados es Sun Network Information
Service (NIS), que se utiliza para permitir que todas las computadoras en una LAN accedan al mismo
datos de autenticación de usuario cuando los usuarios inician sesión. Cada servidor NIS tiene su propia réplica de un
archivo de contraseña común que contiene una lista de los nombres de inicio de sesión de los usuarios y las contraseñas cifradas.
El capítulo 18 analiza las técnicas de replicación en detalle.
Un tipo de arquitectura de múltiples servidores más estrechamente acoplado es el clúster, como
presentado en el Capítulo 1. Un clúster se construye a partir de hasta miles de productos básicos
placas de procesamiento, y el procesamiento de servicios se puede dividir o replicar entre
ellos.
Almacenamiento en caché: un caché es un almacén de objetos de datos usados recientemente que está más cerca de un cliente o un
un conjunto particular de clientes que los propios objetos. Cuando se recibe un nuevo objeto de
un servidor se agrega al almacén de caché local, reemplazando algunos objetos existentes si es necesario.
Cuando un proceso de cliente necesita un objeto, el servicio de almacenamiento en caché primero verifica el caché
y suministra el objeto desde allí si hay una copia actualizada disponible. Si no, una actualización
se recupera la copia. Los cachés pueden estar ubicados junto con cada cliente o pueden estar ubicados en un
servidor proxy que puede ser compartido por varios clientes.
Los cachés se utilizan ampliamente en la práctica. Los navegadores web mantienen un caché de
páginas web visitadas recientemente y otros recursos web en el sistema de archivos local del cliente, utilizando
una solicitud HTTP especial para verificar con el servidor original que las páginas almacenadas en caché están actualizadas
fecha antes de mostrarlos. Los servidores proxy web (Figura 2.5) proporcionan una caché compartida de
Página 14
Figura 2.6 Subprogramas web
a) la solicitud del cliente da como resultado la descarga del código del subprograma
Cliente Web
servidor
Código de applet
b) el cliente interactúa con el subprograma
Web
Cliente Applet servidor
recursos web para las máquinas cliente en un sitio o en varios sitios. El propósito de
servidores proxy es aumentar la disponibilidad y el rendimiento del servicio al reducir
la carga en la red de área amplia y los servidores web. Los servidores proxy pueden asumir otros roles;
por ejemplo, pueden usarse para acceder a servidores web remotos a través de un firewall.
Código móvil: el capítulo 1 introdujo el código móvil. Los applets son muy conocidos y
ejemplo usado de código móvil: el usuario que ejecuta un navegador selecciona un enlace a un subprograma
cuyo código se almacena en un servidor web; el código se descarga en el navegador y se ejecuta
allí, como se muestra en la Figura 2.6. Una ventaja de ejecutar el código descargado localmente es
que puede dar una buena respuesta interactiva ya que no sufre los retrasos o
variabilidad del ancho de banda asociado con la comunicación de la red.
Acceder a los servicios significa ejecutar código que pueda invocar sus operaciones. Algunos
Es probable que los servicios estén tan estandarizados que podamos acceder a ellos con un
aplicación conocida: la Web es el ejemplo más común de esto, pero incluso allí,
Algunos sitios web utilizan funciones que no se encuentran en los navegadores estándar y requieren la
descarga de código adicional. El código adicional puede, por ejemplo, comunicar
con el servidor. Considere una aplicación que requiere que los usuarios se mantengan actualizados con
cambios a medida que ocurren en una fuente de información en el servidor. Esto no se puede lograr
interacciones normales con el servidor web, que siempre son iniciadas por el cliente. La
La solución es utilizar software adicional que funcione de una manera que a menudo se denomina push
modelo: uno en el que el servidor en lugar del cliente inicia interacciones. Por ejemplo,
un corredor de bolsa puede proporcionar un servicio personalizado para notificar a los clientes de los cambios en el
precios de acciones; para utilizar el servicio, cada cliente tendría que descargar un especial
applet que recibe actualizaciones del servidor del corredor, las muestra al usuario y
tal vez realiza operaciones automáticas de compra y venta desencadenadas por las condiciones establecidas por el
cliente y almacenados localmente en la computadora del cliente.
El código móvil es una amenaza potencial para la seguridad de los recursos locales en el destino.
ordenador. Por lo tanto, los navegadores dan a los applets acceso limitado a los recursos locales,
esquema discutido en la Sección 11.1.1.
Agentes móviles: un agente móvil es un programa en ejecución (que incluye tanto código como datos) que
viaja de una computadora a otra en una red llevando a cabo una tarea en la computadora de alguien
nombre, como la recopilación de información y, finalmente, regresar con los resultados. A
El agente móvil puede hacer muchas invocaciones a los recursos locales en cada sitio que visita, por
Página 15
ejemplo, acceder a las entradas individuales de la base de datos. Si comparamos esta arquitectura con una
cliente estático que realiza invocaciones remotas a algunos recursos, posiblemente transfiriendo grandes
cantidades de datos, hay una reducción en el costo y el tiempo de comunicación a través de la
sustitución de invocaciones remotas por locales.
Los agentes móviles pueden usarse para instalar y mantener software en las computadoras
dentro de una organización o para comparar los precios de productos de varios proveedores
visitando el sitio de cada proveedor y realizando una serie de operaciones de base de datos. Uno de los primeros
ejemplo de una idea similar es el llamado programa de gusano desarrollado en Xerox PARC
[Shoch y Hupp 1982], que fue diseñado para hacer uso de computadoras inactivas con el fin de
realizar cálculos intensivos.
Los agentes móviles (como el código móvil) son una amenaza potencial para la seguridad de los recursos en
computadoras que visitan. El entorno que recibe un agente móvil debe decidir
cuál de los recursos locales se le debe permitir usar, según la identidad del usuario
en cuyo nombre actúa el agente: su identidad debe incluirse de forma segura con
el código y los datos del agente móvil. Además, los propios agentes móviles pueden
vulnerables: es posible que no puedan completar su tarea si se les niega el acceso a la
información que necesitan. Las tareas realizadas por los agentes móviles pueden ser realizadas por otros
medio. Por ejemplo, rastreadores web que necesitan acceder a recursos en servidores web
en Internet funcionan con bastante éxito al realizar invocaciones remotas al servidor
Procesos. Por estas razones, la aplicabilidad de los agentes móviles puede ser limitada.
2.3.2 Patrones arquitectónicos
Los patrones arquitectónicos se basan en los elementos arquitectónicos más primitivos discutidos
anterior y proporcionan estructuras recurrentes compuestas que se ha demostrado que funcionan bien en
dadas las circunstancias. No son necesariamente soluciones completas en sí mismas, sino

ofrecen conocimientos parciales que, cuando se combinan con otros patrones, llevan al diseñador a una
solución para un dominio de problema dado.
Este es un tema extenso y se han identificado muchos patrones arquitectónicos para
sistemas distribuidos. En esta sección, presentamos varios patrones arquitectónicos clave en
sistemas distribuidos, incluidas arquitecturas en capas y en niveles y el concepto relacionado
de clientes ligeros (incluido el mecanismo específico de computación en red virtual). Nosotros
también examinan los servicios web como un patrón arquitectónico y dan indicaciones a otros que
puede ser aplicable en sistemas distribuidos.
Estratificación • El concepto de estratificación es familiar y está estrechamente relacionado con la abstracción.

En un enfoque por capas, un sistema complejo se divide en varias capas, con un
capa dada haciendo uso de los servicios ofrecidos por la capa siguiente. Una capa dada
por lo tanto, ofrece una abstracción de software, con capas superiores que desconocen
detalles de implementación, o de hecho de cualquier otra capa debajo de ellos.
En términos de sistemas distribuidos, esto equivale a una organización vertical de servicios.
en capas de servicio. Un servicio distribuido puede ser proporcionado por uno o más servidores.
procesos, interactuando entre sí y con los procesos del cliente con el fin de mantener un
Visión coherente de los recursos del servicio en todo el sistema. Por ejemplo, una hora de la red
El servicio se implementa en Internet basado en el Protocolo de tiempo de red (NTP) por
Procesos de servidor que se ejecutan en hosts a través de Internet que proporcionan la hora actual a
cualquier cliente que lo solicite y ajuste su versión de la hora actual como consecuencia de
Página 16
Figura 2.7 Capas de servicios de software y hardware en sistemas distribuidos
Aplicaciones, servicios
Middleware
Sistema operativo
Plataforma
Hardware informático y de red
interacciones entre sí. Dada la complejidad de los sistemas distribuidos, a menudo es

útil para organizar dichos servicios en capas. Presentamos una vista común de una capa
arquitectura en la Figura 2.7 y desarrolle esta vista con mayor detalle en los Capítulos 3 a 6.
La figura 2.7 presenta los términos importantes plataforma y middleware , que
definir de la siguiente manera:
• Una plataforma para aplicaciones y sistemas distribuidos consiste en el nivel más bajo
capas de hardware y software. Estas capas de bajo nivel brindan servicios a los
capas por encima de ellos, que se implementan de forma independiente en cada computadora,
llevando la interfaz de programación del sistema a un nivel que facilite
comunicación y coordinación entre procesos. Intel x86 / Windows, Intel
x86 / Solaris, Intel x86 / M ac OS X, Intel x86 / Linux y ARM / Symbian son los principales
ejemplos.
• M iddleware se definió en la Sección 1.5.1 como una capa de software cuyo propósito es
para enmascarar la heterogeneidad y proporcionar un modelo de programación conveniente para
programadores de aplicaciones. El middleware está representado por procesos u objetos en un
conjunto de computadoras que interactúan entre sí para implementar la comunicación y
soporte para compartir recursos para aplicaciones distribuidas. Se ocupa de
proporcionando bloques de construcción útiles para la construcción de componentes de software que
pueden trabajar entre sí en un sistema distribuido. En particular, eleva el nivel
de las actividades de comunicación de los programas de aplicación a través del apoyo de
abstracciones como la invocación de métodos remotos; comunicación entre un grupo
de procesos; notificación de eventos; la partición, colocación y recuperación de
objetos de datos compartidos entre ordenadores que cooperan; la replicación de datos compartidos
objetos; y la transmisión de datos multimedia en tiempo real. Volvemos a esto
tema importante en la Sección 2.3.3 a continuación.
Arquitectura en niveles • Las arquitecturas en niveles son complementarias a las capas. M ientras que
La estratificación se ocupa de la organización vertical de los servicios en capas de abstracción, estratificación
es una técnica para organizar la funcionalidad de una capa determinada y colocar esta funcionalidad en
Página 17
servidores apropiados y, como consideración secundaria, en los nodos físicos. Esto

La técnica se asocia más comúnmente con la organización de aplicaciones y
servicios como en la Figura 2.7 anterior, pero también se aplica a todas las capas de un sistema distribuido
arquitectura.
Examinemos primero los conceptos de arquitectura de dos y tres niveles. A
Para ilustrar esto, considere la descomposición funcional de una aplicación dada, como sigue:
• la lógica de presentación, que se ocupa del manejo de la interacción del usuario y

actualizar la vista de la aplicación tal como se presenta al usuario;
• la lógica de la aplicación, que se ocupa de los detalles específicos de la aplicación

procesamiento asociado con la aplicación (también conocido como lógica de negocios,
aunque el concepto no se limita solo a aplicaciones comerciales);
• la lógica de datos, que se ocupa del almacenamiento persistente de la aplicación,

normalmente en un sistema de gestión de bases de datos.
Ahora, consideremos la implementación de tal aplicación usando cliente-servidor

tecnología. Las soluciones asociadas de dos y tres niveles se presentan juntas para
comparación en la Figura 2.8 (a) y (b), respectivamente.
En la solución de dos niveles, los tres aspectos mencionados anteriormente deben dividirse
en dos procesos, el cliente y el servidor. Esto se hace más comúnmente dividiendo
la lógica de la aplicación, con algunos que residen en el cliente y el resto en el servidor
(aunque también son posibles otras soluciones). La ventaja de este esquema es la baja latencia.
en términos de interacción, con un solo intercambio de mensajes para invocar una operación. La
La desventaja es la división de la lógica de la aplicación a través de un límite de proceso, con la
restricción consecuente sobre qué partes de la lógica pueden invocarse directamente a partir de las cuales
Otra parte.
En la solución de tres niveles, hay un mapeo uno a uno de elementos lógicos a
servidores físicos y, por lo tanto, por ejemplo, la lógica de la aplicación se mantiene en un lugar, que
a su vez, puede mejorar la capacidad de mantenimiento del software. Cada nivel también tiene un bien definido
papel; por ejemplo, el tercer nivel es simplemente una base de datos que ofrece un (potencialmente estandarizado)
interfaz de servicio relacional. El primer nivel también puede ser una interfaz de usuario simple que permita
soporte intrínseco para clientes ligeros (como se explica a continuación). Los inconvenientes son los agregados
la complejidad de administrar tres servidores y también el tráfico de red y la latencia agregados
asociado a cada operación.
Tenga en cuenta que este enfoque se generaliza a soluciones de n niveles (o de varios niveles) donde un
El dominio de aplicación dado se divide en n elementos lógicos, cada uno asignado a un determinado
elemento servidor. Como ejemplo, Wikipedia, el sitio web editable públicamente
enciclopedia, adopta una arquitectura de varios niveles para hacer frente al gran volumen de web
solicitudes (hasta 60.000 solicitudes de página por segundo).
El rol de AJAX: en la Sección 1.6 presentamos AJAX (Asynchronous Javascript y
XM L) como una extensión del estilo estándar de interacción cliente-servidor utilizado en el mundo.
Banda ancha. AJAX satisface la necesidad de una comunicación detallada entre un Javascript
programa front-end que se ejecuta en un navegador web y un programa back-end basado en servidor
que contienen datos que describen el estado de la aplicación. Recapitular, en la web estándar
estilo de interacción un navegador envía una solicitud HTTP a un servidor para una página, imagen o
otro recurso con una URL determinada. El servidor responde enviando una página completa que es
ya sea leído de un archivo en el servidor o generado por un programa, dependiendo del tipo
Página 18
Figura 2.8 Arquitecturas de dos y tres niveles
a)
Computadoras personales
o dispositivos móviles Servidor
Vista de usuario, Solicitud

controles y y gestión de datos
manipulación de datos
Vista de usuario, Solicitud

controles y y gestión de datos
manipulación de datos
T ier 1 El nivel 2
B) Computadoras personales Servidor de aplicaciones

o dispositivos móviles
Servidor de base de datos

Usuario
ver y Solicitud
lógica
control S
Base de datos
gerente
Usuario
ver y Solicitud
control S lógica
T ier 1 El nivel 2 Nivel 3
del recurso se identifica en la URL. Cuando el contenido resultante se recibe en el cliente,

el navegador lo presenta de acuerdo con el método de visualización relevante para su tipo M IM E
( texto / html , imagen / jpg , etc.). Aunque una página web puede estar compuesta por varios elementos de
contenido de diferentes tipos, toda la página está compuesta y presentada por el navegador en
de la manera especificada en su definición de página HTM L.
Este estilo estándar de interacción limita el desarrollo de aplicaciones web.
de varias formas significativas:
• Una vez que el navegador ha emitido una solicitud HTTP para una nueva página web, el usuario
incapaz de interactuar con la página hasta que se reciba el nuevo contenido HTM L y
presentado por el navegador. Este intervalo de tiempo es indeterminado, porque está sujeto
a retrasos en la red y el servidor.
• Para actualizar incluso una pequeña parte de la página actual con datos adicionales de
servidor, se debe solicitar y mostrar una página nueva completa. Esto da como resultado una
respuesta retrasada al usuario, procesamiento adicional tanto en el cliente como en el servidor
y tráfico de red redundante.
Página 19
Figura 2.9 Ejemplo de AJAX: actualizaciones de resultados de fútbol
new Ajax.Request ('scores.php? game = Arsenal: Liverpool',

{onSuccess: updateScore});
función updateScore (solicitud) {

.....
(la solicitud contiene el estado de la solicitud Ajax, incluido el resultado devuelto.
El resultado se analiza para obtener algún texto que dé la puntuación, que se utiliza
para actualizar la parte relevante de la página actual).
.....
}
• El contenido de una página que se muestra en un cliente no se puede actualizar en respuesta a

cambios en los datos de la aplicación almacenados en el servidor.
La introducción de Javascript, una programación multiplataforma y entre navegadores

idioma que se descarga y ejecuta en el navegador, constituyó un primer paso hacia
la eliminación de esas limitaciones. Javascript es un lenguaje de uso general que permite tanto
interfaz de usuario y lógica de la aplicación para ser programado y ejecutado en el contexto de un
ventana del navegador.
AJAX es el segundo paso innovador que se necesitaba para permitir una gran interacción
aplicaciones web para ser desarrolladas e implementadas. Habilita el front-end de Javascript
programas para solicitar nuevos datos directamente de los programas del servidor. Cualquier elemento de datos puede ser
solicitado y la página actual actualizada selectivamente para mostrar los nuevos valores. De hecho, el
El front-end puede reaccionar a los nuevos datos de cualquier forma que sea útil para la aplicación.
M uchas aplicaciones web permiten a los usuarios acceder y actualizar importantes recursos compartidos.
conjuntos de datos que pueden estar sujetos a cambios en respuesta a la entrada de otros clientes o datos
feeds recibidos por un servidor. Requieren un componente de front-end receptivo que se ejecute en
cada navegador del cliente para realizar acciones de la interfaz de usuario, como la selección del menú, pero
también requieren acceso a un conjunto de datos que debe mantenerse en el servidor para permitir el uso compartido. Semejante
Los conjuntos de datos son generalmente demasiado grandes y demasiado dinámicos para permitir el uso de cualquier arquitectura.
basado en la descarga de una copia del estado completo de la aplicación al cliente al inicio
de la sesión de un usuario para su manipulación por parte del cliente.
AJAX es el 'pegamento' que apoya la construcción de tales aplicaciones; proporciona
un mecanismo de comunicación que permite a los componentes de front-end que se ejecutan en un navegador
emitir solicitudes y recibir resultados de los componentes de back-end que se ejecutan en un servidor.
Los clientes emiten solicitudes a través del objeto Javascript XmlHttpRequest , que administra un
Intercambio HTTP (consulte la Sección 1.6) con un proceso de servidor. Debido a que XmlHttpRequest tiene un
API compleja que también depende en cierto modo del navegador, generalmente se accede a través de
una de las muchas bibliotecas de Javascript que están disponibles para apoyar el desarrollo de web
aplicaciones. En la Figura 2.9 ilustramos su uso en el Prototipo . biblioteca de JavaScript js
[ www.prototypejs.org ].
El ejemplo es un extracto de una aplicación web que muestra una página que enumera:
resultados actualizados de partidos de fútbol. Los usuarios pueden solicitar actualizaciones de puntajes para individuos
juegos haciendo clic en la línea correspondiente de la página, que ejecuta la primera línea del
Página 20
Figura 2.10 Clientes ligeros y servidores informáticos
Servidor de cómputo
Dispositivo en red
Delgada Solicitud
La red
Cliente Proceso
ejemplo. El objeto Ajax.Request envía una solicitud HTTP a un programa scores.php

ubicado en el mismo servidor que la página web. El objeto Ajax.Request luego devuelve el control,
Permitir que el navegador continúe respondiendo a otras acciones del usuario en la misma ventana o
otras ventanas. Cuando el programa scores.php ha obtenido la última puntuación, la devuelve
en una respuesta HTTP. A continuación, se reactiva el objeto Ajax.Request ; invoca el
función updateScore (porque es la acción onSuccess ), que analiza el resultado y
inserta la partitura en la posición relevante de la página actual. El resto de la página
permanece inalterado y no se recarga.
Esto ilustra el tipo de comunicación que se usa entre el Nivel 1 y el Nivel 2.
componentes. Aunque Ajax.Request (y el objeto XmlHttpRequest subyacente ) ofrece
comunicación síncrona y asíncrona, la versión asíncrona es
casi siempre se usa porque el efecto en la interfaz de usuario de las respuestas demoradas del servidor
es inaceptable.
Nuestro sencillo ejemplo ilustra el uso de AJAX en una aplicación de dos niveles. en un
aplicación de tres niveles, el componente del servidor ( puntuaciones.php en nuestro ejemplo) enviaría un
solicitud a un componente del administrador de datos (generalmente una consulta SQL a un servidor de base de datos) para
los datos requeridos. Esa solicitud sería sincrónica, ya que no hay razón para regresar.
control al componente del servidor hasta que se satisfaga la solicitud.
El mecanismo AJAX constituye una técnica eficaz para la construcción de
aplicaciones web receptivas en el contexto de la latencia indeterminada de Internet,
y se ha desplegado ampliamente. La aplicación Google M aps [ www.google.com
II ] es un ejemplo sobresaliente. Los mapas se muestran como una matriz de 256 x 256 contiguos
imágenes de píxeles (llamadas mosaicos ). Cuando el mapa se mueve, los mosaicos visibles se reposicionan por
El código Javascript en el navegador y los mosaicos adicionales necesarios para llenar el área visible son
solicitado con una llamada AJAX a un servidor de Google. Se muestran tan pronto como se
recibido, pero el navegador continúa respondiendo a la interacción del usuario mientras se espera.
Clientes ligeros • La tendencia en la computación distribuida es alejar la complejidad

desde el dispositivo del usuario final hacia los servicios en Internet. Esto es más evidente en el
avanzar hacia la computación en la nube (discutido en el Capítulo 1) pero también se puede ver en niveles
arquitecturas, como se discutió anteriormente. Esta tendencia ha suscitado interés en el concepto de
un cliente ligero , que permite el acceso a sofisticados servicios en red, proporcionados, por ejemplo,
por una solución en la nube, con pocas suposiciones o demandas en el dispositivo del cliente. M ás
Específicamente, el término cliente ligero se refiere a una capa de software que admite un sistema basado en ventanas.
interfaz de usuario que es local para el usuario mientras ejecuta programas de aplicación o, más
generalmente, acceder a servicios en una computadora remota. Por ejemplo, Figura 2.10 ilustra
un cliente ligero que accede a un servidor informático a través de Internet. La ventaja de esto
enfoque es que los dispositivos locales potencialmente simples (incluidos, por ejemplo, teléfonos inteligentes
Página 21
y otros dispositivos con recursos limitados) se pueden mejorar significativamente con una plétora de
servicios y capacidades en red. El principal inconveniente de la arquitectura de cliente ligero
se encuentra en actividades gráficas altamente interactivas como CAD y procesamiento de imágenes, donde
los retrasos experimentados por los usuarios se incrementan a niveles inaceptables por la necesidad de
transferir información de imágenes y vectores entre el cliente ligero y la aplicación
proceso, debido a las latencias de la red y del sistema operativo.
Este concepto ha llevado al surgimiento de la computación en red virtual (VNC). Esto
La tecnología fue introducida por primera vez por investigadores de Olivetti y Oracle Research
Laboratorio [Richardson et al. 1998]; el concepto inicial ahora se ha convertido en
implementaciones como RealVNC [ www.realvnc.com ], que es una solución de software,
y Adventiq [ www.adventiq.com ], que es una solución basada en hardware que respalda la
transmisión de eventos de teclado, video y mouse sobre IP (KVM -over-IP). Otro VNC
Las implementaciones incluyen Apple Remote Desktop, TightVNC y Aqua Connect.
El concepto es sencillo, proporcionando acceso remoto al usuario gráfico.
interfaces. En esta solución, un cliente (o visor) VNC interactúa con un servidor VNC a través de
un protocolo VNC. El protocolo opera a un nivel primitivo en términos de soporte de gráficos,
basado en framebuffers y con una operación: la colocación de un rectángulo de píxel
datos en una posición determinada en la pantalla (algunas soluciones, como XenApp de Citrix
operar a un nivel superior en términos de operaciones de ventana [ www.citrix.com ]). Este bajo
El enfoque de nivel asegura que el protocolo funcionará con cualquier sistema operativo o aplicación.
Aunque es sencillo, la implicación es que los usuarios pueden acceder a sus
instalaciones informáticas desde cualquier lugar en una amplia gama de dispositivos, lo que representa una
un paso adelante en la informática móvil.
La computación en red virtual ha reemplazado a las computadoras en red, una
Intentar realizar soluciones de cliente ligero a través de dispositivos de hardware simples y económicos.
que dependen completamente de los servicios en red, descargando su sistema operativo
y cualquier software de aplicación que necesite el usuario desde un servidor de archivos remoto. Dado que todos los
Los datos y el código de la aplicación se almacenan en un servidor de archivos, los usuarios pueden migrar desde un
computadora de la red a otra. En la práctica, la computación en red virtual ha demostrado ser un
solución más flexible y ahora domina el mercado.
Otros patrones que ocurren comúnmente • Como se mencionó anteriormente, una gran cantidad de
Los patrones arquitectónicos ahora se han identificado y documentado. Aquí hay algunas claves
ejemplos:
• El patrón de proxy es un patrón comúnmente recurrente en sistemas distribuidos diseñados

particularmente para apoyar la transparencia de la ubicación en llamadas a procedimientos remotos o remotos
invocación del método. Con este enfoque, se crea un proxy en la dirección local.
espacio para representar el objeto remoto. Este proxy ofrece exactamente la misma interfaz
como el objeto remoto, y el programador realiza llamadas en este objeto proxy y
por lo tanto, no necesita ser consciente de la naturaleza distribuida de la interacción. La
El papel de los apoderados en el apoyo a dicha transparencia de ubicación en RPC y RM I es
discutido con más detalle en el Capítulo 5. Tenga en cuenta que los proxies también se pueden utilizar para encapsular
otras funciones, como las políticas de ubicación de replicación o almacenamiento en caché.
• El uso de corretaje en servicios web puede verse útilmente como una

patrón que admite la interoperabilidad en distribuidas potencialmente complejas
Infraestructuras. En particular, este patrón consta del trío de proveedores de servicios,
Página 22
Figura 2.11 El patrón arquitectónico del servicio web
Servicio
Corredor
Servicio Servicio
Solicitante Proveedor
solicitante de servicios y corredor de servicios (un servicio que coincide con los servicios prestados a
los solicitados), como se muestra en la Figura 2.11 . Este patrón de intermediación se replica en
muchas áreas de sistemas distribuidos, por ejemplo con el registro en Java RM I y
el servicio de nombres en CORBA (como se discutió en los Capítulos 5 y 8, respectivamente).
• La reflexión es un patrón que se utiliza cada vez más en sistemas distribuidos como un
medios de apoyar tanto la introspección (el descubrimiento dinámico de las propiedades de
el sistema) e intercesión (la capacidad de modificar dinámicamente la estructura o
comportamiento). Por ejemplo, se utilizan las capacidades de introspección de Java
eficazmente en la implementación de RM I para proporcionar despacho genérico (como
discutido en la Sección 5.4.2). En un sistema reflectante, las interfaces de servicio estándar son
disponible en el nivel básico, pero también está disponible una interfaz de metanivel que proporciona
acceso a los componentes y sus parámetros que intervienen en la realización del
servicios. En general, hay una variedad de técnicas disponibles en el metanivel,
incluyendo la capacidad de interceptar mensajes entrantes o invocaciones, para
descubrir dinámicamente la interfaz ofrecida por un objeto dado y descubrir y
adaptar la arquitectura subyacente del sistema. La reflexión se ha aplicado en un
variedad de áreas en sistemas distribuidos, particularmente dentro del campo de reflectante
middleware, por ejemplo para admitir más configurables y reconfigurables
arquitecturas de middleware [Kon et al . 2002].
Se pueden encontrar más ejemplos de patrones arquitectónicos relacionados con sistemas distribuidos en
Bushmann y col . [2007].
2.3.3 Soluciones de middleware asociadas
M iddleware ya se introdujo en el Capítulo 1 y se revisó en la discusión de

estratificación en la Sección 2.3.2 anterior. La tarea del middleware es proporcionar un nivel superior
abstracción de programación para el desarrollo de sistemas distribuidos y, a través de
capas, para abstraer la heterogeneidad en la infraestructura subyacente para promover
interoperabilidad y portabilidad. Las soluciones de middleware se basan en la arquitectura
modelos introducidos en la Sección 2.3.1 y también admiten arquitecturas más complejas
Página 23
Figura 2.12 Categorías de middleware
Categorías mayores: Subcategoría Sistemas de ejemplo
Objetos distribuidos (Capítulos 5, 8) Estándar RM-ODP
Plataforma CORBA
Plataforma RMI de Java
Componentes distribuidos (Capítulo 8) Componentes ligeros Fractal
Componentes ligeros OpenCOM
Servidores de aplicaciones SOL EJB
Servidores de aplicaciones Modelo de componente CORBA
Servidores de aplicaciones JBoss
Sistemas de publicación y suscripción (Capítulo 6) - Servicio de eventos CORBA
- Escriba
- JMS
Colas de mensajes (Capítulo 6) - Websphere MQ
- JMS
Servicios web (Capítulo 9) servicios web Eje Apache
Servicios de red El kit de herramientas de Globus
Peer-to-peer (Capítulo 10) Superposiciones de enrutamientoPastelería
Superposiciones de enrutamientoTapiz
Específico de la aplicación Ardilla
Específico de la aplicación OceanStore
Específico de la aplicación Hiedra
Específico de la aplicación Gnutella
patrones. En esta sección, revisamos brevemente las principales clases de middleware que existen.
hoy y preparar el terreno para un estudio más profundo de estas soluciones en el resto del libro.
Categorías de middleware • Paquetes de llamadas a procedimientos remotos como Sun RPC

(Capítulo 5) y los sistemas de comunicación grupal como ISIS (Capítulos 6 y 18) fueron
entre las primeras instancias de middleware. Desde entonces una amplia gama de estilos de
Han surgido middleware, basados en gran parte en los modelos arquitectónicos presentados anteriormente.
Presentamos una taxonomía de tales plataformas de middleware en la Figura 2.12. , incluyendo cruzado
referencias a otros capítulos que cubren las distintas categorías con más detalle. Debe ser
destacó que las categorizaciones no son exactas y que las plataformas de middleware modernas
tienden a ofrecer soluciones híbridas. Por ejemplo, muchas plataformas de objetos distribuidos ofrecen
Servicios de eventos distribuidos para complementar el soporte más tradicional para el método remoto.
invocación. De manera similar, muchas plataformas basadas en componentes (y de hecho otras categorías de
plataforma) también admiten interfaces y estándares de servicios web, por razones de
interoperabilidad. También se debe enfatizar que esta taxonomía no está destinada a ser
completa en términos del conjunto de estándares y tecnologías de middleware disponibles en la actualidad,
Página 24
sino que pretende ser indicativo de las principales clases de middleware. Otro
Las soluciones (no mostradas) tienden a ser más específicas, por ejemplo, ofrecen
paradigmas de comunicación como el paso de mensajes, llamadas a procedimientos remotos, distribuidas
memoria compartida, espacios de tuplas o comunicación grupal.
La categorización de nivel superior de middleware en la Figura 2.12 está impulsada por la elección
de entidades comunicantes y paradigmas de comunicación asociados, y sigue cinco
de los principales modelos arquitectónicos: objetos distribuidos, componentes distribuidos, publicación
suscribir sistemas, colas de mensajes y servicios web. Estos se complementan con
sistemas de pares, una rama bastante separada de middleware basada en la cooperativa
enfoque discutido en la Sección 2.3.1. La subcategoría de componentes distribuidos mostrada
como servidores de aplicaciones también proporciona soporte directo para arquitecturas de tres niveles. En
En particular, los servidores de aplicaciones proporcionan una estructura para soportar una separación entre
la lógica de la aplicación y el almacenamiento de datos, junto con el soporte para otras propiedades como
seguridad y confiabilidad. Se aplazan más detalles hasta el Capítulo 8.
Además de las abstracciones de programación, el middleware también puede proporcionar
Servicios de sistema distribuido de infraestructura para su uso por programas de aplicación u otros
servicios. Estos servicios de infraestructura están estrechamente ligados a la programación distribuida
modelo que proporciona el middleware. Por ejemplo, CORBA (Capítulo 8) proporciona
aplicaciones con una gama de servicios CORBA, incluido el soporte para hacer
aplicaciones seguras y fiables. Como se mencionó anteriormente y se discutió más en el capítulo
8, los servidores de aplicaciones también brindan soporte intrínseco para dichos servicios.
Limitaciones del middleware • M uchas aplicaciones distribuidas dependen completamente de los servicios
proporcionado por middleware para satisfacer sus necesidades de comunicación e intercambio de datos. Para
ejemplo, una aplicación que se adapta al modelo cliente-servidor, como una base de datos de
nombres y direcciones, puede confiar en middleware que solo proporciona un método remoto
invocación.
Se ha logrado mucho en la simplificación de la programación de sistemas distribuidos.
a través del desarrollo de soporte de middleware, pero algunos aspectos de la confiabilidad
de los sistemas requieren soporte a nivel de aplicación.
Considere la transferencia de grandes mensajes de correo electrónico desde el servidor de correo del
remitente a la del destinatario. A primera vista, esta es una simple aplicación de los datos TCP.
protocolo de transmisión (discutido en el Capítulo 3). Pero considere el problema de un usuario que
intenta transferir un archivo muy grande a través de una red potencialmente no confiable. TCP proporciona
algo de detección y corrección de errores, pero no se puede recuperar de la red principal
interrupciones. Por lo tanto, el servicio de transferencia de correo agrega otro nivel de tolerancia a fallas,
mantener un registro de progreso y reanudar la transmisión utilizando un nuevo TCP
conexión si el original se rompe.
Un artículo clásico de Saltzer, Reed y Clarke [Saltzer et al. 1984] hace un similar
y un punto valioso sobre el diseño de sistemas distribuidos, que ellos llaman el
argumento final '. Parafraseando su declaración:
Algunas funciones relacionadas con la comunicación se pueden

implementado solo con el conocimiento y la ayuda de la aplicación que se encuentra en el
puntos finales del sistema de comunicación. Por lo tanto, proporcionar esa función como
característica del sistema de comunicación en sí no siempre es sensible. (Aunque un
La versión incompleta de la función proporcionada por el sistema de comunicación puede
a veces puede resultar útil como mejora del rendimiento).
Página 25
SECCIÓN 2.4 MODELOS FUNDAMENTALES 61
Puede verse que su argumento va en contra de la opinión de que toda comunicación

Las actividades pueden ser abstraídas de la programación de aplicaciones por el
introducción de capas de middleware adecuadas.
El meollo de su argumento es que el comportamiento correcto en programas distribuidos
depende de controles, mecanismos de corrección de errores y medidas de seguridad en muchos
niveles, algunos de los cuales requieren acceso a datos dentro del espacio de direcciones de la aplicación. Alguna
Intentar realizar las comprobaciones dentro del sistema de comunicación solo garantizará
sólo una parte de la corrección requerida. Por lo tanto, es probable que se duplique el mismo trabajo.
en programas de aplicación, desperdiciando esfuerzos de programación y, lo que es más importante, agregando
complejidad innecesaria y cálculos redundantes.
No hay espacio para detallar más sus argumentos aquí, pero leyendo el citado
Se recomienda encarecidamente el papel, que está repleto de ejemplos esclarecedores. Uno de los
autores originales han señalado recientemente que los beneficios sustanciales que
Los argumentos aportados al diseño de Internet corren peligro debido a los recientes movimientos hacia
la especialización de los servicios de red para cumplir con los requisitos actuales de las aplicaciones
[ www.reed.com ].
Este argumento plantea un dilema real para los diseñadores de middleware y, de hecho, el
Las dificultades aumentan dada la amplia gama de aplicaciones (y las asociadas
condiciones ambientales) en los sistemas distribuidos contemporáneos (ver Capítulo 1). En
esencia, el comportamiento correcto del middleware subyacente es una función de los requisitos de
una determinada aplicación o conjunto de aplicaciones y el contexto ambiental asociado, como
como el estado y estilo de la red subyacente. Esta percepción está impulsando el interés en
soluciones adaptativas y sensibles al contexto para middleware, como se analiza en Kon et al [2002].
2.4 Modelos fundamentales
Todos los modelos de sistemas anteriores, bastante diferentes, comparten algunas propiedades fundamentales. En
En particular, todos ellos están compuestos por procesos que se comunican entre sí por
enviar mensajes a través de una red informática. Todos los modelos comparten el diseño
Requisitos para lograr las características de rendimiento y confiabilidad de los procesos.
y redes y garantizar la seguridad de los recursos en el sistema. En esta sección,
Presentar modelos basados en las propiedades fundamentales que nos permitan ser más específicos
sobre sus características y los fallos y riesgos de seguridad que puedan presentar.
En general, un modelo tan fundamental debería contener solo los ingredientes esenciales
que debemos considerar para comprender y razonar sobre algunos aspectos de una
comportamiento del sistema. El propósito de tal modelo es:
• Hacer explícitos todos los supuestos relevantes sobre los sistemas que estamos modelando.
• Hacer generalizaciones sobre lo que es posible o imposible, dados los

supuestos. Las generalizaciones pueden tomar la forma de propósito general.
algoritmos o propiedades deseables que están garantizadas. Las garantías son
dependiente del análisis lógico y, en su caso, de la prueba matemática.
Hay mucho que ganar si se sabe de qué dependen y qué no dependen nuestros diseños.
Nos permite decidir si un diseño funcionará si intentamos implementarlo en un
sistema: solo necesitamos preguntarnos si nuestras suposiciones se mantienen en ese sistema. Además, al hacer
Página 26
Nuestras suposiciones son claras y explícitas, podemos esperar probar las propiedades del sistema usando matemáticas
Técnicas emáticas. Estas propiedades se mantendrán entonces para cualquier sistema que cumpla con nuestra solicitud.
suposiciones. Finalmente, abstrayendo solo las entidades y características esenciales del sistema
lejos de detalles como el hardware, podemos aclarar nuestra comprensión de nuestros sistemas.
Los aspectos de los sistemas distribuidos que deseamos capturar en nuestra
Los modelos están destinados a ayudarnos a discutir y razonar sobre:
Interacción : la computación ocurre dentro de los procesos; los procesos interactúan pasando
mensajes, lo que resulta en comunicación (flujo de información) y coordinación
(sincronización y ordenamiento de actividades) entre procesos. En el análisis y
diseño de sistemas distribuidos nos preocupan especialmente estas interacciones.
El modelo de interacción debe reflejar los hechos de que la comunicación tiene lugar con
retrasos que a menudo son de considerable duración, y que la precisión con la que
los procesos independientes pueden ser coordinados está limitado por estos retrasos y por la
dificultad de mantener la misma noción de tiempo en todas las computadoras en un
Sistema distribuido.
Fallo : el funcionamiento correcto de un sistema distribuido se ve amenazado cuando se produce un fallo

ocurre en cualquiera de las computadoras en las que se ejecuta (incluidas las fallas de software) o en el
red que los conecta. Nuestro modelo define y clasifica las fallas. Esto
proporciona una base para el análisis de sus efectos potenciales y para el diseño de sistemas
que son capaces de tolerar fallas de cada tipo mientras continúan funcionando correctamente.
Seguridad : la naturaleza modular de los sistemas distribuidos y su apertura expone

que los ataquen tanto por agentes externos como internos. Nuestro modelo de seguridad define y
clasifica las formas que pueden adoptar tales ataques, proporcionando una base para el análisis de
amenazas a un sistema y para el diseño de sistemas que sean capaces de resistirlas.
Como ayuda para la discusión y el razonamiento, los modelos presentados en este capítulo son
necesariamente simplificado, omitiendo gran parte de los detalles de los sistemas del mundo real. Su
relación con los sistemas del mundo real, y la solución en ese contexto de los problemas que
los modelos ayudan a resaltar, es el tema principal de este libro.
2.4.1 Modelo de interacción
La discusión de las arquitecturas de sistemas en la Sección 2.3 indica que fundamentalmente

Los sistemas distribuidos se componen de muchos procesos que interactúan de manera compleja. Para
ejemplo:
• Varios procesos de servidor pueden cooperar entre sí para proporcionar un servicio; la

Los ejemplos mencionados anteriormente fueron el Sistema de nombres de dominio, que particiones y
replica sus datos en servidores a través de Internet y Sun's Network
Servicio de información, que mantiene copias replicadas de archivos de contraseñas en varios
servidores en una red de área local.
• Un conjunto de procesos de pares pueden cooperar entre sí para lograr un

objetivo: por ejemplo, un sistema de conferencias de voz que distribuye flujos de audio
datos de manera similar, pero con estrictas restricciones en tiempo real.
La mayoría de los programadores estarán familiarizados con el concepto de algoritmo : una secuencia de
pasos a seguir para realizar un cálculo deseado. Los programas simples son
Página 27
controlado por algoritmos en los que los pasos son estrictamente secuenciales. El comportamiento del
programa y el estado de las variables del programa está determinado por ellos. Tal programa
se ejecuta como un solo proceso. Sistemas distribuidos compuestos por múltiples procesos
como los descritos anteriormente son más complejos. Su comportamiento y estado pueden ser
descrito por un algoritmo distribuido - una definición de los pasos que debe seguir cada uno de los
Procesos de los que se compone el sistema, incluida la transmisión de mensajes.
entre ellos . Los mensajes se transmiten entre procesos para transferir información
entre ellos y para coordinar su actividad.
La velocidad a la que avanza cada proceso y el tiempo de transmisión de
los mensajes entre ellos no se pueden predecir en general. También es difícil describir todos
los estados de un algoritmo distribuido, porque debe lidiar con las fallas de uno o más
de los procesos involucrados o el fallo de la transmisión de mensajes.
Los procesos interactivos realizan toda la actividad en un sistema distribuido. Cada
el proceso tiene su propio estado, que consiste en el conjunto de datos a los que puede acceder y actualizar,
incluyendo las variables en su programa. El estado que pertenece a cada proceso es completamente
privado: es decir, ningún otro proceso puede acceder a él ni actualizarlo.
En esta sección, discutimos dos factores importantes que afectan los procesos que interactúan.
en un sistema distribuido:
• El desempeño de la comunicación es a menudo una característica limitante.
• Es imposible mantener una noción global única de tiempo.
Desempeño de los canales de comunicación • Los canales de comunicación en nuestro modelo
se realizan de diversas formas en sistemas distribuidos, por ejemplo, mediante un
implementación de flujos o mediante un simple mensaje que pasa a través de una red informática.
La comunicación a través de una red informática tiene las siguientes características de rendimiento
en relación con la latencia, el ancho de banda y la fluctuación:
• La demora entre el inicio de la transmisión de un mensaje de un proceso y el

el comienzo de su recepción por otro se denomina latencia . La latencia incluye:
- El tiempo que tarda el primero de una cadena de bits transmitidos a través de una red
llegar a su destino. Por ejemplo, la latencia para la transmisión de un
mensaje a través de un enlace satelital es el momento para que una señal de radio viaje al
satélite y espalda.
- El retraso en el acceso a la red, que aumenta significativamente cuando el

la red está muy cargada. Por ejemplo, para la transmisión Ethernet, el envío
la estación espera a que la red esté libre de tráfico.
- El tiempo que tardan los servicios de comunicación del sistema operativo en

los procesos de envío y recepción, que varía según la carga actual
en los sistemas operativos.
• El ancho de banda de una red informática es la cantidad total de información que puede
transmitirse sobre él en un tiempo determinado. Cuando una gran cantidad de comunicaciones
Los canales utilizan la misma red, tienen que compartir el ancho de banda disponible.
• Jitter es la variación en el tiempo necesario para entregar una serie de mensajes. El jitter es
relevante para los datos multimedia. Por ejemplo, si se muestran muestras consecutivas de datos de audio
reproducido con diferentes intervalos de tiempo, el sonido se distorsionará mucho.
Página 28
Relojes de computadora y eventos de temporización • Cada computadora en un sistema distribuido tiene su propia
reloj interno, que puede ser utilizado por procesos locales para obtener el valor de la corriente
hora. Por lo tanto, dos procesos que se ejecutan en diferentes computadoras pueden asociarse
marcas de tiempo con sus eventos. Sin embargo, incluso si los dos procesos leen sus relojes en el
Al mismo tiempo, sus relojes locales pueden proporcionar diferentes valores de tiempo. Esto se debe a que la computadora
Los relojes se desvían del tiempo perfecto y, lo que es más importante, sus velocidades de desplazamiento difieren de uno.
otro. El término tasa de desviación del reloj se refiere a la tasa a la que se desvía el reloj de una computadora
de un reloj de referencia perfecto. Incluso si los relojes de todas las computadoras en un
El sistema está configurado a la misma hora inicialmente, sus relojes eventualmente variarán bastante
significativamente a menos que se apliquen correcciones.
Existen varios enfoques para corregir los tiempos en los relojes de las computadoras. Para
Por ejemplo, las computadoras pueden usar receptores de radio para obtener lecturas de tiempo del Global
Sistema de posicionamiento con una precisión de aproximadamente 1 microsegundo. Pero los receptores GPS no
operan dentro de edificios, ni se puede justificar el costo de cada computadora. En cambio, un
computadora que tiene una fuente de tiempo precisa, como GPS, puede enviar mensajes de tiempo a
otras computadoras en su red. El acuerdo resultante entre los tiempos en el local
Los relojes se ven afectados, por supuesto, por retrasos variables en los mensajes. Para una discusión más detallada
de la deriva del reloj y la sincronización del reloj, consulte el Capítulo 14.
Dos variantes del modelo de interacción • En un sistema distribuido es difícil establecer límites en
el tiempo que se puede tomar para la ejecución del proceso, la entrega de mensajes o la desviación del reloj. Dos
posiciones extremas opuestas proporcionan un par de modelos simples: el primero tiene una fuerte
suposición de tiempo y el segundo no hace suposiciones sobre el tiempo:
Sistemas distribuidos síncronos : Hadzilacos y Toueg [1994] definen un

sistema distribuido síncrono para ser uno en el que se definen los siguientes límites:
• El tiempo para ejecutar cada paso de un proceso tiene límites superior e inferior conocidos.
• Cada mensaje transmitido a través de un canal se recibe dentro de un límite conocido.

hora.
• Cada proceso tiene un reloj local cuya tasa de deriva del tiempo real tiene un conocido
atado.
Es posible sugerir límites superiores e inferiores probables para el tiempo de ejecución del proceso,
Retraso de mensajes y tasas de desviación del reloj en un sistema distribuido, pero es difícil llegar
en valores realistas y para proporcionar garantías de los valores elegidos. A menos que los valores
de los límites se puede garantizar, cualquier diseño basado en los valores elegidos no será
de confianza. Sin embargo, modelar un algoritmo como un sistema síncrono puede ser útil
por dar una idea de cómo se comportará en un sistema distribuido real. en un
sistema síncrono es posible utilizar tiempos de espera, por ejemplo, para detectar el fallo
de un proceso, como se muestra en la Sección 2.4.2 a continuación.
Se pueden construir sistemas distribuidos síncronos. Lo que se requiere es para
procesos para realizar tareas con requisitos de recursos conocidos para los que pueden ser
garantizado suficientes ciclos de procesador y capacidad de red, y para que los procesos sean
Suministrado con relojes con tasas de deriva limitadas.
Página 29
Sistemas distribuidos asincrónicos : muchos sistemas distribuidos, como Internet,

son muy útiles sin poder calificar como sistemas síncronos. Por lo tanto, nosotros
Necesito un modelo alternativo. Un sistema distribuido asincrónico es aquel en el que hay
no hay límites en:
• Velocidades de ejecución del proceso: por ejemplo, un paso del proceso puede tomar solo un
picosegundo y otro siglo; todo lo que se puede decir es que cada paso puede llevar
un tiempo arbitrariamente largo.
• Retrasos en la transmisión de mensajes: por ejemplo, un mensaje del proceso A al
El proceso B puede entregarse en un tiempo insignificante y otro puede llevar varios
años. En otras palabras, un mensaje puede recibirse después de un tiempo arbitrariamente largo.
• Tasas de deriva del reloj: de nuevo, la tasa de deriva de un reloj es arbitraria.
El modelo asincrónico no permite suposiciones sobre los intervalos de tiempo involucrados en

cualquier ejecución. Esto es exactamente el modelo de Internet, en el que no existe un límite intrínseco.
en la carga del servidor o de la red y, por lo tanto, en cuánto tiempo lleva, por ejemplo, transferir
un archivo mediante FTP. A veces, un mensaje de correo electrónico puede tardar días en llegar. La caja en
esta página ilustra la dificultad de llegar a un acuerdo en un sistema asincrónico
Sistema distribuido.
Pero algunos problemas de diseño se pueden resolver incluso con estos supuestos. Para
Por ejemplo, aunque la Web no siempre puede proporcionar una respuesta particular dentro de un
límite de tiempo razonable, los navegadores se han diseñado para permitir a los usuarios hacer otras cosas
mientras esperan. Cualquier solución que sea válida para un distribuido asincrónico
El sistema también es válido para uno sincrónico.
Los sistemas distribuidos reales son muy a menudo asincrónicos debido a la necesidad de
procesos para compartir los procesadores y para los canales de comunicación para compartir el
Acuerdo en Pepperland • Dos divisiones del ejército de Pepperland, 'Apple' y

'Orange', están acampados en la cima de dos colinas cercanas. M ás a lo largo del valle de abajo
son los invasores Blue M eanies. Las divisiones de Pepperland están a salvo siempre que
permanecen en sus campamentos, y pueden enviar mensajeros de manera confiable a través del
valle para comunicarse. Las divisiones de Pepperland deben ponerse de acuerdo sobre cuál de ellas
liderará la carga contra los Blue M eanies y cuándo se llevará a cabo la carga.
Incluso en un Pepperland asincrónico, es posible ponerse de acuerdo sobre quién dirigirá el
cargo. Por ejemplo, cada división puede enviar el número de sus miembros restantes,
y el que tenga más liderará (si hay un empate, la división Apple gana sobre Orange). Pero cuando
¿Deberían cobrar? Desafortunadamente, en Pepperland asincrónico, los mensajeros son
muy variable en su velocidad. Si, por ejemplo, Apple envía un mensajero con el mensaje
"¡Carga!", Es posible que Orange no reciba el mensaje durante, digamos, tres horas; o puede tomar,
digamos, cinco minutos para llegar. En un Pepperland sincrónico, todavía hay una coordinación
problema, pero las divisiones conocen algunas limitaciones útiles: cada mensaje toma al menos
minutos min y como máximo minutos max para llegar. Si la división que liderará el
charge envía un mensaje 'Charge!', espera min minutos; luego carga. El otro
la división espera 1 minuto después de recibir el mensaje y luego carga. Su cargo es
garantizado para estar después de la división líder, pero no más de ( max - min + 1)
minutos después.
Página 30
Figura 2.13 Orden de eventos en tiempo real
enviar recibir recibir

X
1 m1 4
m2
enviar
2 recibir Físico
3
Y
recibir hora
enviar
Z
recibir recibir
m3 m1 m2
A
recibir recibir recibir
t1 t2 t3
la red. Por ejemplo, si demasiados procesos de carácter desconocido comparten un

procesador, entonces no se puede garantizar el rendimiento resultante de cualquiera de ellos.
Pero hay muchos problemas de diseño que no se pueden resolver para un sistema asincrónico.
sistema que puede resolverse cuando se utilizan algunos aspectos del tiempo. La necesidad de cada
elemento de un flujo de datos multimedia que se entregará antes de una fecha límite es un
problema. Para problemas como estos, se requiere un modelo sincrónico.
Orden de eventos • En muchos casos, nos interesa saber si un evento

(enviar o recibir un mensaje) en un proceso ocurrido antes, después o al mismo tiempo
con otro evento en otro proceso. La ejecución de un sistema se puede describir en
términos de los eventos y su orden a pesar de la falta de relojes precisos.
Por ejemplo, considere el siguiente conjunto de intercambios entre un grupo de correo electrónico
usuarios, X, Y, Z y A, en una lista de correo:
1. El usuario X envía un mensaje con el asunto Reunión .
2. Los usuarios Y y Z responden enviando un mensaje con el asunto Re: Reunión .
En tiempo real, el mensaje de X se envía primero, Y lo lee y responde; Z luego lee ambas X
mensaje y la respuesta de Y y envía otra respuesta, que hace referencia tanto a X como a Y
mensajes. Pero debido a los retrasos independientes en la entrega de mensajes, los mensajes pueden ser
entregado como se muestra en la Figura 2.13
, y algunos usuarios pueden ver estos dos mensajes en el
orden incorrecto. Por ejemplo, el usuario A puede ver :
Bandeja de entrada:
Artículo De Sujeto
23 Z Re: reunión
24 X Reunión
25 Y Re: reunión
Página 31
Si los relojes de las computadoras X, Y y Z pueden sincronizarse, entonces cada mensaje

podría llevar la hora en el reloj de la computadora local cuando se envió. Por ejemplo,
los mensajes m 1 , m 2 y m 3 llevarían los tiempos t 1 , t 2 y t 3 donde t 1 < t 2 < t 3 . Los mensajes
recibidos se mostrarán a los usuarios de acuerdo con su orden de tiempo. Si los relojes son
aproximadamente sincronizados, estas marcas de tiempo a menudo estarán en el orden correcto.
Dado que los relojes no se pueden sincronizar perfectamente en un sistema distribuido,
Lamport [1978] propuso un modelo de tiempo lógico que se puede utilizar para proporcionar una ordenación
entre los eventos en los procesos que se ejecutan en diferentes computadoras en un sistema distribuido.
El tiempo lógico permite inferir el orden en el que se presentan los mensajes sin
recurso a los relojes. Se presenta en detalle en el Capítulo 14, pero aquí sugerimos cómo algunos
Los aspectos del orden lógico se pueden aplicar a nuestro problema de pedidos por correo electrónico.
Lógicamente, sabemos que se recibe un mensaje después de su envío. Por lo tanto podemos
establecer un orden lógico para los pares de eventos que se muestran en la Figura 2.13, por ejemplo,
considerando solo los eventos relacionados con X e Y:
X envía m 1 antes de que Y reciba m 1 ; Y envía m 2 antes de que X reciba m 2 .
También sabemos que las respuestas se envían después de recibir mensajes, por lo que tenemos lo siguiente
ordenamiento lógico para Y:
Y recibe m 1 antes de enviar m 2 .
El tiempo lógico lleva esta idea más allá al asignar un número a cada evento correspondiente
a su ordenamiento lógico, de modo que los eventos posteriores tengan números más altos que los anteriores. Para
Por ejemplo, la Figura 2.13 muestra los números del 1 al 4 en los eventos en X e Y.
2.4.2 Modelo de falla
En un sistema distribuido, tanto los procesos como los canales de comunicación pueden fallar, es decir,
pueden apartarse de lo que se considera un comportamiento correcto o deseable. La falla
El modelo define las formas en las que puede ocurrir una falla con el fin de proporcionar una comprensión
de los efectos de las fallas. Hadzilacos y Toueg [1994] proporcionan una taxonomía que
distingue entre las fallas de los procesos y los canales de comunicación. Estos son
presentado bajo los encabezados fallas por omisión, fallas arbitrarias y fallas en el tiempo.
El modelo de falla se utilizará a lo largo del libro. Por ejemplo:
• En el Capítulo 4, presentamos las interfaces Java para datagramas y flujos.

comunicación, que proporcionan distintos grados de fiabilidad.
• El Capítulo 5 presenta el protocolo de solicitud-respuesta, que admite RM I. Su fracaso

Las características dependen de las características de falla de ambos procesos y
canales de comunicación. El protocolo se puede construir a partir de un datagrama o
flujo de comunicación. La elección puede decidirse de acuerdo con una consideración
de simplicidad de implementación, desempeño y confiabilidad.
• El Capítulo 17 presenta el protocolo de compromiso de dos fases para transacciones. Esta diseñado
para completar frente a fallas bien definidas de procesos y comunicación
canales.
Fallos por omisión • Los fallos clasificados como fallos por omisión se refieren a casos en los que un
El proceso o el canal de comunicación no realiza las acciones que se supone que debe realizar.
Página 32
Fallos por omisión del proceso: el principal fallo por omisión de un proceso es que se bloquee. Cuando nosotros
decir que un proceso se ha bloqueado, queremos decir que se ha detenido y no se ejecutará más.
pasos de su programa nunca. El diseño de servicios que puedan sobrevivir en presencia de fallas.
puede simplificarse si se puede suponer que los servicios de los que dependen fallan
limpiamente, es decir, sus procesos funcionan correctamente o se detienen. Otros procesos
puede ser capaz de detectar un bloqueo de este tipo por el hecho de que el proceso no responde repetidamente
a los mensajes de invocación. Sin embargo, este método de detección de accidentes se basa en el uso de
tiempos de espera - es decir, un método en el que un proceso permite un período de tiempo fijo para
algo que ocurra. En un sistema asincrónico, un tiempo de espera puede indicar solo que un
El proceso no responde: puede que se haya bloqueado o sea lento, o los mensajes pueden
no han llegado.
Una caída de proceso se denomina parada por falla si otros procesos pueden detectar con certeza que el
el proceso se ha bloqueado. Se puede producir un comportamiento de parada por falla en un sistema síncrono si el
Los procesos utilizan tiempos de espera para detectar cuando otros procesos no responden y los mensajes se
garantizado para ser entregado. Por ejemplo, si los procesos de p y q se programan para q a
responder a un mensaje de p , y si el proceso p no ha recibido respuesta del proceso q en un
tiempo máximo medido en p ‘es reloj local, entonces el proceso p puede concluir que el proceso
q ha fallado. El recuadro de enfrente ilustra la dificultad de detectar fallas en un
sistema asincrónico o de llegar a un acuerdo en presencia de fallas.
Fallos de omisión de comunicación: considere las primitivas de comunicación que envían y

recibir . Un proceso p realiza un envío insertando el mensaje m en su mensaje saliente
buffer. El canal de comunicación transporta el búfer de mensajes entrantes de m a q .
El proceso q realiza una recepción tomando m de su búfer de mensajes entrantes y
entregarlo (ver Figura 2.14). Los búferes de mensajes entrantes y salientes son típicamente
proporcionado por el sistema operativo.
El canal de comunicación produce una falla por omisión si no transporta
un mensaje del búfer de mensajes salientes de p al búfer de mensajes entrantes de q . Esto es
conocido como 'dejar caer mensajes' y generalmente es causado por la falta de espacio de búfer en el
receptor o en una puerta de enlace intermedia, o por un error de transmisión de red, detectado por un
suma de control llevada con los datos del mensaje. Hadzilacos y Toueg [1994] se refieren a la pérdida
de mensajes entre el proceso de envío y el búfer de mensaje saliente como Enviar-
fallas de omisión , a la pérdida de mensajes entre el búfer de mensajes entrantes y el
proceso de recepción como fallas por omisión de recepción , y a la pérdida de mensajes en el medio como
fallas de omisión de canal . Las fallas por omisión se clasifican junto con las arbitrarias.
fallas en la Figura 2.15.
Las fallas se pueden clasificar según su gravedad. Todos los fracasos que tenemos
descritos hasta ahora son fracasos benignos . La mayoría de las fallas en los sistemas distribuidos son benignas.
Las fallas benignas incluyen fallas por omisión, así como fallas de tiempo y desempeño.
fracasos.
Fallos arbitrarios • El término fallo arbitrario o bizantino se utiliza para describir lo peor
posible semántica de falla, en la que puede ocurrir cualquier tipo de error. Por ejemplo, un proceso
puede establecer valores incorrectos en sus elementos de datos, o puede devolver un valor incorrecto en respuesta a un
invocación.
Un fallo arbitrario de un proceso es aquel en el que omite arbitrariamente el
pasos de procesamiento o toma pasos de procesamiento no deseados. Fallos arbitrarios en los procesos
Página 33
Figura 2.14 Procesos y canales
proceso p proceso q
enviar metro recibir
Canal de comunicación
Búfer de mensajes salientes Búfer de mensajes entrantes
no se puede detectar al ver si el proceso responde a las invocaciones, porque

podría omitir arbitrariamente la respuesta.
Los canales de comunicación pueden sufrir fallos arbitrarios; por ejemplo, mensaje
el contenido puede estar dañado, pueden entregarse mensajes inexistentes o mensajes reales
puede entregarse más de una vez. Las fallas arbitrarias de los canales de comunicación son raras
Detección de fallas • En el caso de las divisiones de Pepperland acampadas en la parte superior de

colinas (véase la página 65), supongamos que los Blue M eanies son, después de todo, suficiente fuerza
atacar y derrotar a cualquiera de las divisiones mientras están acampadas, es decir, que cualquiera de las dos puede fallar.
Supongamos además que, aunque invictas, las divisiones envían regularmente mensajeros a
informar su estado. En un sistema asincrónico, ninguna división puede distinguir
si el otro ha sido derrotado o el tiempo que tardan los mensajeros en cruzar
el valle intermedio es muy largo. En un Pepperland sincrónico, una división puede
diga con certeza si el otro ha sido derrotado por la ausencia de un mensajero regular.
Sin embargo, la otra división puede haber sido derrotada justo después de enviar la última
M ensajero.
Imposibilidad de llegar a un acuerdo oportuno en presencia de comunicación.

fallas • Hemos asumido que los mensajeros de Pepperland siempre manejan
cruzar el valle eventualmente; pero ahora supongamos que los Blue M eanies pueden capturar cualquier
mensajero y evitar que lleguen. (Asumiremos que es imposible que el
Blue M eanies para lavar el cerebro a los mensajeros para dar el mensaje equivocado - the M eanies
no son conscientes de sus traicioneros precursores bizantinos.) ¿Pueden la manzana y la naranja
divisiones envían mensajes para que ambos decidan constantemente cargar al
¿Los malvados o ambos deciden rendirse? Desafortunadamente, como el teórico de Pepperland
Ringo el Grande demostró que en estas circunstancias las divisiones no pueden garantizar
decidir constantemente qué hacer. Para ver esto, suponga lo contrario que las divisiones
ejecutar un protocolo de Pepperland que logre un acuerdo. Cada uno propone '¡Carga!' o
'¡Ríndete!', Y el protocolo da como resultado que ambos estén de acuerdo en uno u otro curso
de acción. Ahora considere el último mensaje enviado en cualquier ejecución del protocolo. La
mensajero que lo lleva podría ser capturado por los Blue M eanies, por lo que el resultado final
debe ser el mismo tanto si el mensaje llega como si no. Podemos prescindir de eso. Ahora
podemos aplicar el mismo argumento al mensaje final que queda. Pero este argumento
se aplica nuevamente a ese mensaje y continuará aplicándose, por lo que terminaremos sin
mensajes enviados en absoluto! Esto demuestra que ningún protocolo que garantice el acuerdo entre
las divisiones de Pepperland pueden existir si se pueden capturar mensajeros.
Página 34
Figura 2.15 Omisión y fallas arbitrarias
Clase de falla Afecta Descripción
Parada de emergencia Proceso El proceso se detiene y permanece detenido. Otros procesos pueden
detectar este estado.
Choque Proceso El proceso se detiene y permanece detenido. Otros procesos pueden

no poder detectar este estado.
Omisión Canal Un mensaje insertado en un búfer de mensajes salientes

nunca llega al mensaje entrante del otro extremo
buffer.
Enviar-omisión Proceso Un proceso completa una operación de envío pero el mensaje

no se coloca en su búfer de mensajes salientes.
Recibir- Proceso Un mensaje se coloca en el mensaje entrante de un proceso

omisión búfer, pero ese proceso no lo recibe.
Arbitrario Proceso El proceso / canal muestra un comportamiento arbitrario: puede

(Bizantino) o enviar / transmitir mensajes arbitrarios en momentos arbitrarios o
canal cometer omisiones; un proceso puede detenerse o tomar un
paso incorrecto.
porque el software de comunicación es capaz de reconocerlos y rechazar los defectuosos

mensajes. Por ejemplo, las sumas de comprobación se utilizan para detectar mensajes corruptos y mensajes
Los números de secuencia se pueden utilizar para detectar mensajes duplicados o inexistentes.
Fallos de temporización • Los fallos de temporización son aplicables en sistemas distribuidos síncronos
donde los límites de tiempo se establecen en el tiempo de ejecución del proceso, el tiempo de entrega de mensajes y el reloj
tasa de deriva. Las fallas de tiempo se enumeran en la Figura 2.16. Cualquiera de estas fallas puede resultar
en las respuestas que no están disponibles para los clientes dentro de un intervalo de tiempo especificado.
En un sistema distribuido asincrónico, un servidor sobrecargado también puede responder
lentamente, pero no podemos decir que tenga una falla de tiempo ya que no se ha ofrecido garantía.
Los sistemas operativos en tiempo real están diseñados con miras a proporcionar tiempo
garantías, pero son más complejas de diseñar y pueden requerir hardware redundante.
La mayoría de los sistemas operativos de propósito general, como UNIX, no tienen que cumplir
limitaciones.
La sincronización es particularmente relevante para las computadoras multimedia con audio y video.
canales. La información de video puede requerir la transferencia de una gran cantidad de datos.
La entrega de dicha información sin fallas de tiempo puede generar demandas muy especiales en
tanto el sistema operativo como el sistema de comunicación.
Enmascaramiento de fallas • Cada componente de un sistema distribuido generalmente se construye

de una colección de otros componentes. Es posible construir servicios confiables a partir de
componentes que presentan fallas. Por ejemplo, varios servidores que contienen réplicas de datos
puede continuar brindando un servicio cuando uno de ellos falla. Un conocimiento del fracaso
Las características de un componente pueden permitir diseñar un nuevo servicio para enmascarar la
Página 35
Figura 2.16 Fallas de tiempo
Clase de falla Afecta Descripción
Reloj Proceso El reloj local del proceso supera los límites de

su tasa de deriva del tiempo real.
Actuación Proceso El proceso excede los límites del intervalo

entre dos escalones.
Actuación Canal La transmisión de un mensaje tarda más de

el límite declarado.
Fallo de los componentes de los que depende. Un servicio enmascara un fallo ocultándose
por completo o convirtiéndolo en un tipo de falla más aceptable. Para un ejemplo
de este último, las sumas de comprobación se utilizan para enmascarar mensajes corruptos, convirtiendo efectivamente un
falla arbitraria en falla por omisión. Veremos en los capítulos 3 y 4 que la omisión
Las fallas se pueden ocultar mediante el uso de un protocolo que retransmite mensajes que no llegan a
su destino. El capítulo 18 presenta el enmascaramiento mediante replicación. Incluso proceso
los bloqueos pueden enmascararse, reemplazando el proceso y restaurando su memoria de
información almacenada en disco por su predecesor.
Fiabilidad de la comunicación uno a uno • Aunque es un canal de comunicación básico

puede exhibir las fallas de omisión descritas anteriormente, es posible usarlo para construir un
servicio de comunicación que enmascara algunas de esas fallas.
El término comunicación confiable se define en términos de validez e integridad como
sigue:
Validez : Cualquier mensaje en el búfer de mensajes salientes finalmente se entrega al

búfer de mensajes entrantes.
Integridad : el mensaje recibido es idéntico al enviado y no se

entregado dos veces.
Las amenazas a la integridad provienen de dos fuentes independientes:
• Cualquier protocolo que retransmite mensajes pero no rechaza un mensaje que llega
dos veces. Los protocolos pueden adjuntar números de secuencia a los mensajes para detectarlos.
que se entregan dos veces.
• Usuarios malintencionados que pueden inyectar mensajes falsos, reproducir mensajes antiguos o alterar
con mensajes. Se pueden tomar medidas de seguridad para mantener la propiedad de integridad.
ante tales ataques.
2.4.3 Modelo de seguridad

En el Capítulo 1 identificamos el intercambio de recursos como un factor motivador para distribuir

sistemas, y en la Sección 2.3 describimos su arquitectura en términos de procesos,
potencialmente encapsulando abstracciones de alto nivel como objetos, componentes o
Página 36
Figura 2.17 Objetos y principios
Derechos de acceso
Objeto
invocación
Cliente
resultado Servidor
Principal (usuario) La red Principal (servidor)
servicios y proporcionar acceso a ellos a través de interacciones con otros procesos. Que
El modelo arquitectónico proporciona la base para nuestro modelo de seguridad:
la seguridad de un sistema distribuido se puede lograr asegurando los procesos y la

canales utilizados para sus interacciones y protegiendo los objetos que
encapsular contra el acceso no autorizado.
La protección se describe en términos de objetos, aunque los conceptos se aplican igualmente bien a
recursos de todo tipo.
Protección de objetos • La Figura 2.17 muestra un servidor que administra una colección de objetos en
en nombre de algunos usuarios. Los usuarios pueden ejecutar programas cliente que envían invocaciones al
servidor para realizar operaciones en los objetos. El servidor realiza la operación
especificado en cada invocación y envía el resultado al cliente.
Los objetos están destinados a ser utilizados de diferentes formas por diferentes usuarios. Por ejemplo,
Algunos objetos pueden contener datos privados de un usuario, como su buzón de correo y otros objetos.
puede contener datos compartidos como páginas web. Para respaldar esto, los derechos de acceso especifican quién es
se le permite realizar las operaciones de un objeto, por ejemplo, a quién se le permite leer o
para escribir su estado.
Por tanto, debemos incluir a los usuarios en nuestro modelo como beneficiarios de los derechos de acceso. Nosotros
hacerlo asociando con cada invocación y cada resultado la autoridad en la que se
emitido. Tal autoridad se llama principal . Un principal puede ser un usuario o un proceso.
En nuestra ilustración, la invocación proviene de un usuario y el resultado de un servidor.
El servidor es responsable de verificar la identidad del principal detrás de cada
invocación y comprobación de que tienen suficientes derechos de acceso para realizar la solicitud
operación sobre el objeto particular invocado, rechazando aquellos que no lo hagan. El cliente puede
Verifique la identidad del principal detrás del servidor para asegurarse de que el resultado provenga de
el servidor requerido.
Asegurar los procesos y sus interacciones • Los procesos interactúan enviando mensajes.
Los mensajes están expuestos a ataques porque la red y el servicio de comunicación
que utilizan son abiertos, para permitir la interacción de cualquier par de procesos. Servidores y pares
Los procesos exponen sus interfaces, lo que permite que las invocaciones les sean enviadas por cualquier otro
proceso.
Los sistemas distribuidos a menudo se implementan y utilizan en tareas que probablemente sean
sujeto a ataques externos por parte de usuarios hostiles. Esto es especialmente cierto para aplicaciones que
Página 37
Figura 2.18 El enemigo
Copia de m
El enemigo
metro'
Proceso p metro Proceso q
Canal de comunicación
manejar transacciones financieras, información confidencial o clasificada o cualquier otra

información cuyo secreto o integridad es crucial. La integridad está amenazada por la seguridad
violaciones así como fallas de comunicación. Entonces sabemos que es probable que haya
amenazas a los procesos que componen dichas aplicaciones y a los mensajes
viajando entre los procesos. Pero, ¿cómo podemos analizar estas amenazas para
identificarlos y derrotarlos? La siguiente discusión presenta un modelo para el análisis
de amenazas a la seguridad.
El enemigo • Para modelar las amenazas a la seguridad, postulamos un enemigo (a veces también conocido
como el adversario) que sea capaz de enviar cualquier mensaje a cualquier proceso y leer o
copiar cualquier mensaje enviado entre un par de procesos, como se muestra en la Figura 2.18. Semejante
Los ataques se pueden realizar simplemente usando una computadora conectada a una red para ejecutar un
programa que lee mensajes de red dirigidos a otras computadoras en la red, o
un programa que genera mensajes que realizan solicitudes falsas a los servicios, pretendiendo
provienen de usuarios autorizados. El ataque puede provenir de una computadora legítimamente
conectado a la red o desde uno que está conectado de manera no autorizada.
Las amenazas de un enemigo potencial incluyen amenazas a procesos y amenazas a
canales de comunicación .
Amenazas a los procesos: un proceso que está diseñado para manejar solicitudes entrantes puede
recibir un mensaje de cualquier otro proceso en el sistema distribuido, y no puede
determinar necesariamente la identidad del remitente. Los protocolos de comunicación como IP hacen
incluir la dirección de la computadora de origen en cada mensaje, pero no es difícil para un
enemigo para generar un mensaje con una dirección de origen falsificada. Esta falta de confianza
El conocimiento de la fuente de un mensaje es una amenaza para el correcto funcionamiento de ambos
servidores y clientes, como se explica a continuación:
Servidores : dado que un servidor puede recibir invocaciones de muchos clientes diferentes, no puede
determinar necesariamente la identidad del principal detrás de cualquier invocación en particular.
Incluso si un servidor requiere la inclusión de la identidad del principal en cada invocación,
un enemigo puede generar una invocación con una identidad falsa. Sin confiable
conocimiento de la identidad del remitente, un servidor no puede decir si debe realizar la
operación o rechazarla. Por ejemplo, un servidor de correo no sabría si el usuario
está permitido detrás de una invocación que solicita un elemento de correo de un buzón en particular
para hacerlo o si fue una solicitud de un enemigo.
Clientes : cuando un cliente recibe el resultado de una invocación de un servidor, no puede

decir necesariamente si la fuente del mensaje de resultado es del servidor previsto
Página 38
o de un enemigo, tal vez 'falsificando' el servidor de correo. Así el cliente podría recibir
un resultado que no estaba relacionado con la invocación original, como un artículo de correo falso (uno
que no está en el buzón del usuario).
Amenazas a los canales de comunicación: un enemigo puede copiar, alterar o inyectar mensajes a medida que
viajar a través de la red y sus puertas de enlace intermedias. Tales ataques presentan una amenaza para
la privacidad e integridad de la información mientras viaja por la red y la integridad
del sistema. Por ejemplo, un mensaje de resultado que contenga el elemento de correo de un usuario podría ser
revelado a otro usuario o podría modificarse para decir algo bastante diferente.
Otra forma de ataque es el intento de guardar copias de mensajes y reproducirlos
en un momento posterior, lo que permite reutilizar el mismo mensaje una y otra vez.
Por ejemplo, alguien podría beneficiarse reenviando un mensaje de invocación solicitando un
transferencia de una suma de dinero de una cuenta bancaria a otra.
Todas estas amenazas se pueden vencer mediante el uso de canales seguros , que son
que se describen a continuación y se basan en la criptografía y la autenticación.
Derrotar las amenazas de seguridad • Aquí presentamos las principales técnicas sobre las que proteger
se basan los sistemas. El capítulo 11 analiza el diseño y la implementación de sistemas
sistemas distribuidos con mucho más detalle.
Criptografía y secretos compartidos: suponga que un par de procesos (por ejemplo, un
cliente en particular y un servidor en particular) comparten un secreto; es decir, ambos conocen el secreto
pero ningún otro proceso del sistema distribuido lo sabe. Entonces, si un mensaje intercambiado por
ese par de procesos incluye información que prueba el conocimiento del remitente del
secreto compartido, el destinatario sabe con certeza que el remitente era el otro proceso en el
par. Por supuesto, se debe tener cuidado para garantizar que el secreto compartido no se revele a un
enemigo.
La criptografía es la ciencia de mantener seguros los mensajes, y el cifrado es la
proceso de codificación de un mensaje de tal manera que se oculte su contenido. M oderno
La criptografía se basa en algoritmos de cifrado que utilizan claves secretas : grandes números que
son difíciles de adivinar, para transformar los datos de una manera que solo se puede revertir con
conocimiento de la clave de descifrado correspondiente.
Autenticación: el uso de secretos compartidos y cifrado proporciona la base para la
autenticación de mensajes: prueba
La técnica de autenticación consistedeenlasincluir
identidades proporcionadas
en un mensaje una partepor sus remitentes.
cifrada Lo básico
que contiene
suficiente del contenido del mensaje para garantizar su autenticidad. La autenticacion
parte de una solicitud a un servidor de archivos para leer parte de un archivo, por ejemplo, puede incluir un
representación de la identidad del mandante solicitante, la identidad del expediente y la fecha
y hora de la solicitud, todo cifrado con una clave secreta compartida entre el servidor de archivos
y el proceso de solicitud. El servidor descifraría esto y comprobaría que corresponde
a los detalles sin cifrar especificados en la solicitud.
Canales seguros: el cifrado y la autenticación se utilizan para crear canales seguros como
capa de servicio sobre los servicios de comunicación existentes. Un canal seguro es un
canal de comunicación que conecta un par de procesos, cada uno de los cuales actúa en nombre de
un principal, como se muestra en la Figura 2.19. Un canal seguro tiene las siguientes propiedades:
• Cada uno de los procesos conoce de manera confiable la identidad del principal en cuyo nombre
el otro proceso se está ejecutando. Por lo tanto, si un cliente y un servidor se comunican a través de un
canal seguro, el servidor conoce la identidad del principal detrás del
Página 39
Figura 2.19 Canales seguros
Director A Director B
Proceso p Canal seguro Proceso q
invocaciones y puede comprobar sus derechos de acceso antes de realizar una operación. Esto
permite que el servidor proteja sus objetos correctamente y permite que el cliente esté seguro
que está recibiendo resultados de un servidor de buena fe .
• Un canal seguro garantiza la privacidad e integridad (protección contra manipulación)
de los datos transmitidos a través de él.
• Cada mensaje incluye una marca de tiempo física o lógica para evitar que los mensajes
siendo reproducido o reordenado.
La construcción de canales seguros se analiza en detalle en el Capítulo 11. Canales seguros

se han convertido en una importante herramienta práctica para asegurar el comercio electrónico y la
protección de la comunicación. Redes privadas virtuales (VPN, discutidas en el Capítulo 3)
y el protocolo Secure Sockets Layer (SSL) (discutido en el Capítulo 11) son instancias.
Otras posibles amenazas de un enemigo • La Sección 1.5.3 introdujo muy brevemente dos
más amenazas a la seguridad: ataques de denegación de servicio y despliegue de código móvil.
Reiteramos estas como posibles oportunidades para que el enemigo interrumpa las actividades de
procesos:
Denegación de servicio : esta es una forma de ataque en la que el enemigo interfiere con el
actividades de los usuarios autorizados haciendo invocaciones excesivas e inútiles en
servicios o transmisiones de mensajes en una red, lo que resulta en una sobrecarga de
recursos (ancho de banda de la red, capacidad de procesamiento del servidor). Dichos ataques suelen ser
realizado con la intención de retrasar o prevenir acciones de otros usuarios. Para
Por ejemplo, el funcionamiento de las cerraduras electrónicas de las puertas de un edificio puede
ataque que satura la computadora que controla las cerraduras electrónicas con inválidos
peticiones.
Código móvil : el código móvil plantea nuevos e interesantes problemas de seguridad para cualquier
proceso que recibe y ejecuta código de programa de otro lugar, como el correo electrónico
adjunto mencionado en la Sección 1.5.3. Este código puede fácilmente convertirse en un caballo de Troya.
función, que pretende cumplir un propósito inocente, pero de hecho incluye un código que accede
o modifica los recursos que están legítimamente disponibles para el proceso anfitrión pero no para el
creador del código. Los métodos por los cuales se pueden llevar a cabo tales ataques son
muchos y variados, y el entorno anfitrión debe construirse con mucho cuidado en
para evitarlos. M uchos de estos problemas se han abordado en Java y otros
sistemas de códigos móviles, pero la historia reciente de este tema ha incluido la exposición de
Página 40
algunas debilidades vergonzosas. Esto ilustra bien la necesidad de un análisis riguroso en

el diseño de todos los sistemas seguros.
Los usos de los modelos de seguridad • Se podría pensar que el logro de la seguridad en
sistemas distribuidos sería un asunto sencillo que implica el control de acceso a
objetos de acuerdo con derechos de acceso predefinidos y el uso de canales seguros para
comunicación. Desafortunadamente, este no es el caso en general. El uso de la seguridad
técnicas como el cifrado y el control de acceso incurre en un procesamiento sustancial y
costos de gestión. El modelo de seguridad descrito anteriormente proporciona la base para el análisis
y diseño de sistemas seguros en los que estos costos se mantengan al mínimo, pero las amenazas a
un sistema distribuido surge en muchos puntos, y un análisis cuidadoso de las amenazas que pueden
surgen de todas las fuentes posibles en el entorno de red del sistema, físicas
se necesita el medio ambiente y el medio ambiente humano. Este análisis implica la construcción
de un modelo de amenaza que enumera todas las formas de ataque a las que está expuesto el sistema y una
evaluación de los riesgos y consecuencias de cada uno. La efectividad y el costo de la
Las técnicas de seguridad necesarias pueden entonces equilibrarse con las amenazas.
2.5 Resumen
Como se ilustra en la Sección 2.2, los sistemas distribuidos son cada vez más complejos en términos de
sus características físicas subyacentes; por ejemplo, en términos de escala de sistemas,
el nivel de heterogeneidad inherente a tales sistemas y las demandas reales para proporcionar
soluciones integrales en términos de propiedades como la seguridad. Esto lugares aumentando
importancia de poder comprender y razonar sobre los sistemas distribuidos en términos de
modelos. Este capítulo siguió la consideración de los modelos físicos subyacentes con
un examen en profundidad de los modelos arquitectónicos y fundamentales que sustentan
sistemas distribuidos.
Este capítulo ha presentado un enfoque para describir los sistemas distribuidos en términos
de un modelo arquitectónico abarcador que da sentido a este espacio de diseño que examina
las cuestiones centrales de lo que se está comunicando y cómo se comunican estas entidades,
complementado con la consideración de los roles que cada elemento puede desempeñar junto con el
estrategias de ubicación adecuadas dada la infraestructura física distribuida. La
El capítulo también presentó el papel clave de los patrones arquitectónicos para permitir más complejos
Diseños que se construirán a partir de los elementos centrales subyacentes, como el cliente-servidor.
modelo resaltado arriba, y destacó los principales estilos de middleware de apoyo
soluciones, incluidas soluciones basadas en objetos distribuidos, componentes, servicios web
y eventos distribuidos.
En términos de modelos arquitectónicos, prevalece el enfoque cliente-servidor: la Web
y otros servicios de Internet como FTP, noticias y correo, así como servicios web y
Los DNS se basan en este modelo, al igual que los servicios de presentación y otros servicios locales. Servicios como el
Los DNS que tienen un gran número de usuarios y gestionan una gran cantidad de información se basan
en varios servidores y utilice la partición de datos y la replicación para mejorar la disponibilidad y
Tolerancia a fallos. El almacenamiento en caché por parte de clientes y servidores proxy se utiliza ampliamente para mejorar la
ejecución de un servicio. Sin embargo, ahora existe una amplia variedad de enfoques para
M odelado de sistemas distribuidos que incluyen filosofías alternativas como peer-to-peer
Página 41
EJERCICIOS 77
computación y soporte para abstracciones más orientadas a problemas, como objetos,

componentes o servicios.
El modelo arquitectónico se complementa con modelos fundamentales, que ayudan a
razonamiento sobre las propiedades del sistema distribuido en términos de, por ejemplo,
rendimiento, fiabilidad y seguridad. En particular, presentamos modelos de interacción,
fracaso y seguridad. Identifican las características comunes de los componentes básicos
a partir de los cuales se construyen los sistemas distribuidos. El modelo de interacción se refiere
con el desempeño de los procesos y canales de comunicación y la ausencia de un
reloj global. Identifica un sistema síncrono como uno en el que los límites conocidos pueden ser
colocado en el tiempo de ejecución del proceso, el tiempo de entrega de mensajes y la desviación del reloj. Identifica un
sistema asincrónico como aquel en el que no se pueden poner límites a la ejecución del proceso
tiempo, tiempo de entrega del mensaje y desviación del reloj, que es una descripción del comportamiento de
La Internet.
El modelo de fallas clasifica las fallas de procesos y comunicación básica
canales en un sistema distribuido. El enmascaramiento es una técnica mediante la cual un
El servicio se construye a partir de uno menos confiable al enmascarar algunas de las fallas que presenta. En
En particular, se puede construir un servicio de comunicación confiable a partir de una comunicación básica.
canal enmascarando sus fallas. Por ejemplo, sus fallas por omisión pueden estar enmascaradas por
retransmitir mensajes perdidos. La integridad es una propiedad de la comunicación confiable:
requiere que un mensaje recibido sea idéntico al que se envió y que ningún mensaje
ser enviado dos veces. La validez es otra propiedad: requiere que cualquier mensaje puesto en el
El búfer de salida se entregará finalmente al búfer de mensajes entrantes.
El modelo de seguridad identifica las posibles amenazas a los procesos y la comunicación
canales en un sistema distribuido abierto. Algunas de esas amenazas se relacionan con la integridad:
los usuarios malintencionados pueden alterar los mensajes o reproducirlos. Otros amenazan su privacidad.
Otro problema de seguridad es la autenticación del principal (usuario o servidor) en cuyo
nombre se envió un mensaje. Los canales seguros utilizan técnicas criptográficas para garantizar la
integridad y privacidad de los mensajes y para autenticar pares de principales comunicantes.
EJERCICIOS
2.1 Proporcione tres ejemplos específicos y contrastantes de los crecientes niveles de heterogeneidad.
con experiencia en sistemas distribuidos contemporáneos como se define en la Sección 2.2. página 39
2.2 ¿Qué problemas prevé en el acoplamiento directo entre entidades comunicantes?

que está implícito en los enfoques de invocación remota? En consecuencia, ¿qué ventajas
anticipar desde un nivel de desacoplamiento ofrecido por el desacoplamiento del espacio y el tiempo? Nota:
es posible que desee volver a visitar esta respuesta después de leer los capítulos 5 y 6. página 43
2.3 Describir e ilustrar la arquitectura cliente-servidor de una o más de las principales redes de Internet.
aplicaciones (por ejemplo, la Web, correo electrónico o netnews). página 46
2.4 Para las aplicaciones discutidas en el ejercicio 2.1, ¿qué estrategias de ubicación se emplean?
en la implementación de los servicios asociados? página 48
Página 42
2.5 Un motor de búsqueda es un servidor web que responde a las solicitudes de los clientes para buscar en sus archivos almacenados.
indexa y (al mismo tiempo) ejecuta varias tareas del rastreador web para crear y actualizar el
índices. ¿Cuáles son los requisitos para la sincronización entre estos concurrentes
¿ocupaciones? página 46
2.6 Las computadoras host utilizadas en los sistemas de igual a igual a menudo son simplemente computadoras de escritorio en
oficinas u hogares de los usuarios. ¿Cuáles son las implicaciones de esto para la disponibilidad y la seguridad?
de los objetos de datos compartidos que tienen y en qué medida se pueden
superar mediante el uso de la replicación? páginas 47, 48
2,7 Enumere los tipos de recursos locales que son vulnerables a un ataque de un programa que no es de confianza.
que se descarga de un sitio remoto y se ejecuta en una computadora local. página 50
2.8 Dé ejemplos de aplicaciones en las que el uso de código móvil sea beneficioso. página 50
2.9 Considere una hipotética empresa de alquiler de coches y esboce una solución de tres niveles para
prestación de su servicio de alquiler de coches distribuido subyacente. Use esto para ilustrar el
Beneficios e inconvenientes de una solución de tres niveles considerando cuestiones como el rendimiento,
escalabilidad, lidiar con fallas y también mantener el software a lo largo del tiempo. página 52
2.10 Proporcione un ejemplo concreto del dilema que ofrece el argumento de extremo a extremo de Saltzer en
el contexto de la provisión de soporte de middleware para aplicaciones distribuidas (puede
quieren centrarse en un aspecto de proporcionar sistemas distribuidos fiables, por ejemplo
relacionados con la tolerancia a fallos o la seguridad). página 60
2.11 Considere un servidor simple que realiza las solicitudes de los clientes sin acceder a otros servidores.
Explique por qué generalmente no es posible establecer un límite en el tiempo que toma dicho servidor.
para responder a la solicitud de un cliente. ¿Qué debería hacerse para que el servidor pueda
ejecutar solicitudes dentro de un tiempo limitado? ¿Es esta una opción práctica? página 62
2.12 Para cada uno de los factores que contribuyen al tiempo que se tarda en transmitir un mensaje entre
dos procesos a través de un canal de comunicación, indique qué medidas serían necesarias para
establecer un límite en su contribución al tiempo total. ¿Por qué no se proporcionan estas medidas en
sistemas distribuidos de uso general actuales? página 63
2.13 El servicio Network Time Protocol se puede utilizar para sincronizar los relojes de las computadoras.
Explique por qué, incluso con este servicio, no se otorga ningún límite garantizado para la diferencia.
entre dos relojes. página 64
2.14 Considere dos servicios de comunicación para su uso en sistemas distribuidos asíncronos. En
servicio A, los mensajes pueden perderse, duplicarse o retrasarse y las sumas de verificación se aplican solo a
encabezados. En el servicio B, los mensajes pueden perderse, retrasarse o entregarse demasiado rápido para el
destinatario para manejarlos, pero los que se entregan llegan con el contenido correcto.
Describa las clases de fallas que exhibe cada servicio. Clasifica sus fallas
según sus efectos sobre las propiedades de validez e integridad. ¿Puede el servicio B ser
descrito como un servicio de comunicación confiable? página 67 , página 71
2.15 Considere un par de procesos X e Y que utilizan el servicio de comunicación B de
Ejercicio
servidor y2.14
quepara
una comunicarse entre sí.enSuponga
invocación consiste que X
un mensaje de es un cliente
solicitud de XyY
a Yun
, seguido de Y
realizar la solicitud, seguido de un mensaje de respuesta de Y a X. Describa las clases
de falla que pueda exhibir una invocación. página 67
Página 43
EJERCICIOS 79
2.16 Suponga que una lectura de disco básica a veces puede leer valores que son diferentes de los
escrito. Indique el tipo de falla que presenta una lectura de disco básica. Sugiera cómo este fracaso
pueden enmascararse para producir una forma benigna de falla diferente. Ahora sugiera cómo
para enmascarar el fracaso benigno. página 70
2.17 Definir la propiedad de integridad de una comunicación confiable y enumerar todas las posibles amenazas.
a la integridad de los usuarios y de los componentes del sistema. ¿Qué medidas se pueden tomar para
Asegurar la propiedad de la integridad frente a cada una de estas fuentes de amenazas.
páginas 71, 74
2.18 Describa las posibles ocurrencias de cada uno de los principales tipos de amenazas a la seguridad (amenazas a
procesos, amenazas a los canales de comunicación, denegación de servicio) que pudieran ocurrir en el
Internet. páginas 74, 75
Página 44
Esta página se dejó en blanco intencionalmente


Resume Nad

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Resume Nad

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Resume Nad

Cargado por

Copyright:

Formatos disponibles

3/6/2021 MODELOS DE SISTEMA

Los modelos arquitectónicos describen un sistema en términos de computación y

Los modelos fundamentales adoptan una perspectiva abstracta para examinar

2.2 Modelos físicos

Un modelo físico es una representación de los elementos de hardware subyacentes de un

• La aparición de la computación ubicua ha llevado a un movimiento de nodos discretos a

• La aparición de la computación en la nube y, en particular, las arquitecturas de clústeres ha llevado

El resultado final es una arquitectura física con un aumento significativo en el nivel de

S istemas distribuidos de sistemas • Un informe reciente analiza el surgimiento de ultra-

Resumen • El desarrollo histórico general capturado en esta sección se resume

2.3 Modelos arquitectónicos

La arquitectura de un sistema es su estructura en términos de componentes especificados por separado.

Figura 2.1 Generaciones de sistemas distribuidos

Sistemas distribuidos: Temprano Escala de Internet Contemporáneo

Escala Pequeña Grande Ultra-grande

Heterogeneidad Dimensiones agregadas

Franqueza Gran desafío de investigación

Calidad de servicio Gran desafío de investigación

En esta sección describimos los principales modelos arquitectónicos empleados en distribuidos

• mirar los elementos arquitectónicos subyacentes centrales que sustentan la modernidad

2.3.1 Elementos arquitectónicos

Para comprender los bloques de construcción fundamentales de un sistema distribuido, es necesario

• ¿Cuáles son las entidades que se comunican en el sistema distribuido?

• ¿Cómo se comunican o, más específicamente, qué paradigma de comunicación

• ¿Qué roles y responsabilidades (potencialmente cambiantes) tienen en el

• ¿Cómo se asignan a la infraestructura física distribuida (cuál es su

• En algunos entornos primitivos, como las redes de sensores, el

En un nivel, esto es suficiente para modelar un sistema distribuido y, de hecho, el fundamental

Objetos : Se han introducido objetos para permitir y fomentar el uso de objetos.

Componentes : Desde su introducción, se han planteado varios problemas importantes.

permite el desarrollo de componentes por parte de terceros y también promueve una

... una aplicación de software identificada por un URI, cuyas interfaces y

• comunicación entre procesos;

La comunicación entre procesos se refiere al soporte de nivel relativamente bajo para

Protocolos de solicitud-respuesta : los protocolos de solicitud-respuesta son efectivamente un patrón impuesto

En particular, tales protocolos normalmente implican un intercambio de mensajes por pares de

Invocación de método remoto : la invocación de método remoto (RM I) se parece mucho

El conjunto de técnicas anterior tiene una cosa en común: la comunicación representa un

• Los remitentes no necesitan saber a quién están enviando ( desacoplamiento de espacio ).

La comunicación indirecta se analiza con más detalle en el Capítulo 6.

Comunicación grupal : la comunicación grupal se ocupa de la entrega de

Sistemas de publicación y suscripción : muchos sistemas, como el ejemplo de comercio financiero en

Las opciones arquitectónicas discutidas hasta ahora se resumen en la Figura 2.2.

Funciones y responsabilidades • En los procesos de un sistema distribuido, o incluso en los objetos,

Figura 2.2 Entidades comunicantes y paradigmas de comunicación

Entidades comunicantes Paradigmas de comunicación

Orientado al sistema Problema- Interproceso Remoto Indirecto

Nodos Objetos M ensaje Pedido- Grupo

Figura 2.3 Los clientes invocan servidores individuales

Cliente invocación Servidor

Colocación • La última cuestión a considerar es cómo entidades como objetos o servicios

Figura 2.5 Servidor proxy web

• mapeo de servicios a múltiples servidores;

Figura 2.6 Subprogramas web

b) el cliente interactúa con el subprograma

2.3.2 Patrones arquitectónicos

dadas las circunstancias. No son necesariamente soluciones completas en sí mismas, sino

Estratificación • El concepto de estratificación es familiar y está estrechamente relacionado con la abstracción.

Figura 2.7 Capas de servicios de software y hardware en sistemas distribuidos