44 Sistemas distribuidos

libro. El desarrollo de técnicas para comprobar y asegurar la corrección de los programas distribuidos y
concurrentes es un tema de investigación actual e importante. A pesar de presentar resultados
prometedores, sólo algunos de éstos se encuentran suficientemente maduros para su implantación en
aplicaciones reales.
Tolerancia frente a fallos: Las aplicaciones estables deben continuar funcionando correctamente en
presencia de fallos en el hardware, el software y las redes. La fiabilidad se consigue introduciendo
redundancia; proporcionando múltiples recursos de modo que el software de sistema y aplicación pueda ser
reconfigurado y seguir realizando sus tareas en presencia de fallos. La redundancia es costosa y existen
límites a la amplitud en que puede ser empleada; en consecuencia también hay límites en el grado de
tolerancia que puede obtenerse.
A nivel arquitectónico, la redundancia precisa el empleo de varios computadores donde lanzar cada
proceso componente del sistema y múltiples caminos de comunicación sobre los que transmitir los
mensajes. Los datos y los procesos pueden replicarse donde quiera que sea necesario para proporcionar el
debido nivel de tolerancia a fallos. Una forma usual de redundancia es la presencia de varias réplicas de los
datos en diferentes computadores; en tanto en cuanto uno cualquiera de los computadores continúe
funcionando, se podrá acceder a los datos. Algunas aplicaciones críticas, tales como los sistemas de control
de tráfico aéreo, precisan un alto nivel de garantías en cuanto a la tolerancia frente a fallos, lo que implica
un alto coste de mantenimiento de la actualización de las múltiples réplicas existentes. En el Capítulo 14 se
discute esta materia más profundamente.
Para hacer fiables los protocolos de comunicación se emplean otras técnicas. Por ejemplo, los
mensajes se retransmiten hasta que se ha recibido un mensaje de reconocimiento. La fiabilidad de los
protocolos subyacentes a RMI se cubren en los Capítulos 4 y 5.
Seguridad: El impacto arquitectónico de los requisitos de seguridad afecta a la necesidad de ubicar los
datos y otros recursos sensibles sólo en aquellos computadores equipados de un modo eficaz contra
ataques. Por ejemplo, una base de datos de un hospital alojará registros con un componente sensible
sobre los pacientes y sólo ciertos empleados podrán acceder a ellos, mientras que otros componentes de
los mismos registros pueden estar disponibles más ampliamente. No sería apropiado construir un sistema
en el que al acceder a los datos de un paciente se descargara el registro completo de éste en el computador
de sobremesa del usuario, dado que el computador típico de sobremesa no constituye un entorno seguro,
y los usuarios podrían lanzar programas para acceder o actualizar cualquier parte de los datos almacenados
en su computador personal. En la Sección 2.3.3 se presenta un modelo de seguridad que trata con
requisitos amplios para la seguridad, el Capítulo 7 describirá las técnicas disponibles para obtenerlo.

Todos los modelos de sistemas anteriores, aunque bien diferentes, comparten algunas propiedades
fundamentales. En particular, todos ellos se componen de procesos que se comunican unos con otros
mediante el envío de mensajes en una red de computadores. Todos los modelos comparten los requisitos
de diseño dados en la sección previa, y que conciernen principalmente a las características de prestaciones
y fiabilidad de los procesos y las redes, y a la seguridad de los recursos en el sistema. En esta sección,
presentamos modelos basados en las propiedades fundamentales que nos permiten ser más específicos
sobre las características y los riesgos de fallos y seguridad que puedan exhibir.
En general, un modelo contiene solamente aquellos ingredientes esenciales que necesitamos para
comprender y razonar sobre algunos aspectos del comportamiento del sistema. Un modelo de sistema
debe tratar las siguientes cuestiones:
 • ¿Cuáles son las entidades principales en el sistema?
• ¿Cómo interactúan?
• ¿Cuáles son las características que afectan s u comportamiento individual y colectivo?

El objetivo de un modelo es:

• Hacer explícitas todas las premisas relevantes sobre los sistemas que estamos modelando.
• Hacer generalizaciones respecto a lo que es posible o no, dadas las premisas anteriores. Las
generalizaciones pueden tomar la forma de algoritmos de propósito general o de propiedades
deseables que se garantizan. Las garantías surgirán del análisis lógico y, cuando sea pertinente, de la
prueba matemática.

Hay mucho que ganar si conocemos lo que hacen y de lo que dependen nuestros diseños, y de lo que no.
Así podremos decidir si un diseño funcionará si intentamos implementarlo en un sistema particular: sólo
necesitamos preguntarnos si nuestras premisas son válidas en ese sistema. A la vez, aclarando y
explicitando nuestras premisas, podemos esperar demostrar propiedades del sistema empleando técnicas
matemáticas. Estas propiedades valdrán para cualquier sistema que concuerde con nuestras premisas.
Finalmente, al abstraer sólo entidades y características esenciales del sistema (y no detalles, como el
hardware) podemos arrojar luz sobre nuestra comprensión de estos sistemas.
Los aspectos de los sistemas distribuidos que queremos capturar en nuestros modelos fundamentales
están destinados a ayudarnos a discutir y razonar sobre:

