Académique Documents
Professionnel Documents
Culture Documents
Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas
Distribuidos.
Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el
estudio de la misma. Es conveniente disponer de la bibliografa propuesta por la Universidad para su
estudio completo.
Cualquier sugerencia, comentario o correccin sobre este documento, envelo a david.rgh@gmail.com
para poder realizar los cambios necesarios.
INTRODUCCIN
Qu es un sistema distribuido? No es ms que aquel sistema cuyos componentes (tanto software
como hardware) se encuentran localizados en distintas computadoras unidas a travs de una red y que
se comunican y coordinan entre s mediante el paso de mensajes.
Esta definicin tiene algunas implicaciones, como la concurrencia; es decir, varios usuarios trabajando
desde sus propios ordenadores pueden tener acceso simultneo a los mismos recursos del sistema. Esto
es importante, ya que el sistema debe poder gestionar bien la coordinacin entre estos accesos.
Adems, como cada ordenador funciona aparte del resto (aunque conectados entre s todos), no existe
una nocin global del tiempo, manteniendo cada uno sus propios registros. As pues, debe poder
sincronizarse de alguna forma.
Se mantiene relativamente un concepto de individualidad, incluso en los fallos. Si uno de los
ordenadores falla, el resto de ordenadores del sistema debe poder seguir trabajando.
Qu es un recurso? Es algo que se comparte entre los ordenadores de la red. Puede ser algo fsico,
como un disco duro y su capacidad de almacenamiento; o no, como un fichero o una base de datos.
Internet:
Quizs el ms conocido. Se compone de diversos tipos de computadores
interconectados. stos se comunican mediante el paso de mensajes, que debe ser posible por
los mecanismos de comunicacin. Algunos servicios de este sistema son la WWW (World Wide
Web) (Cuidado: no confundir WWW con Internet), el correo electrnico o la transferencia de
ficheros (FTP). Los usuarios se conectan a Internet gracias a un ISP (Internet Service Provider),
que proporciona la conexin de su computador con la intranet de la empresa que acta como
ISP. Esta intranet, a su vez, tiene acceso a Internet.
Intranets: Consiste en una porcin de Internet, administrada por separado. Suele pertenecer a
una empresa, que establece los lmites necesarios para mantener su poltica. Los ISPs poseen
intranets que utilizan para conectar a sus clientes a Internet, a travs de un router. Adems,
puede ofrecer sus propios servicios, que pueden estar inaccesibles desde fuera de la intranet
(ej: almacenamiento y visualizacin de datos clnicos de los pacientes de un hospital). Suelen
disponer tambin de un cortafuegos, que filtra los mensajes de entrada y salida de la intranet
con el fin de protegerse de programas nocivos.
Una intranet tambin puede estar aislada completamente de Internet, siendo slo accesible
desde dentro de la misma (en este caso, no es necesario el uso de un cortafuegos).
Computacin mvil y ubicua: Los ordenadores (entindase de sobremesa) no son los nicos
que se conectan a los sistemas distribuidos. Poco a poco van proliferando el uso de dispositivos
mviles, como los ordenadores porttiles, los telfonos mviles, las PDAs Estos dispositivos
pueden viajar entre redes, de forma que no estn conectados siempre a la misma red. Esto se
conoce como computacin mvil.
La computacin ubicua consiste en integrar el uso de la informtica y los dispositivos
inteligentes en la vida ordinaria, de forma que el usuario los use de una forma totalmente
natural. La rama ms avanzada es la domtica (viviendas automatizadas) que tantas veces se
han visto en pelculas de ciencia-ficcin, pero cuya realidad no est tan alejada como pudiera
creerse. La vivienda est dotada de dispositivos inteligentes capaces de reaccionar a su entorno
(ej: controlar la iluminacin de una sala en funcin de la actividad detectada).
URL: Universal Resource Link. Se trata de un identificador que refiere de forma universal y
unvoca a un recurso concreto de la Web. Se compone de un esquema y de la localizacin
especfica. El primero puede ser mailto, ftp y el segundo puede ser una direccin de correo
electrnico, una direccin web
Como ya se dijo antes, pueden introducirse nuevos tipos de recursos, que pasarn a utilizar un
esquema propio. Evidentemente, los navegadores deben incluir (o instalar con ellos) una
aplicacin que pueda leer el nuevo tipo de recurso.
El esquema de URL ms conocido es, probablemente, el HTTP. Es de la forma:
http://nombredelservidor[:puerto][/pathdelservidor][?argumentos]
En la pgina 12 del libro base se pueden encontrar algunos ejemplos de URL. Las URL HTTP
pueden incluir anclas (#), que hacen referencia a una parte concreta del documento,
permitiendo al usuario ir directamente a esa parte.
Para publicar un nuevo recurso, el usuario debe colocar el fichero en una carpeta accesible del
servidor; de forma que se puede posteriormente componer la URL adecuada y publicarla en
otro documento.
Tipos de contenido: El cliente especifica, junto con su solicitud, el tipo de archivos que
prefiere (por ejemplo, puede preferir un formato GIF y no un JPEG); de forma que el
servidor lo puede tener en cuenta a la hora de responder a la peticin (en la respuesta
incluir el tipo de contenido para que el cliente sepa cmo procesarlo; esta
informacin se conoce como tipos MIME). Pueden verse algunos ejemplos en la
pgina 13 del libro base.
Un recurso por solicitud: Por cada recurso deseado, se realizar una solicitud distinta
(ej: un documento con 9 imgenes necesitar 10 solicitudes (una por cada imagen y
otra por el propio documento)). Esto es as en la versin 1.0 de HTTP.
Control de acceso simple: Cualquier usuario con una conexin de red a un servidor
web tendr acceso a cualquiera de los recursos publicados en dicho servidor. Sin
embargo, un servidor puede ser configurado para limitar el acceso (por ejemplo,
mediante un sistema de contraseas).
Todo lo anterior ha hecho referencia a documentos estticos, donde si hay algn cambio se realiza de
forma permanente para todos los posibles clientes. Sin embargo, determinados documentos requieren
un formato personalizado (por ejemplo, la confirmacin de los datos personales de una persona en una
tienda online). Por otra parte, algunos documentos se componen de formularios (ej: la pgina de
registro de un sitio web) que deben poder procesar los datos introducidos (esto es, se envan dichos
datos al servidor).
Para poder presentar estos datos se necesita un programa que genere el cdigo dinmico de los
resultados. Se le suele conocer como CGI (Common Gateway Interface). Este programa se ejecuta en el
servidor.
Sin embargo, otros tipos de cdigo, como el Javascript, se descargan junto al documento y se ejecutan
en el cliente (ej: validacin bsica de datos de formulario o modificar algunas partes del documento), lo
cual acorta el tiempo de espera; aunque es bastante limitado. Para salvar esta limitacin, tenemos los
applets, que son programas escritos en Java y que se descargan al cliente, donde se ejecutan. Los
applets pueden tener acceso a la red (ej: chat incrustado en una pgina web).
El xito de la Web es la facilidad de publicacin de recursos. Sin embargo, tiene algunos inconvenientes,
como por ejemplo los enlaces rotos (si se modifica un recurso puede que los enlaces hacia l queden
intiles) o la confusin que puede suponer a un usuario seguir demasiados enlaces.
Por otra parte, HTML es un lenguaje muy limitado en un mundo en el que se requiere un intercambio de
muchos tipos de datos estructurados cada vez ms creciente. Adems, los servidores pueden tener
demasiados accesos simultneos, con lo que se ralentiza el acceso a los usuarios.
DESAFOS
HETEROGENEIDAD
Las redes y computadores accesibles por Internet son muy heterogneos (variados y diferentes). Esta
heterogeneidad se aplica a redes, hardware, sistemas operativos, lenguajes de programacin y
diferentes implementaciones.
Los protocolos de Internet permiten la interconexin entre ellos. Tngase en cuenta que distinto
hardware puede tener distinta representacin para un tipo de dato, al igual que distintos lenguajes de
programacin.
En cuanto a las implementaciones, se necesita el acuerdo de una serie de estndares.
El middleware es un tipo de software que permite encapsular la implementacin de las aplicaciones,
permitiendo que dos programas distintos o en redes distintas puedan comunicarse entre s. Algunos
ejemplos son CORBA y Java RMI. Es una herramienta til adems para los desarrolladores, para poder
crear aplicaciones distribuidas utilizando las invocaciones remotas que proporciona el middleware.
Se conoce como cdigo mvil a aquel que puede enviarse desde un computador a otro y ejecutarse en
el destino. El problema es que dicho cdigo puede no ser entendido por el destino para su ejecucin.
Esto queda solucionado mediante las mquinas virtuales; es decir, se crea cdigo para una mquina
virtual en lugar de para un hardware concreto. Esta mquina virtual (por ejemplo, JVM (Java Virtual
Machine)) traduce el cdigo para el hardware en cuestin (esta solucin no se puede aplicar de modo
general a otros lenguajes).
EXTENSIBILIDAD
Consiste en el grado en que se puede extender y reimplementar con variaciones. En un sistema
distribuido est determinado por el grado en que se pueden aadir nuevos servicios de comparticin de
recursos y publicarlos. Para ello, la documentacin debe estar disponible para los desarrolladores. Los
protocolos de Internet tienen su documentacin en los llamados RFC (Request For Comments), aunque
no son los nicos.
Se conoce como sistema distribuido abierto a aquel sistema diseado para dar soporte a la
comparticin de recursos. La extensin del sistema puede ser por hardware o por software. Sus
interfaces estn publicadas y estos sistemas se basan en la providencia de un mecanismo de
comunicacin uniforme. Como ya se dijo antes, puede construirse con hardware y software
heterogneos, utilizando para ello estndares.
SEGURIDAD
Esta propiedad es vital, pues los recursos pueden tener un gran valor. Tiene 3 componentes:
confidencialidad (impedir accesos no autorizados), integridad (no se modifican los datos) y
disponibilidad (impide el bloqueo del acceso).
En las peticiones, se transmite informacin sensible por la red, que debe tener una cierta seguridad,
adems de asegurarse de que el interlocutor es quien dice ser. Las tcnicas de encriptacin pueden dar
esta seguridad.
Sin embargo, tenemos estos otros problemas:
Seguridad del cdigo mvil: La transmisin de cdigo por la red supone un riesgo para quien
lo recibe. No son pocos los que han sido infectados por cdigo maligno que estaba adjunto en
un correo electrnico.
ESCALABILIDAD
Para que un sistema sea escalable, debe conservar su efectividad cuando se aumenta significativamente
los recursos y usuarios. Un ejemplo de un sistema escalable es el propio Internet.
Un problema existente es el coste de los recursos fsicos, necesarios cuando la demanda de los recursos
(software) aumenta. Por ejemplo, aadir servidores redundantes que puedan balancear la carga de
trabajo de las peticiones.
Adems, extender un sistema puede suponer una prdida de prestaciones, la cual debe ser controlada y
minimizada.
Un recurso puede verse desbordado con la extensin. Por ejemplo, las direcciones IP actuales (IPv4) son
limitadas y se agotan con el rpido crecimiento de usuarios, lo que requiere una ampliacin (IPv6).
La carga debera estar bien balanceada, para evitar problemas de cuellos de botella.
TRATAMIENTO DE FALLOS
Los sistemas fallan, es una realidad. Deben minimizarse sus efectos.
Algunos fallos son detectables, lo cual permite prevenirlos y evitar que sucedan. Por ejemplo, las sumas
de comprobacin (checksum) permiten detectar datos corruptos de un archivo. Otros fallos pueden
ocultarse al usuario (por ejemplo, mediante la redundancia de discos se logra que un dato corrupto sea
servido por el disco que contiene el correcto).
No todos los fallos pueden ocultarse o enmascararse, y supondra un gasto elevado. Por ello, se admite
una cierta tolerancia segn el sistema. Es muy importante tambin disponer de un buen sistema de
recuperacin de fallos, de forma que los datos puedan volver a un estado consistente tras un fallo (ej:
rollback).
CONCURRENCIA
Una consecuencia directa de la comparticin de recursos es la posibilidad del acceso concurrente de
varios usuarios a un mismo recurso. Aunque podra atenderse cada peticin por separado, conllevara a
una prdida de productividad (throughput). Por ello se utilizan threads para ejecutar concurrentemente
el contenido de un objeto en que se encapsula el recurso en cuestin. Las operaciones realizadas deben
estar bien sincronizadas.
TRANSPARENCIA
Consiste en ocultar al usuario la separacin de los componentes distribuidos, de forma que perciba una
sola unidad. Tenemos los siguientes tipos de transparencia:
De acceso: Se accede de la misma forma a recursos locales que a remotos. Por ejemplo, las
carpetas de una GUI se muestran igual tanto si son locales como remotas.
De concurrencia:
recurso.
De replicacin: Puede utilizarse varias (miles) de copias de un recurso para aumentar las
prestaciones (el usuario no es consciente de ello).
Frente a fallos: Oculta los fallos a los usuarios y a las aplicaciones de usuario, permitiendo que
continen su tarea.
De movilidad:
forma).
De prestaciones: Permite reconfigurar el sistema para balancear las cargas segn el estado.
De estos, los ms importantes son los 2 primeros. Por ejemplo, un URL tiene transparencia de ubicacin,
ya que da igual la localizacin fsica del recurso, ya que el URL designa un identificador nico que luego
debe traducirse. Sin embargo, no tiene transparencia de movilidad, ya que si se reubica el recurso, sus
enlaces quedan intiles. Pueden verse varios ejemplos en la pgina 23 del libro base.
MODELOS ARQUITECTNICOS
Se conoce como arquitectura del sistema a la estructura de componentes del mismo.
De una manera simplista, se podra desglosar un sistema distribuido en servidores, clientes e iguales.
Los dos primeros ya se explicaron en los apartados anteriores. Los iguales son aquellos procesos que
cooperan entre s ponerse uno por encima del otro.
Recordemos que puede realizarse cdigo mvil, que se descargan del servidor al cliente para ejecutarse
all.
CAPAS DE SOFTWARE
Los sistemas distribuidos se estructuran en capas, como puede verse en la figura de la pgina 30.
Se conoce como plataforma al nivel de hardware y las capas ms bajas del software. Su funcin es servir
a las capas superiores con independencia del computador utilizado. Una parte de la plataforma es el
sistema operativo, que acta de interfaz con las capas superiores.
Se conoce como middleware a una capa de hardware que permite realizar una interconexin entre
capas de forma homognea; es decir, enmascara las capas inferiores para que la capa superior no tenga
que preocuparse de la implementacin de stas. Proporciona bloques tiles que sirven para que los
componentes software puedan interactuar con los sistemas distribuidos.
Como ejemplos de middleware, podemos nombrar las llamadas a procedimientos remotos (RPC)
(fueron de los primeros), CORBA, RMI, DCOM.
Tambin puede proporcionar servicios para que las aplicaciones de servicios los utilicen (ej: CORBA
ofrece funciones como la gestin de nombres, seguridad, transacciones, almacenamiento persistente).
Muchas aplicaciones dependen del middleware para su correcto funcionamiento, pero algunos aspectos
de la confiabilidad an requieres soporte al nivel de aplicacin (puede verse un ejemplo en la pgina
31). El funcionamiento correcto depende de las comprobaciones en los diversos niveles, no solo en el
middleware.
ARQUITECTURAS DE SISTEMA
Una de las caractersticas principales de un sistema distribuido es el reparto de tareas entre sus
componentes. A continuacin veremos los modelos arquitectnicos principales. Es conveniente
acompaar esta parte con las ilustraciones del libro base desde la pgina 32 hasta la 39:
Procesos de igual a igual: Peer to Peer. Todos los procesos funcionan de forma simtrica e
interactan entre ellos para cooperar para llevar a cabo una determinada tarea. En este caso
no existe proceso servidor.
Cdigo mvil: Ya hemos hablado antes de esto. Un ejemplo de cdigo mvil es un applet de
Java. Con ello se puede extender la funcionalidad de la aplicacin cliente (ej: navegador web)
aadiendo otras que no realiza de forma bsica. Recurdese que el cdigo mvil es un riesgo
de seguridad para el computador destino; aunque los navegadores suelen limitar el acceso de
dicho cdigo a los recursos locales.
Agentes mviles: Se trata de un proceso que, para llevar a cabo su tarea, se traslada entre
varios computadores (ej: una aplicacin que recolecte informacin o una aplicacin que pueda
instalar componentes en varios computadores). Igualmente representan un riesgo para los
computadores visitados.
Clientes ligeros: Es una capa de aplicacin con una interfaz de ventanas sobre un computador
local que ejecuta programas de aplicacin en un computador remoto. Se diferencia del anterior
en que no se descarga el cdigo de las aplicaciones, sino que se ejecutan en el servidor
(servidor de cmputo). Su mayor problema est en aplicaciones grficas con una interaccin
fuerte (ej: CAD), que ralentiza excesivamente su uso.
La mayora de variantes de UNIX usan el sistema de ventanas X-11. En la pgina 37 del libro
pueden verse algunos ejemplos.
Dispositivos mviles y enlace espontneo a red: Recordemos que hay infinidad de dispositivos
que pueden conectarse a la red: PDA, mviles, chips de domtica Un sistema distribuido
puede dar soporte para la computacin mvil que permite a estos dispositivos conectarse a los
recursos locales y remotos.
Se conoce como enlace a red espontneo a aplicaciones que usan conexiones de una manera
ms informal (ej: PDA con geolocalizacin o servicios locales como la Web). Vanse varios
ejemplos en la pgina 38. Las caractersticas esenciales son:
o
Integracin fcil con servicios locales: Un dispositivo que se mueva entre redes
existentes de dispositivos, detecta automticamente qu servicios proporcionan los
dispositivos a los que se conecta. Un ejemplo comn son los servicios bluetooth de un
telfono mvil: detecta los servicios que proporcionan otros dispositivos bluetooth
cercanos.
Todo esto conlleva sus problemas, como puede ser la desconexin temporal, por ejemplo, si se
atraviesa un tnel, en la que el usuario debera poder seguir trabajando. Adems, hay
problemas de seguridad por la proximidad de la conexin de otros dispositivos (en el ejemplo
del bluetooth, otro telfono cercano podra acceder al nuestro si no se establecen medidas de
seguridad).
Se conoce como servicio de deteccin o servicio de descubrimiento a aquel servicio que se
encarga de aceptar y almacenar detalles de los servicios disponibles en la red a la que est
conectado, as como responder consultas de otros dispositivos. Esto, por ejemplo, lo hacemos
cada vez que en nuestro telfono solicitamos hacer un barrido en busca de dispositivos
cercanos. Tiene dos interfaces:
o
INTERFACES Y OBJETOS
Se conoce como definicin de interfaz a la especificacin del conjunto de funciones que se puede
invocar sobre el proceso en cuestin. En los lenguajes orientados a objetos, los procesos pueden
encapsular un gran nmero de objetos y comunicarse con otros procesos a travs de estas interfaces (a
travs de invocaciones remotas), esta es la aproximacin aportada por CORBA y Java con el RMI.
REQUISITOS DE DISEO PARA ARQUITECTURAS DISTRIBUIDAS
Cuando comenz a extenderse la disponibilidad de redes de computadores de prestaciones medias, la
comparticin de recursos se asumi como normal. Pero compartir datos en gran escala an es un reto.
En cuanto a las prestaciones, podemos considerar los siguientes puntos:
Respecto a la calidad del servicio, se ve afectada por la fiabilidad, la seguridad y las prestaciones.
Tambin es importante la facilidad de adaptacin (adaptability). Los dos primeros son crticos.
Muchos sistemas tienen determinados datos que deben transferirse en un tiempo determinado (ej:
detector de humos que permite activar el sistema de extincin de incendios). La calidad del servicio
(QoS, Quality of Service) es la capacidad del sistema para satisfacer estos tiempos lmite. Una excesiva
carga en el sistema deteriora sus prestaciones y, por tanto, la calidad. Se debe garantizar que los
recursos crticos estn reservados para las aplicaciones que requieren QoS.
Por lo que respecta al uso de cach y de replicacin, ya habamos comentado las ventajas de la cach
para disminuir los tiempos de respuesta. sta almacena los recursos que se han utilizado, de forma que
el siguiente servicio que use dichos recursos se ejecuta ms rpido, al no tener que esperar el envo
desde el servidor original. En la Web, esta cach puede ser del navegador o del proxy (si existe). Si el
recurso no est actualizado (se valida con el servidor original) ser entonces cuando se vuelva a recurrir
al servidor para obtener la ltima actualizacin.
Los recursos de la cach y el proxy suelen tener unos tiempos de expiracin, que permite comprobar si
un recurso est obsoleto, realizando un clculo con su edad en contraposicin al tiempo de expiracin.
Por ltimo, la fiabilidad es un requisito crucial. De este requisito pueden llegar a depender vidas,
aspectos econmicos, seguridad de datos personales etc. Podemos analizar algunos aspectos
importantes:
Tolerancia frente a fallos: Se puede conseguir fiabilidad mediante redundancia. Los recursos
pueden estar duplicados en mltiples servidores, por lo que se logran varios caminos de
comunicacin y que las aplicaciones se reconfiguren automticamente para conectar a uno o a
otro. Es algo costoso y limitado. Las aplicaciones crticas (ej: control areo) requieren un alto
grado de fiabilidad, por lo que el coste de mantenimiento es muy elevado. En las
comunicaciones se logra fiabilidad con otras tcnicas, como el uso de reconocimientos (ACK)
para las transmisiones.
MODELOS FUNDAMENTALES
Todos los modelos descritos anteriormente comparten el hecho de que se componen de procesos que
se comunican mediante mensajes por la red y siguen los principios de diseo que hemos comentado.
Un modelo tiene slo lo esencial para entender y razonar sobre algunos aspectos del comportamiento
del sistema y debe tratar de definir las entidades del sistema y su interaccin, adems de las
caractersticas que les afectan.
Nos permite conocer las premisas sobre los sistemas, y as podemos valorar si son vlidas sobre una
implementacin concreta. As, podemos razonar sobre la interaccin entre los procesos del sistema
(comunicacin por paso de mensajes) (debe reflejar los retrasos y la precisin de coordinacin), los
fallos que estn definidos y clasificados por el modelo (permite analizarlos y disear sistemas
tolerantes) y la seguridad (se definen y clasifican los posibles ataques con el fin de poder combatirlos).
Veamos algunos modelos simples:
MODELO DE INTERACCIN
Los sistemas se componen de procesos que interactan entre s. La interaccin puede incluir clientes y
servidores, y tambin puede realizarse entre iguales.
Se conoce como algoritmo distribuido a la definicin de los pasos que hay que llevar a cabo por cada
proceso, incluyendo los mensajes de transmisin entre ellos. Es complicado conocer todos los posibles
estados de los algoritmos distribuidos, ya que depende mucho de los fallos de ellos mismos y de los
procesos con los que se comuniquen.
A los procesos que interactan, les afectan dos factores principalmente.
Por una parte, tenemos las prestaciones de los canales de comunicacin. Hay varias opciones de
canales. Se debe tener en cuenta la latencia (retarde entre el envo de un mensaje y la recepcin de su
respuesta), el ancho de banda (si se usan varios canales, el ancho de banda tiene que ser compartido, lo
que disminuye las prestaciones) y la fluctuacin (variacin del tiempo invertido en completar el reparto
de una serie de mensajes (es importante para los datos multimedia (no debe presentar demasiada
fluctuacin))).
Por otra parte, tenemos los relojes de computadores y eventos de temporizacin. Cada computador
tiene su propio reloj, que casi siempre presentar derivas con respecto a los relojes del resto de
computadores. Se conoce como tasa de deriva del reloj a la proporcin de deriva de un reloj con otro
de referencia que se considere perfecto. Una forma de corregir los tiempos del reloj es mediante un
receptor GPS, que realice lecturas del tiempo de un sistema GPS; pero es una solucin cara para cada
computador (como alternativa, puede haber un servidor que se encargue de esto y transmita el tiempo
al resto de computadores).
En este modelo podemos encontrar dos variantes:
Muchas veces nos interesa saber el orden de los eventos o mensajes (vase el ejemplo de las pginas
48-49 del libro base). Como los sistemas distribuidos no pueden sincronizarse de una forma perfecta,
tenemos el modelo de tiempo lgico, que permite inferir el orden sin recurrir a los relojes (vase el
ejemplo de la pgina 50).
MODELO DE FALLO
Pueden fallar tanto los procesos como el canal de comunicaciones. Tenemos la siguiente clasificacin de
fallos:
Fallos por omisin: No se logran realizar acciones que se supone que se pueden hacer.
o
En la figura 2.11 (pgina 52) puede verse la clasificacin de fallos por omisin.
Fallos arbitrarios: (o fallo bizantino). Puede ocurrir cualquier tipo de error. En el proceso se
omiten pasos deseables para el procesamiento o se realizan pasos no intencionados de
procesamiento. Estos fallos no pueden detectarse por la respuesta a las invocaciones. Pueden
ocurrir corrupcin de datos, envo de mensajes no existentes, repeticin de mensajes
Fallos de temporizacin: Se dan en los sistemas sncronos. Superan los lmites de tiempo
establecidos (vase la clasificacin de la figura 2.12 (pgina 53)). En los asncronos no podemos
hablar de fallos de temporizacin, porque el exceso puede deberse simplemente a un retardo
en la comunicacin. En las comunicaciones multimedia, es imprescindible evitar este tipo de
errores.
Fiabilidad y comunicacin uno a uno: Se conoce como comunicacin fiable a aquella que es
vlida (cualquier mensaje en el buffer de salida llegar al buffer de entrada) e ntegro (no se
duplican ni alteran mensajes). Las amenazas a esta integridad provienen de protocolos que
Proteccin de objetos: Los objetos del servidor tienen una serie de derechos de acceso, que
determinan quin puede invocar qu operaciones del servidor. Los beneficiarios de estos
derechos son los usuarios. Cada invocacin y cada resultado est asociado a la autoridad con la
que se ordena, llamada principal (puede ser un usuario o un proceso (en el ejemplo de la
pgina 55 (Figura 2.13) la invocacin proviene de un usuario y el resultado de un servidor)). El
servidor debe verificar la identidad y derechos del principal que invoca a la operacin. El cliente
debe comprobar la identidad del principal que le enva el resultado.
El enemigo: Debe concebirse al enemigo en los peores casos (enva mensajes a cualquier
proceso, tiene todos los derechos), para hacer un modelo de seguridad fiable. Incluso se debe
prever que el enemigo pueda ser un computador que pertenece a la propia red.
Amenazas a los canales de comunicacin: Los mensajes que se transmiten pueden ser
interceptados en el trayecto, provocando que el atacante los elimine, los altere o los
sustituya por un mensaje propio (vase la Figura 2.14 (pgina 55)). Incluso podra
almacenarse el mensaje para ejecutarlo posteriormente repetidas veces (ej: peticin
de transferencia de dinero). Deben utilizarse canales seguros.
Canales seguros: Es un canal que comunica dos procesos y que cada uno de ellos
conoce bien la identidad del otro. Adems, asegura la privacidad y la integridad y en
cada mensaje se incluye un sello temporal que evita que sea reenviado o reordenado.
Ejemplos de canales seguros son las VPN y el SSL.
Cdigo mvil: El cdigo mvil puede convertirse en un caballo de Troya que pone en
riesgo al destinatario. Aqu hay muchas posibilidades de ataque, por lo que debe
tenerse especial cuidado.