Interacción: el cómputo ocurre en los procesos; los procesos interaccionan por paso de mensajes, lo
que deviene en comunicación (esto es, flujo de información) y coordinación (sincronización y
ordenamiento de actividades) entre procesos. En el análisis y diseño de los sistemas dis tribuidos
trataremos especialmente con estas interacciones. El modelo de interacción debe reflejar hechos como
que la comunicación tiene lugar con retrasos, que a menudo son de considerable duración, y la
precisión con que la pueden coordinarse procesos independientes está limitada por esos retrasos y por la
dificultad de mantener la misma noción de tiempo en todos los computadores de un sistema distribuido.
Fallo: la correcta operación de un sistema distribuido se ve amenazada allá donde aparezca un fallo en
cualquiera de los computadores sobre el que se ejecuta (incluyendo fallos de software) o en la red que
los conecta. Nuestro modelo define y clasifica los fallos. Esto nos da la base para el anális is de los
efectos potenciales de los fallos y para el diseño de sistemas que tolerando fallos de cualquier tipo
puedan seguir funcionando correctamente.
Seguridad: la naturaleza modular de los sistemas distribuidos y su extensibilidad los expone a ataques
tanto de agentes externos como internos. Nuestro modelo de seguridad define y clasifica los modos en
que pueden tener lugar tales ataques, y proporciona una base para el análisis de las amenazas a un
sistema con el fin de diseñar sistemas capaces de resistirse a ellas.

Para discutir y razonar más fácilmente, los modelos presentados en este capítulo están necesariamente
simplificados, omitiéndose muchos detalles de los sistemas reales. Su relación con los sistemas del mundo
real y la solución que esos modelos nos ayudan a traer a colación, en ese contexto, son el tema principal de
este libro.

2.3.1. MODELO DE INTERACCIÓN

La discusión de arquitecturas de sistemas de la Sección 2.2 indica que los sistemas distribuidos se
componen de muchos procesos, y que interactúan de formas complejas. Por ejemplo:

• Múltiples procesos servidores pueden cooperar entre sí para proporcionar un servicio; los
ejemplos mencionados anteriormente son el Servicio de Nombres de Dominio, que parte y
46 Sistemas distribuidos

replica sus datos en los servidores a lo largo de Internet; y el Servicio de Información en Red de Sun,
que mantiene copias replicadas de los archivos de contraseñas en varios servidores de una red de
área local.
• Un conjunto de procesos similares pueden cooperar entre sí para lograr una meta común: por ejemplo,
un sistema de conferencia para voz que distribuye flujos de datos de audio de forma similar, pero con
estrictas restricciones de tiempo real.

La mayoría de los programadores estarán familiarizados con el concepto de algoritmo: secuencia de

pasos que hay que seguir para realizar un cómputo deseado. Los programas simples están controlados por
algoritmos en los que los pasos son estrictamente secuénciales. El comportamiento del programa y el estado
de las variables del programa está determinado por aquéllos. Tal progra ma se ejecuta como un proceso
aislado. Los sistemas distribuidos compuestos de varios procesos, tales como los delineados anteriormente,
son más complejos. Su comportamiento y el estado puede describirse mediante un algoritmo distribuido:
una definición de los pasos que hay que llevar a cabo por cada uno de los procesos de que consta el sistema,
incluyendo los mensajes de transmisión entre ellos. Los procesos transmiten mensajes de uno a otro para
transferir información y coordinar su actividad.
La tasa con que procede cada proceso y la temporización de la transmisión de los mensajes entre ellos
no puede predecirse, en general. También es difícil describir todos los estados de un algoritmo distribuido,
dado que éste debe tratar con los fallos de uno, o más, de los procesos involucrados, o el fallo en la
transmisión de los mensajes.
En un sistema distribuido toda la acción la soportan los procesos que interactúan. Cada proceso tiene su
propio estado, que consiste en el conjunto de datos a los que puede acceder y actualizar, incluyendo las
variables internas al programa. El estado concerniente a cada proceso es completamente privado, esto es,
no puede ser accedido o actualizado por otro proceso.
En esta sección, discutiremos dos factores significativos que afectan a los procesos interactuantes de un
sistema distribuido:
• Las prestaciones de las comunicaciones son con frecuencia una característica limitadora.
• Es imposible mantener una única noción global del tiempo.

Prestaciones de los canales de comunicaciones. Los canales de comunicación, en nuestro modelo, se

implementan de muchas formas en los sistemas distribuidos; por ejemplo me diante una implementación de
streams o por un simple paso de mensajes sobre la red de computadores. Las características de prestaciones
de la comunicación sobre una red de computadores incluyen la latencia, el ancho de banda y las
fluctuaciones:

• El retardo entre el envío de un mensaje por un proceso y su recepción por otro se denomina latencia.
La latencia incluye:

- El tiempo que se toma en llegar a su destino el primero de una trama de bits transmitidos a través
de una red. Por ejemplo, la latencia para la transmisión de un mensaje mediante un enlace por
satélite es el lapso de tiempo en que la señal va y vuelve del satélite.
- El retardo en acceder a la red, que es grande cuando la red está muy cargada. Por ejemplo, al
transmitir sobre Ethernet la estación de emisión esperará a que la red esté libre de tráfico.
- El tiempo empleado por los servicios de comunicación del sistema operativo tanto en el proceso que
envía como en el que recibe, y que varía según la carga actual de cada sistema operativo.

• El ancho de banda de una red de computadores es la cantidad total de información que puede
transmitirse en un intervalo de tiempo dado. Cuando una red está siendo utilizada por un número
grande de canales de comunicación, habrá que compartir el ancho de banda dis ponible.
 • La fluctuación (fitter) es la variación en el tiempo invertido en completar el reparto de una serie de
mensajes. La fluctuación es importante para los datos multimedia. Este es el caso que si se reproducen
muestras de audio consecutivas a un ritmo variable el sonido presentará graves distorsiones.

Relojes de computadores y eventos de temporización. Cada computador de un sistema distribuido tiene

su propio reloj interno; los procesos locales obtienen de él, el valor del tiempo actual. Ésta es la forma en
que dos procesos en ejecución sobre dos computadores diferentes asocian marcas (o sellos) temporales a sus
eventos. Sin embargo, incluso si dos procesos leen sus relojes a la vez, sus relojes locales proporcionarán
valores de tiempo diferentes. Esto ocurre porque los relojes presentan derivas con respecto al tiempo
perfecto y, más importante, sus tasas de deriva difieren de una a otra. El término tasa de deriva del reloj
alude a la proporción en que el reloj de un computador difiere del reloj de referencia perfecto. Incluso, si los
relojes de todos los computadores de un sistema distribuido se ponen en hora a la vez, a partir de un tiempo
sus relojes variarán en una magnitud significativa a menos que se apliquen correcciones.
Hay varias aproximaciones a la corrección de los tiempos del reloj de los computadores. Así, podría
utilizarse receptores de radio para obtener lecturas de tiempo de un GPS con aproximaciones cercana al
microsegundo. Pero los receptores GPS no operan dentro de los edificios, ni se justifica el coste para cada
computador. En su lugar, un computador dotado de una fuente de tiempo precisa, como un GPS, sí que
podría enviar mensajes de temporización a otros computadores de la red. La concordancia final entre los
tiempos de los relojes locales está, por supuesto, afectada por retardos variables en los mensajes. Para una
discusión más detallada de la deriva del reloj y sincro nización del reloj, véase el Capítulo 11.

Dos variantes del modelo de interacción. En un sistema distribuido es difícil establecer cotas sobre el
tiempo que debe tomar la ejecución de un proceso, el reparto de un mensaje o la deriva del reloj. Tenemos
dos modelos simples que parten de posiciones extremas y opuestas: el primero tiene en cuenta una fuerte
restricción sobre el tiempo; en el segundo no se hace ninguna presuposición.

Sistemas distribuidos síncronos: Hadzilacos y Toueg [1994] definen un sistema distribuido síncrono
como aquel en el que se establecen los siguientes límites:
• El tiempo de ejecución de cada etapa de un proceso tiene ciertos límites inferior y superior conocidos.
• Cada mensaje transmitido sobre un canal se recibe en un tiempo limitado conocido.
• Cada proceso tiene un reloj local cuya tasa de deriva sobre el tiempo real tiene un límite conocido.

Es posible sugerir valores parecidos para los límites superior e inferior del tiempo de ejecución de un
proceso, el retardo de mensajes y las tasas de deriva de relojes en un sistema distribuido. Pero es difícil
obtener valores realistas y además dar garantías sobre los valores elegidos. A menos que podamos
garantizar los límites, cualquier diseño basado en los valores elegidos no será fiable. Sin embargo,
pudiera ser útil modelar un algoritmo como un sistema síncrono para dar una idea de cómo se comportará
en un sistema distribuido real. En un sistema síncrono, es posible utilizar tiempo límite (timeouts), por
ejemplo para detectar el fallo de un proceso, tal y como se muestra en la sección que trata del modelo de
fallo.
Se pueden construir sistemas distribuidos síncronos. Esto requiere que los procesos imple menten
tareas con requisitos de recursos conocidos, para los que se pueda garantizar ciclos suficientes de
procesador y capacidad de red; y que se provea a estos procesos de relojes con tasas de deriva limitada.

Sistemas distribuidos asíncronos: muchos sistemas distribuidos, por ejemplo Internet, son de gran
utilidad aun sin ser sistemas síncronos. En consecuencia necesitamos un modelo alternativo: un sistema
distribuido asíncrono es aquel en que no existen limitaciones sobre:
48 Sistemas distribuidos

• La velocidad de procesamiento (por ejemplo, un paso de un proceso puede requerir tan sólo un
picosegundo y otro un siglo; lo único que podemos decir es que cada paso se tomará un tiempo
arbitrariamente largo).
• Los retardos de transmisión de mensaje (por ejemplo, al repartir un mensaje de un proceso A a
otro B puede tardar un tiempo cero o bien varios años. En otras palabras, un mensaje puede
recibirse tras un tiempo arbitrariamente largo).
• Las tasas de deriva de reloj (de nuevo, la tasa de deriva de reloj es arbitraria).

El modelo asíncrono no presupone nada sobre los intervalos de tiempo involucrados en cualquier
ejecución. Éste es exactamente el modelo de Internet, en él no hay límite intrínseco en la carga del
servidor o la red (en consecuencia no se sabe cuánto tomará, por ejemplo, transferir un archivo usando
ftp). A veces un mensaje de correo puede tomarse varios días en llegar. El recuadro de la página
siguiente ilustra la dificultad de llegar a un acuerdo en un sistema distribuido asíncrono.
Aun así con estas premisas se pueden resolver algunos problemas de diseño. Por ejemplo, a pesar
de que el Web no siempre puede proveer una respuesta en un límite de tiempo razonable, los
navegadores se diseñan para permitir que los usuarios realicen otras tareas mientras están a la espera.
Cualquier solución válida para un sistema distribuido asíncrono es válida también para un sistema
síncrono.
Los sistemas distribuidos reales son frecuentemente asíncronos a causa de la necesidad de los
procesos de compartir procesadores y de los canales de comunicación de compartir la red. Por ejemplo,
si demasiados procesos de índole desconocida comparten un procesador, no habrá garantías sobre las
prestaciones resultantes de ninguno de ellos. Pero existen muchos problemas de diseño que no pueden
ser resueltos para un sistema asíncrono que pueden resolverse cuando se tienen en cuenta algunos
aspectos temporales. La necesidad de que cada elemento de un flujo de datos multimedia se reparta
antes de un tiempo límite es un problema de este tipo. Para problemas como éste se requiere un modelo
síncrono. El recuadro de más adelante ilustra la imposibilidad de sincronizar los relojes en un sistema
asíncrono.
Ordenamiento de eventos. En muchos casos, nos interesa saber si un evento (enviar o recibir un mensaje)
en un proceso ocurrió antes, después o concurrentemente con otro evento en algún otro proceso. La ejecución
de un sistema puede describirse en términos de los eventos y su ordenación aun careciendo de relojes
precisos.
Por ejemplo, considere el siguiente conjunto de intercambios entre un pequeño grupo de usuarios X, Y,
Z y A de una lista de correo:
1. El usuario X envía un mensaje con el tema Reunión.
2. Los usuarios Y y Z responden con un mensaje con el tema Re: Reunión.
En tiempo real, se envía primero el mensaje de X, Y lo lee y responde; Z lee ambos mensajes, el de X y la
respuesta de Y y entonces envía otra respuesta, que hace referencia a los dos anteriores. Pero debido a los
retardos independientes en el reparto de los mensajes, los mensajes pudieran haber sido repartidos como se
muestra en la Figura 2.9, y algunos usuarios podrían ver estos mensajes en el orden equivocado, por
ejemplo, el usuario A podría ver:
 Modelos de sistema 49

Si los relojes de los computadores de X, Y y Z pudieran sincronizarse, podría utilizarse el tiempo asociado
localmente a cada mensaje enviado. Por ejemplo, los mensajes m1 , m2 , y m3 llevarían los tiempos t1, t2 , y t3
donde t1 , < t2 , < t3 . Los mensajes recibidos se mostrarían a los usuarios según este ordenamiento temporal.
Si los relojes están sincronizados aproximadamente la temporización ocurrirá en el orden correcto.

Como los relojes de un sistema distribuido no pueden sincronizarse de manera perfecta, Lamport
[1987] propuso un modelo de tiempo lógico que pudiera utilizarse para ordenar los eventos de procesos que
se ejecutan en computadores diferentes de un sistema distribuido. El tiempo lógico permite inferir el orden
en que se presentan los mensajes sin recurrir a relojes. Se presenta en detalle en el Capítulo 10, aunque aquí
bosquejaremos cómo pueden aplicarse algunos aspectos del ordenamiento lógico a nuestro problema de
ordenamiento de correos electrónicos.
Sistemas distribuidos

Es obvio que los mensajes se reciben después de su envío, así podemos admitir un ordenamiento
lógico para los pares de sucesos que se muestran en la Figura 2.9; por ejemplo, considerando sólo los
eventos relativos a X e Y:

X envía m, antes de que Y reciba m1 ; Y envía m2 antes de que X reciba m2.

También sabemos que las respuestas se reciben después de que se reciben los mensajes, de modo que
tenemos el siguiente ordenamiento lógico para Y:

Y recibe m, antes de enviar m2 .

El tiempo lógico lleva esta idea más lejos asignando un número a cada evento, que se corresponde con su
ordenamiento lógico, de modo que los últimos eventos tendrán números mayores que los primeros. Como
ejemplo, en la Figura 2.9 se consignan los números 1 a 4 en los eventos en X e Y.

2.3.2. MODELO DE FALLO

En un sistema distribuido pueden fallar tanto los procesos como los canales de comunicación; esto es,
podrían apartarse de lo que se considera el comportamiento correcto o deseable. El modelo de fallo define
las formas en que puede ocurrir el fallo para darnos una comprensión de los efectos de los fallos.
Hadzilacos y Toueg [1994] proponen una taxonomía que distingue entre los fallos de procesos y los fallos
de canales de comunicación. Éstos se presentan bajo los encabezamientos: fallos por omisión, fallos
arbitrarios y fallos de temporización.
Este modelo de fallo se utilizará a lo largo del libro. Este es el caso de:

• En el Capítulo 4, donde presentamos las interfaces Java de la comunicación de tipo datagrama y

stream, que proporcionan diferentes grados de fiabilidad.
• El Capítulo 4 en el que presentamos el protocolo petición-respuesta, que subyace a RMI. Sus
características de fallo dependen de las características de fallo tanto de los procesos como de los
canales de comunicación. El protocolo puede construirse mediante comunicación basada en
datagramas o streams. La elección podrá decidirse en función de la simplicidad de la im-
plementación, las prestaciones y la fiabilidad.
• El Capítulo 13 donde se presenta el protocolo de realización en dos fases (two-phase commit) para
transacciones. Está diseñado para completarse en presencia de fallos bien definidos de los procesos y
de los canales de comunicación.

Fallos por omisión. Las faltas clasificadas como fallos por omisión se refieren a casos en los que los
procesos o los c anales de comunicación no consiguen realizar acciones que se suponen que pueden hacer.

Fallos por omisión de procesos: El principal fallo por omisión de un proceso es el fracaso o ruptura
accidentada del procesamiento (crash). Cuando decimos que un proces o se rompe queremos decir que ha
parado y no ejecutará ningún paso de programa más. El diseño de servicios que puedan sobrevivir en
presencia de fallos se puede simplificar si asumimos que los servicios de los que depende fracasan
limpiamente; es decir, los procesos de los que depende o funcionan correctamente o se detienen. Otros
procesos pueden ser capaces de detectar tales fracasos por el hecho de que los procesos rotos fallan
repetidamente en responder a los mensajes de invocación. Desgraciadamente, este método de detección de
rupturas descansa en el uso de timeouts; es decir un método en el cual un proceso otorga un período fijo de
tiempo para que algo ocurra. En un sistema asíncrono un timeout puede indicar tan sólo que un proceso no
responde; puede que se haya roto o sea lento, o que los mensajes no hayan llegado.
 Modelos de sistema 51

La rotura de un proceso se denomina fallo -parada (fail-stop) si los otros procesos pueden detectar con
certeza que el proceso ha fracasado. El comportamiento fallo-parada puede producirse en un sistema
síncrono si el proceso utiliza timeouts para detectar cuando los otros procesos fallan en la respuesta y está
garantizado que los mensajes llegan. Por ejemplo, si los procesos p y q están programados para que q
responda a un mensaje de p, y el proceso p no ha recibido respuesta del proceso q en un tiempo máximo
medido por el reloj local de p, entonces el proceso p puede concluir que el proceso q ha fallado. El recuadro
próximo ilustra la dificultad de detectar los fallos en un sistema asíncrono o de llegar a un acuerdo en
presencia de fallos.

Fallos por omisión de comunicaciones: Considere las primitivas de comunicación envía y recibe. Un
proceso p realiza un envío insertando el mensaje m en su búfer de mensajes salientes. El canal de
comunicación transporta m al búfer de mensajes entrantes de q. El proceso q realiza un recibe tomando m de
su búfer de mensajes entrantes y repartiéndolo (véase la Figura 2.10). Los búferes entrante y saliente se
proporcionan usualmente desde el sistema operativo.
El canal de comunicación produce un fallo de omisión si no transporta un mensaje desde el búfer de
mensajes salientes de p al búfer de mensajes entrantes de q. A esto se denomina «perder mensajes» y su
causa suele ser la falta de espacio en el búfer de recepción de alguna pasarela de entre medias, o por un error
de red, detectable por una suma de chequeo de los datos del mensaje. Hadzilacos y Toueg [1994] se refieren
a la pérdida de mensajes entre el proceso emisor y el búfer de mensajes de salida como fallos por omisión
de envío; la pérdida de mensajes entre el búfer de mensajes de entrada y el proceso receptor como fallos por
omisión de recepción; y la pérdida de mensajes entre los búferes como fallos por omisión del canal. En la
Figura 2.11 se clasifican los fallos por omisión junto con los fallos arbitrarios.
 Figura 2.11. Fallos por omisión y fallos arbitrarios.

Los fallos pueden categorizarse según su severidad. Todos los fallos que hemos descrito hasta el
momento son benignos. La mayoría de los fallos de los sistemas distribuidos son de esta clase. Los fallos
benignos incluyen fallos por omisión así como fallos de temporización y fallos de prestaciones.

Fallos arbitrarios. El término arbitrario, o fallo bizantino, se emplea para describir la peor semántica de
fallo posible, en la que puede ocurrir cualquier tipo de error. Por ejemplo, un procese podría cargar valores
equivocados en su área de datos, o podría responder un valor incorrecto a una petición.
Un fallo arbitrario en un proceso es aquel en el que se omiten pasos deseables para el procesamiento o
se realizan pasos no intencionados de procesamiento. En consecuencia los fallos arbitra rios en los procesos
no pueden detectarse observando si el proceso responde a las invocaciones, dado que podría omitir
arbitrariamente la respuesta.
Los canales de comunicación sufren fallos arbitrarios; por ejemplo: los contenidos de un mensaje
pueden estar corrompidos o se pueden repartir mensajes no existentes o incluso algunos
 Modelos de sistema 53

Figura 2.12. Fallo de temporización.

mensajes auténticos pueden repartirse más de una vez. Los fallos arbitrarios de los canales de comunicación
son raros porque el software de comunicación es capaz de reconocerlos y rechazar los mensajes fallidos. Por
ejemplo, para detectar mensajes corrompidos empleamos sumas de chequeo, y podemos emplear números
de secuencia para detectar mensajes no existentes y mensajes duplicados.
Fallos de temporización. Los fallos de temporización se aplican en los sistemas distribuidos síncronos
donde se establecen límites en el tiempo de ejecución de un proceso, en el tiempo de reparto de un mensaje
y en la tasa de deriva de reloj. Los fallos de temporización se muestran en la Figura 2.12. Cualquiera de
estos fallos puede ocasionar que las respuestas no estuvieran disponibles para los clientes en un intervalo de
tiempo dado.
En un sistema distribuido asíncrono, un servidor sobrecargado podría responder demasiado lentamente,
pero no podemos decir que haya habido un fallo de temporización dado que no se ha ofrecido ninguna
garantía al respecto.
Los sistemas operativos de tiempo real se diseñan con vistas a proporcionar garantías de temporización,
pero son más complejos 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 restricciones de tiempo real.
La temporización es particularmente relevante en los computadores multimedia con canales de audio y
vídeo. La información de vídeo puede requerir la transferencia de una gran cantidad de datos. El reparto de
tal cantidad de información, sin fallos de temporización, puede exigir demandas especiales tanto en el
sistema operativo como en el sistema de comunicación.
Enmascaramiento de fallos. Cada componente de un sistema distribuido se construye generalmente a
partir de un conjunto de componentes ya existentes. Es posible construir servicios fiables con componentes
que presenten fallos. Por ejemplo, múltiples servidores que alojen réplicas de datos pueden continuar
prestando un servicio aunque uno de ellos se rompa. El conocimiento de las características de fallo de un
componente puede permitirnos crear un nuevo servicio diseñado para enmascarar los fallos del primero. Un
servicio enmascara un fallo, bien, ocultándolo comple tamente o convirtiéndolo en otro tipo de fallo más
aceptable. Un ejemplo de este último es el cómo se utilizan las sumas de chequeo para enmascarar los
mensajes corrompidos, convirtiendo un fallo arbitrario en un fallo por omisión. Veremos en los Capítulos 3
y 4 que los fallos por omisión pueden ocultarse empleando un protocolo que retransmita los mensajes que
no alcanzan su destino. El Capítulo 14 presenta el enmascaramiento mediante replicación. Incluso la ruptura
de procesos puede enmascararse, remplazando el proceso y restaurando su memoria de la información
almacenada en el disco sobre su predecesor.
Fiabilidad y comunicación uno a uno. Aunque un canal de comunicación básico pueda presentar fallos
por omisión como los descritos anteriormente, es posible utilizarlo para construir un servicio de
comunicación que enmascare algunos de esos fallos.

El término comunicación fiable se define en términos de validez e integridad, definidos como sigue:
Sistemas distribuidos

Validez: Cualquier mensaje en el búfer de mensajes salientes será hecho llegar eventualmente al búfer
de mensajes entrantes;
Integridad: El mensaje recibido es idéntico al enviado, y no se reparten mensajes por duplicado.

Las amenaza s a la integridad provienen de dos fuentes independientes:

• Cualquier protocolo que retransmita mensajes pero no rechace un mensaje que llegue dos veces.
Los protocolos pueden adjuntar números de secuencia a los mensajes para detectar aquellos que
se reparten por duplicado.
• Usuarios malintencionados que insertan mensajes espurios, repiten mensajes antiguos o
modifican mensajes auténticos. Se pueden tomar medidas de seguridad para mantener la
propiedad de integridad en caso de tales ataques.

2.3.3. MODELO DE SEGURIDAD

En la Sección 2.2 identificamos la compartición de recursos como un factor motivador para los sistemas
distribuidos y describimos su arquitectura de sistema en términos de procesos que encapsulan objetos y
proporcionan acceso a ellos mediante interacciones con otros procesos. El modelo arquitectónico da la base
de nuestro modelo de seguridad:
la seguridad de un sistema distribuido puede lograrse asegurando los procesos y los canales empleados
para sus interacciones y protegiendo los objetos que encapsulan contra el acceso no autorizado.
La protección se describe en términos de objetos, aunque los conceptos se aplican tal cual a recursos de
todos los tipos.
Protección de objetos. La Figura 2.13 muestra un servidor que administra un conjunto de objetos en
beneficio de algunos usuarios. Los usuarios pueden lanzar programas cliente que envían invocaciones al
servidor para realizar operaciones sobre los objetos. El servidor realiza la operación indicada en cada
invocación y envía el resultado al cliente.
Los objetos están construidos para ser usados de formas diferentes por usuarios diferentes. Por ejemplo,
algunos objetos podrían incluir datos privados de un usuario, tales como un buzón de correo, y otros objetos
pueden incluir datos compartidos como páginas Web. Para dar soporte a esto los derechos de acceso
especifican a quién se permite realizar ciertas operaciones de un objeto, por ejemplo, a quién se permite leer
o escribir su estado.
Así, debemos incluir a los usuarios en nuestro modelo como los beneficiarios de los derechos de acceso.
Esto se realiza asociando a cada invocación y a cada resultado la autoridad con que se ordena. Tal autoridad
se denomina principal. Un principal pudiera 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 tras cada invocación y comprobar que
dispone de los suficientes derechos de acceso como para realizar la operación requerida sobre el objeto
particular invocado, rechazando aquellas que no dispongan de ellos. El cliente puede comprobar la identidad
del principal tras el servidor para asegurar que el resultado proviene del servidor requerido.
Asegurar procesos y sus interacciones. Los procesos interaccionan enviando mensajes. Los mensajes están
expuestos a un ataque dado que la red y el servicio de comunicación que usan es abierto, de modo que
cualquier par de procesos puedan interactuar. Los servidores y procesos parejos exponen sus interfaces,
permitiendo ser el destino de los mensajes de otros procesos.
 Modelos de sistema 55

Los sistemas distribuidos se despliegan y usan, probablemente, en tareas propensas a ser objetivo de
ataques externos por usuarios hostiles. Esto es especialmente cierto en aplicaciones que tratan con
transacciones financieras, confidenciales o con información clasificada o cualquier otra in formación cuya
privacidad e integridad sea crucial. La integridad se ve amenazada por las violaciones de seguridad así
como por fallos de la comunicación. Es así que sabemos que probablemente habrá ataques a los procesos
de los que se componen tales aplicaciones y a los mensajes que viajan entre los procesos. Pero, ¿cómo
podemos analizar estas amenazas para identificarlas y derrotarlas? La siguiente discusión presenta un
modelo para el análisis de amenazas de seguridad.

El enemigo. Para modelar amenazas de seguridad, postulamos que el enemigo (también conocido como
adversario) es capaz de enviar cualquier mensaje a cualquier proceso y también de leer o copiar cualquier
mensaje entre un par de procesos, como se muestra en la Figura 2.14. Tales ataques pueden cometerse
simplemente utilizando un computador conectado a una red para lanzar un programa que lea los mensaje s
de la red dirigidos a otros computadores de la misma red, o un programa que genere mensajes que realicen
peticiones falsas a servicios dando a entender que provienen de usuarios autorizados. El ataque puede
provenir de un computador legítimamente conectado a la red o también de alguna conectada de forma no
autorizada.
Las amenazas de un enemigo potencial se discutirán según los siguientes apartados: amenazas
a procesos, amenazas a los canales de comunicación y denegación de servicio.

Amenazas a procesos: Cualquier proceso diseñado para admitir peticiones puede recibir un mensaje de
cualquier otro proceso del sistema distribuido, y bien pudiera no ser capaz de determinar la identidad del
emisor. Los protocolos de comunicación como IP incluyen la dirección del computador origen de cada
mensaje, pero no es problema para un enemigo el generar un mensaje con una dirección fuente falsa. Esta
carencia de conocimiento fiable del origen de un mensaje es una amenaza al correcto funcionamiento, tanto
de los servidores como de los clientes, tal y como se explica a renglón seguido:

Figura 2.14. El enemigo.

Sistemas distribuidos

Servidores: dado que un servidor puede recibir invocaciones de muchos clientes diferentes, no
necesariamente puede determinar la identidad del principal que se halla tras cualquier invocación
particular. Incluso si un servidor requiere la inclusión de la identidad del principal en cada invocación,
un enemigo podría generar una invocación con una identidad falsa. Sin un conocimiento fiable de la
identidad del emisor, un servidor no puede decir si realizar la operación o rechazarla. Por ejemplo, un
servidor de correo pudiera no saber si el usuario tras una invocación que recupera un correo de un buzón
particular está autorizado para ello, o si era una petición de un enemigo.
Clientes: cuando un cliente recibe el resultado de una invocación de un servidor, no necesariamente
puede decir si la fuente del mensaje resultado es del servidor que se pretendía o de un enemigo, quizás
uno que esté suplantando (spoofing) el servidor de correo. Entonces el cliente pudiera recibir un
resultado no relacionado con la invocación original, tal como un correo falso (uno que no esté en el
buzón de correo del usuario).
Amenazas a los canales de comunicación: Un enemigo puede copiar, alterar o insertar mensajes según
viajan a través de la red y sus pasarelas intermedias. Tales ataques presentan una amenaza a la privacidad y a
la integridad de la información según ésta viaja a través de la red, y a la integridad del sistema. Por ejemplo,
un mensaje resultado que contenga un correo de un usuario pudiera ser visto por otro usuario o podría ser
convertido en algo bastante diferente.
Otra forma de ataque es la pretensión de hacer acopio de mensajes para volver a enviarlos más tarde,
haciendo posible volver a usar el mismo mensaje una y otra vez. Por ejemplo, alguien podría beneficiarse de
un mensaje en el que se invoca una petición de transferencia de dinero de una cuenta bancaria a otra.
Todas estas amenazas pueden vencerse empleando canales seguros, como los que se describen más
adelante y que se basan en la criptografía y la autenticación.

Vencer amenazas de seguridad. Aquí presentamos las técnicas principales en que se basan los sistemas
seguros. El Capítulo 7 discute el diseño y la implementación de sistemas distribuidos seguros con cierto
detalle.
Criptografía y secretos compartidos: Suponga que un par de procesos (por ejemplo un cliente y un
servidor concretos) comparten un secreto; es decir, ningún proceso del sistema distribuido aparte de ellos
conoce este secreto. Entonces, si se intercambia un mensaje entre estos dos procesos e incluye información
que demuestra el conocimiento, por parte del emisor, de este secreto compartido, tenemos que el receptor
podrá estar seguro de quién es el que ha emitido el mensaje. Obvia mente, es preciso tener cuidado para que
el secreto compartido no sea revelado a un enemigo.
La criptografía es la ciencia de mantener los mensajes seguros, y la encriptación es el proceso de
trastocar el mensaje de modo que quede oculto el contenido. La criptografía moderna se basa en algoritmos
de encriptación que emplean claves secretas (números grandes difíciles de deducir) para transformar los
datos, de forma que sólo se pueda revertir el proceso con la clave de desencriptado correspondiente.
Autenticación: El uso de los secretos compartidos y la encriptación presenta la base de los mensajes de
autenticación, probando las identidades proporcionadas por sus emisores. La técnica básica de autenticación
consiste en incluir en un mensaje un fragmento encriptado que contenga suficiente contenido del mensaje
como para garantizar su autenticidad. La porción de autenticación de una petición a un servidor de archivos,
pongamos que para leer parte de un archivo, podría incluir una representación de la identidad del principal
solicitante, la identidad del archivo y la fecha y hora de la petición, todo encriptado con una clave secreta que
comparten el servidor de archivos y el proceso solicitante. El servidor lo desencriptaría y comprobaría que se
corresponde con los detalles no encriptados que se especifican en la petición.
 Modelos de sistema 57

Figura 2.15. Canales seguros

Canales seguros: La encriptación y la autenticación se emplean para construir canales seguros en forma
de 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 representación de un
principal, según se muestra en la Figura 2.15. Un canal seguro presenta las siguientes propiedades:
• Cada proceso conoce bien la identidad del principal en cuya representación se ejecuta otro proceso.
De este modo si un cliente y un servidor se comunican vía un canal seguro, el servidor conoce la
identidad del principal tras las 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 al
cliente estar seguro de estar recibiendo resultados de un servidor que actúa de buena fe.
• Un canal seguro asegura la privacidad y la integridad (protección contra la manipulación) de los datos
transmitidos por él.
• Cada mensaje incluye un sello de carácter temporal, de tipo físico o lógico, para prevenir el reenvío o
la reordenación de los mensajes.
La construcción de canales seguros se discutirá con detalle en el Capítulo 7. Los 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. Las redes privadas virtuales (VPN, que se verán en el Capítulo 3) y el protocolo de
capa de sockets segura (SSL, Secure Sockets Layer) son ejemplos de canales seguros.
Otras posibilidades de amenaza de un enemigo. La Sección 1.4.3 presentó brevemente dos amenazas de
seguridad, los ataques de denegación de servicio y el despliegue de código móvil. Veamos otra vez este
tipo de ataques desde el punto de vista de las posibilidades que se le ofrecen al enemigo de dificultar las
actividades de los procesos:
Denegación de servicio: ésta es una forma de ataque en la que el enemigo interfiere con las actividades
de los usuarios autorizados mediante un número excesivo de invocaciones sin sentido sobre servicios o
la red, lo que resulta en una sobrecarga de los recursos físicos (ancho de banda, capacidad de
procesamiento del servidor). Tales ataques suelen tener el fin de retrasar o impedir las acciones de los
otros usuarios. Por ejemplo, podría desconectarse la operación de las cerraduras electrónicas de una
edificación por medio de un ataque que sature el computador que las controla con peticiones inválidas.

Código móvil: el código móvil despierta nuevos e interesantes problemas para cualquier proceso que
reciba y ejecute código de programas proveniente de algún otro sitio, tal como los anexos a los correos
electrónicos mencionados en la Sección 1.4.3. Tal código podría jugar fácilmente el papel de caballo
de Troya, pretendiendo cumplir con un objetivo inocente pero, de hecho, incluyendo código que
accede o modifica los recursos que están disponibles legítima mente para los procesos del host, pero no
para el creador del código. Los métodos mediante los
58 Sistemas distribuidos

cuales es posible llevar a cabo tales ataques son muchos y variados, en consecuencia el entorno del host
debe construirse cuidadosamente para evitarlos. Muchas de estas cuestiones han sido tenidas en cuenta
en Java y otros sistemas de código móvil, pero la historia reciente sobre el tema muestra la desnudez de
algunas debilidades bastante embarazosas. Esta cuestión muestra la necesidad de realizar un análisis
riguroso sobre el diseño de todos los sistemas seguros.
Aplicaciones de los modelos de seguridad. Pudiera pensarse que obtener sistemas distribuidos seguros
debiera ser un asunto evidente que implica el control del acceso a los objetos según permisos de acceso
predefinidos y el empleo de canales de comunicación seguros. Desgraciadamente, no siempre es éste el
caso. El empleo de técnicas de seguridad como la encriptación y el control de acceso conlleva un coste de
procesamiento y administración sustancial. El modelo de seguridad esquematizado anteriormente da las
bases del análisis y el diseño de sistemas seguros en los que se mantienen los costes al mínimo; pero las
amenazas a un sistema distribuido se presentan desde muchos flancos, y se hace necesario un análisis
cuidadoso de estas amenazas, que pudieran provenir de todas las fuentes posibles en el entorno de red del
sistema, el entorno físico y el entorno humano. Este análisis involucra la construcción de un modelo de
amenazas que tabula todas las formas de ataque a las que se encuentra expuesto el sistema y una evaluación
de los riesgos y consecuencias de cada uno. La efectividad y el coste de las técnicas de seguridad necesarias
pueden entonces ser contrapesadas con las amenazas.

La mayoría de los sistemas distribuidos se componen de una o más variedades de modelos de arquitectura.
El modelo cliente-servidor es el más usado; el Web y otros servicios Internet tales como ftp, news y mail así
como el DNS se basan en este modelo, así como el sistema local de archivos y otros más. Los servicios
como DNS que tienen un número de usuarios grande y tratan con una gran cantidad de información se basan
en múltiples servidores, el uso de particiones sobre los datos y la replicación para facilitar la disponibilidad
y la tolerancia frente a fallos. El uso de caché en los clientes y servidores proxy se encuentra ampliamente
extendido para mejorar las prestaciones de un servicio. En el modelo de procesos de igual a igual, los
procesos de aplicaciones distribuidas se comunican uno con otro directamente sin emplear servidores
intermediarios.
La posibilidad de mover código de un proceso a otro ha desembocado en algunas variantes del modelo
cliente-servidor. El ejemplo más común de esto es el applet cuyo código es aportado por un servidor Web
para ejecutarse en un cliente, proporcionando funcionalidades no disponibles en el cliente y la mejora de
ciertas prestaciones debido a la proximidad con el cliente.
La existencia de computadores portátiles, PDA y otros dispositivos digitales y su integración en los
sistemas distribuidos permite que los usuarios accedan a servicios locales y de Internet, aunque estén lejos
de su computador de sobremesa. La presencia de dispositivos de computación con posibilidades de
comunicación inalámbrica en aparatos cotidianos como las máquinas lavadoras o las alarmas antirrobo les
permite dar servicios accesibles desde una red inalámbrica en el hogar. Una característica de los dispositivos
móviles de los sistemas distribuidos es que pueden estar conectados o desconectados impredeciblemente,
conduciendo a requisitos de descubrimiento de servicios mediante los que los servidores móviles puedan
ofrecer sus servicios y los clientes móviles buscarlos.
Hemos presentado modelos de interacción, fallo y seguridad que identifican las características comunes
de los componentes básicos con que se construyen los sistemas distribuidos. El modelo de interacción tiene
que ver con las prestaciones de los procesos y los canales de comunicación, y con la ausencia de un reloj
global. También define un sistema asíncrono como uno en el que no hay límites en el tiempo de ejecución
de un proceso, el tiempo de reparto de un mensaje, y la deriva de los relojes; siendo así como se comporta
Internet.