1. INTRODUCCION A LOS SISTEMAS DISTRIBUIDOS 1.1.

EVOLUCIN La historia de la computacin puede ser dividida en tres grandes eras: En los 70: Era del Tiempo Compartido o un computador para varios usuarios Procesamiento central (Hosts): Uno de los primeros modelos de ordenadores interconectados, llamados centralizados, donde todo el procesamiento de la organizacin se llevaba a cabo en una sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores personales. Problemas: Cuando la carga de procesamiento aumentaba se tena que cambiar el hardware del Mainframe, lo cual es ms costoso que aadir ms computadores personales clientes o servidores que aumenten las capacidades. El otro problema que surgi son las modernas interfases grficas de usuario, las cuales podan conllevar a un gran aumento de trfico en los medios de comunicacin y por consiguiente podan colapsar. Mainframes centrales (Sistemas de tiempo compartido, Recursos centralizados) Interfaces de usuario poco amigables Aparecen las primeras redes En los 80: Era de la Computacin Personal o un computador para cada usuario . Grupo de servidores: Entr a competir con el anterior, tambin un tanto centralizado , son un grupo de ordenadores actuando como servidores, normalmente de archivos o de impresin, poco inteligentes para un nmero de minicomputadores que hacen el procesamiento conectados a una red de rea local. Tenan los S.O.Distribuidos: Mach de CMU (1986) Amoeba diseado por Tanenbaum (1984). Chorus de INRIA en Francia (1988). Problemas: Podra generarse una saturacin de los medios de comunicacin entre los servidores poco inteligentes y los minicomputadores, por ejemplo cuando se solicitan archivos grades por varios clientes a la vez, podan disminuir en gran medida la velocidad de transmisin de informacin. PCs y estaciones de trabajo Interfaces amigables Redes de rea local Aparecen los primeros sistemas operativos distribuidos, como Sprite, Chorus, Amoeba. Lectura obligatoria: Amoeba DOS Overview Material de referencia: Chorus DOS Overview Responder: Por qu no se han desarrollado Sistemas Operativos Distribuidos comercia les?

En los 90: Era de la Computacin Paralela o varios computadores para cada usuario . La computacin Cliente Servidor: Este modelo, que predomina en la actualidad, perm ite descentralizar el procesamiento y recursos, sobre todo, de cada uno de los servi cios y de la visualizacin de la Interfaz Grfica de Usuario. Esto hace que ciertos servido res estn dedicados solo a una aplicacin determinada y por lo tanto ejecutarla en forma eficiente. Despegue de las aplicaciones cliente/servidor Ms descentralizacin Enorme difusin de internet gracias al Web Nuevas necesidades y aplicaciones basadas en el Web 1.2. CONCEPTOS BASICOS Un sistema distribuido es aquel en el que los componentes localizados en computa dores, conectados en red, comunican y coordinan sus acciones nicamente mediante el paso de mensajes. Esta definicin lleva a las siguientes caractersticas de los sistemas distribuidos:

concurrencia de los componentes inexistencia de un reloj global fallos independientes de los componentes Concurrencia: en una red de computadores, la ejecucin de programas concurrentes e s la norma. Yo puedo realizar mi trabajo en mi computador, mientras t realizas tu trab ajo en la tuya, compartiendo recursos como pginas web o ficheros, cuando es necesario. La capacid ad del sistema para manejar recursos compartidos se puede incrementar aadiendo ms recurso s (por ejemplo, computadores) a la red. La coordinacin de programas que comparten r ecursos y se ejecutan de forma concurrente es tambin un tema importante y recurrente. Inexistencia de reloj global: cuando los programas necesitan cooperar coordinan sus acciones mediante el intercambio de mensajes. La coordinacin estrecha depende a menudo de una idea compartida del instante en el que ocurren las acciones de los programas. Pe ro resulta que hay lmites a la precisin con lo que los computadores en una red pueden sincron izar sus relojes, no hay una nica nocin global del tiempo correcto. Esto es una consecu encia directa del hecho que la nica comunicacin se realiza enviando mensajes a travs de l a red. Esto tiene como consecuencia problemas de temporizacin.

Fallos independientes: todos los sistemas informticos pueden fallar y los diseador es de sistemas tienen la responsabilidad de planificar las consecuencias de posibles f allos. Los sistemas distribuidos pueden fallar de nuevas formas. Los fallos en la red produ cen el aislamiento de los computadores conectados a l, pero eso no significa que detenga n su ejecucin. De hecho, los programas que se ejecutan en ellos pueden no ser capaces de detectar cuando la red ha fallado o est excesivamente lenta. De forma similar, la parada d e un computador o la terminacin inesperada de un programa en alguna parte del sistema (crash) no se da a conocer inmediatamente a lo dems componentes con los que se comunica. Cad a componente del sistema puede fallar independientemente, permitiendo que los dems continen su ejecucin.

Un sistema distribuido es aqul en el que no puedes trabajar con tu mquina por el fallo de otra mquina que ni siquiera sabas que exista Leslie Lamport 1.3. SISTEMAS CENTRALIZADOS VERSUS SISTEMAS DISTRIBUIDOS CENTRALIZADOS DISTRIBUIDOS Componentes no autnomos Componentes autnomos Construidos utilizando tecnologa homognea Construidos utilizando tecnologa heterognea Mltiples usuarios comparten los recursos centralizados todo el tiempo Los componentes podran ser utilizados exclusivamente por un solo usuario Unico punto de falla y control centralizado Mltiples puntos de falla 1.4. EJEMPLOS DE SISTEMAS DISTRIBUIDOS Y APLICACIONES DISTRIBUIDAS INTERNET

INTRANET

COMPUTACION MOVIL

WEB

APLICACIONES DISTRIBUIDAS:

Sistemas de Control de Trfico Areo Aplicaciones Bancarias Aplicaciones de Comercio Electrnico Aplicaciones Multimedia (Ej. vdeoconferencias) Aplicaciones Mdicas (transferencia de imgenes) 1.5. VENTAJAS Comparticin de informacin y recursos remotos sin necesidad de conocer su ubicacin geogrfica Extensibilidad: capacidad de incorporar nuevos nodos y nuevos servicios de diver sos proveedores. Escalabilidad: capacidad de crecimiento sin afectar a la estructura del sistema Concurrencia: acceso simultneo a recursos compartidos sin interferencias Disponibilidad y Tolerancia a fallos: mantenimiento de los servicios en presenci a de fallos 1.6. DESVENTAJAS Complejidad en el diseo, implementacin y gestin Inseguridad inherente a las comunicaciones Interconexin Alto costo Baja confiabilidad (prdida de mensajes) Saturacin 1.7. DESAFIOS Los desafos que surgen en el diseo e implementacin de sistemas distribuidos son: La heterogeneidad de sus componentes Su carcter abierto o extensibilidad La seguridad La escalabilidad El tratamiento de los fallos La concurrencia de sus componentes La transparencia. HETEROGENEIDAD Internet permite que los usuarios accedan a servicios y ejecuten aplicaciones so bre un conjunto heterogneo de redes y computadores. Esta heterogeneidad (es decir, varie dad y diferencia) se aplica a todos los siguientes elementos: Redes. Hardware de computadores. Sistemas operativos. Lenguajes de programacin. Implementaciones de diferentes desarrolladores. A pesar de que Internet consta de muchos tipos de redes diferentes sus diferenci as se

encuentran enmascaradas dado que todos los computadores conectados a ste utilizan los protocolos de Internet para comunicarse una con otra. Por ejemplo, un computador

conectado a Ethernet tiene una implementacin de los protocolos de internet sobre Ethernet, as un computador en un tipo de red diferente necesitar una implementacin de los protocolos de Internet para esa red. Los tipos de datos, como los enteros, pueden representarse de diferente forma en diferentes clases de hardware por ejemplo, hay dos alternativas para ordenar los bytes en el caso de los enteros. Hay que tratar con estas diferencias de representacin si se va a intercambiar mensajes entre programas que se ejecutan en diferente hardware. Los programas escritos por diferentes programadores no podrn comunicarse entre s a menos que utilicen estndares comunes, por ejemplo para la comunicacin en red y la representacin de datos elementales y estructuras de datos en mensajes. Para que e sto ocurra es necesario concertar y adoptar estndares. CARCTER ABIERTO O EXTENSIBILIDAD La extensibilidad de un sistema de cmputo es la caracterstica que determina si el sistema puede ser extendido y reimplementado en diversos aspectos. La extensibil idad de los sistemas distribuidos se determina en primer lugar por el grado en el cual s e pueden aadir nuevos servicios de comparticin de recursos y ponerlos a disposicin para el u so por una variedad de programas cliente. No es posible obtener extensibilidad a menos que la especificacin y la documentac in de las interfaces software clave de los componentes de un sistema estn disponible s para los desarrolladores de software. Es decir, que las interfaces clave estn publicad as. Sin embargo, la publicacin de interfaces slo es el punto de arranque de la adicin y extensin de servicios en un sistema distribuido. El desafo para los diseadores es h acer frente a la complejidad de los sistemas distribuidos que constan de muchos compo nentes diseados por personas diferentes. Los sistemas diseados de este modo para dar soporte a la comparticin de recursos s e etiquetan como sistemas distribuidos abiertos (open distributed systems) para re marcar el hecho de ser extensibles. Pueden ser extendidos en el nivel hardware mediante la inclusin de computadores a la red y en el nivel software por la introduccin de nue vos servicios y la reimplementacin de los antiguos, posibilitando a los programas de aplicacin la comparticin de recursos. Otro beneficio ms, citado a menudo, de los sistemas abiertos es su independencia de proveedores concretos. En resumen: Los sistemas abiertos se caracterizan porque sus interfaces estn publicadas.

Los sistemas distribuidos abiertos se basan en la providencia de un mecanismo de comunicacin uniforme e interfaces pblicas para acceder a recursos compartidos. Los sistemas distribuidos abiertos pueden construirse con hardware y software heterogneo, posiblemente de diferentes proveedores. Sin embargo, la conformidad c on

el estndar publicado de cada componente debe contrastarse y verificarse cuidadosa mente si se desea que el sistema trabaje correctamente. SEGURIDAD Entre los recursos de informacin que se ofrecen y se mantienen en los sistemas di stribuidos, muchos tienen un alto valor intrnseco para sus usuarios. Por esto su seguridad es de considerable importancia. La seguridad de los recursos de informacin tiene tres c omponentes: Confidencialidad (proteccin contra el descubrimiento por individuos no autorizados) Integridad (proteccin contra la alteracin o corrupcin) Disponibilidad (proteccin contra interferencia con los procedimientos de acceso a los recursos) En un sistema distribuido, los clientes envan peticiones de acceso a datos admini strados por servidores, lo que trae consigo enviar informacin en los mensajes por la red. Ejemplos: Un mdico puede solicitar acceso a los datos hospitalarios de un paciente o enviar modificaciones sobre ellos. En comercio electrnico y banca, los usuarios envan su nmero de tarjeta de crdito a travs de Internet. En ambos casos, el reto se encuentra en enviar informacin sensible en un mensaje, por la red, de forma segura. Pero la seguridad no slo es cuestin de ocultar los contenido s de los mensajes, tambin consiste en conocer con certeza la identidad del usuario u o tro agente en nombre del cual se enva el mensaje. En el primer ejemplo, el servidor n ecesita conocer que el usuario es realmente un mdico y en el segundo, el usuario necesita estar seguro de la identidad del negocio o del banco con el que est tratando. El segund o reto consiste en identificar un usuario remoto u otro agente correctamente. Ambos des afos pueden lograrse a travs de tcnicas de encriptacin desarrolladas al efecto. ESCALABILIDAD Los sistemas distribuidos operan efectiva y eficientemente en muchas escalas dif erentes, desde pequeas intranets a Internet. Se dice que un sistema es escalable si conser va su efectividad cuando ocurre un incremento significativo en el numero de recursos y

el numero de usuarios. Internet proporciona un ejemplo de sistema distribuido en el que el numero de computadores y servicios experimenta un dramtico incremento constante. El diseo de los sistemas distribuidos escalables presenta los siguientes retos: Control del coste de los recursos fsicos: segn crece la demanda de un recurso, deb iera ser posible extender el sistema, a un coste razonable, para satisfacerla. Por ejempl o, la frecuencia

con la que se accede a los archivos de una intranet suele crecer con el incremen to del nmero de usuarios y computadores. Debe ser posible aadir servidores para evitar el embo tellamiento que aparece cuando un solo servidor de archivos ha de manejar todas las peticion es de acceso a stos. Por ejemplo, si un solo servidor de archivos pudiera soportar 20 usuarios , entonces 2 servidores del mismo tipo tendrn capacidad para 40 usuarios. Aunque parezca una m eta obvia, no es tan fcil lograrlo en la prctica. Control de las prdidas de prestaciones: considere la administracin de un conjunto de datos cuyo tamao es proporcional al nmero de usuarios o recursos del sistema, por ejemplo la tabla con la relacin de nombres de dominio de computadores y sus direcciones Internet sustentado por el Sistema de Nombres de Dominio (Domain Nam e System DNS), que se emplea principalmente para averiguar nombres DNS tales como www.amazon.com. Conforme aumenta el nmero de registros de la tabla, aumenta el tiempo de bsqueda del nombre DNS que corresponde a una direccin IP: Prevencin de desbordamiento de recursos software: un ejemplo de prdida de escalabilidad se muestra en las direcciones de Internet IP. A finales de los aos setenta, se decidi emplear para esto 32 bits, pero el suministro de direcciones disponibles p ara Internet esta por desbordarse. La nueva versin del protocolo emplear direcciones Internet de 128 bits. IPv4 (32 bits address) -> IPv6 (128 bits address) A pesar de ello, para ser justos con los primeros diseadores de Internet, no hay una solucin idnea para este problema. Es difcil predecir la demanda que tendr que soportar un sistema con aos de anticipacin. Adems, sobredimensionar para prever el crecimiento futuro pudiera ser peor que la adaptacin a un cambio cuando se hace necesario; las direcciones Internet grandes ocupan espacio extra en los mensajes , y en la memoria de los computadores. Evitacin de cuellos de botella de prestaciones: en general, para evitar cuellos d e botella de prestaciones, los algoritmos deberan ser descentralizados. Ilustramos este pun to aludiendo al predecesor del Sistema de Nombres de Dominio en el cual la tabla de nombres se alojaba en un solo archivo maestro que poda descargarse a cualquier computador que lo necesitara. Esto funcionaba bien cuando slo haba unos cientos de computadores en Internet, pero pronto se convirti en un serio cuello de botella d e prestaciones y de administracin. El Sistema de Nombres de Dominio elimin este cuel lo de botella particionando la tabla de nombres entre servidores situados por todo Internet y siendo administrados localmente. Algunos recursos compartidos son accedidos con mucha frecuencia; por ejemplo, puede que muchos usuarios accedan a la misma pgina

web, causando un declive de las prestaciones. El empleo de cach y replicacin puede mejorar las prestaciones de los recursos que estn siendo muy fuertemente utilizad as. Idealmente, el software de sistema y aplicacin no tiene por qu cambiar cuando la escala del sistema se incremente, pero esto es difcil de conseguir. La cuestin del escalado de un sistema es un tema dominante en el desarrollo de sistemas distrib uidos. Las tcnicas que han demostrado xito incluyen el uso de datos replicados, la tcnica

asociada de cach y la implementacin de mltiples servidores para tratar tareas frecuentes, permitiendo varias tareas similares concurrentemente. TRATAMIENTO DE FALLOS Los sistemas computacionales a veces fallan. Cuando aparecen fallos en el hardwa re o el software, los programas pueden producir resultados incorrectos o pudieran parar antes de haber completado el clculo pedido. Los fallos en un sistema distribuido son parci ales; es decir, algunos componentes fallan mientras otros siguen funcionando. Consecuentemente, el tratamiento de fallos es particularmente difcil. Existen alg unas tcnicas para tratar fallos: Deteccin de fallos: algunos fallos son detectables. Por ejemplo, se pueden utiliz ar sumas de comprobacin (checksums) para detectar datos corruptos en un mensaje o un archi vo. Es difcil o incluso imposible detectar algunos otros fallos como la cada de un ser vidor remoto en Internet. El reto est en arreglrselas en presencia de fallos que no pued en detectarse pero que s pueden esperarse. Enmascaramiento de fallos: algunos fallos que han sido detectados pueden ocultar se o atenuarse. Dos ejemplos de ocultacin de fallos son: 1. Los mensajes pueden retransmitirse cuando falla la recepcin. 2. Los archivos con datos pueden escribirse en una pareja de discos de forma que si uno est deteriorado el otro seguramente est en buen estado. Simplemente eliminar un mensaje corrupto es un ejemplo de atenuar un fallo (pudi era retransmitirse de nuevo). Cabe destacar que las tcnicas propuestas para ocultar l os fallos no tienen garanta de funcionamiento en las peores situaciones; por ejemplo, los d atos en el segundo disco pudieran tambin estar corrompidos, o el mensaje bien pudiera no llegar a tiempo no importa cuantas veces se retransmita. Tolerancia de fallos: la mayora de los servicios en Internet exhiben fallos; es p osible que no sea prctico para ellos pretender detectar y ocultar todos los fallos que pudie ran aparecer en una red tan grande y con tantos componentes. Sus clientes pueden dis earse para tolerar ciertos fallos, lo que implica que tambin los usuarios tendrn que tol erarlos generalmente. Por ejemplo, cuando un visualizador web no puede contactar con un servidor web n o har que el cliente tenga que esperar indefinidamente mientras hace sucesivos intento s;

informar al usuario del problema, dndole la libertad de intentarlo ms tarde. Recuperacin frente a fallos: la recuperacin implica el diseo de software en el que, tras una cada del servidor, el estado de los datos pueda reponerse o retractarse (roll back) a una situacin anterior. En general, cuando aparecen fallos los clculos realizados p or algunos programas se encontrarn incompletos y al actualizar datos permanentes (archivos e informacin ubicada en almacenamiento persistente) pudiera encontrarse en un estado inconsistente.

Redundancia: puede lograrse que los servicios toleren fallos mediante el empleo redundante de componentes. Considere los siguientes ejemplos: 1. Siempre deber haber al menos dos rutas diferentes entre cualesquiera dos route rs (encaminadores) en Internet. 2. En el Sistema de Nombres de Dominio, cada tabla de nombres se encuentra repli cada en dos servidores diferentes. 3. Una base de datos puede encontrarse replicada en varios servidores para asegu rar que los datos siguen siendo accesibles tras el fallo de cualquier servidor concreto; los servidores pueden disearse para detectar fallos entre sus iguales; cuando se dete cta algn error en un servidor se redirigen los clientes a los servidores restantes. El diseo de tcnicas eficaces para mantener rplicas actualizadas de datos que cambia n rpidamente sin una prdida excesiva de prestaciones es un reto para el que existen varias aproximaciones. Los sistemas distribuidos proporcionan un alto grado de disponibilidad frente a los fallos del hardware. La disponibilidad de un sistema mide la proporcin de tiempo en que est utilizable. Cuando falla algn componente del sistema distribuido slo resulta afect ado el trabajo relacionado con el componente defectuoso. As como cuando un computador fa lla el usuario puede desplazarse a otro, tambin puede iniciarse un proceso de servici o en otra ubicacin. CONCURRENCIA Tanto los servicios como las aplicaciones proporcionan recursos que pueden compa rtirse entre los clientes en un sistema distribuido. Existe por lo tanto una posibilida d de que varios clientes intenten acceder a un recurso compartido a la vez. Por ejemplo, una estructura de datos que almacena licitaciones de una subasta pu ede ser accedida muy frecuentemente cuando se aproxima el momento de cierre. El proceso que administra un recurso compartido puede atender las peticiones de cliente una por una en forma secuencial, pero esta aproximacin limita el ritmo de producc in del sistema (throughput). Por esto los servicios y aplicaciones permiten, usualm ente, procesar concurrentemente mltiples peticiones de los clientes. Ms concretamente, suponga que cada recurso se encapsula en un objeto y que las invocaciones se eje cutan en hilos de ejecucin concurrentes (threads). En este caso es posible que varios thre ads estuvieran ejecutando concurrentemente el contenido de un objeto, en cuyo caso l as

operaciones en el objeto pueden entrar en conflicto entre s y producir resultados inconsistentes. Por ejemplo, sean dos ofertas que concurren a una subasta como Prez: 122$ y Rodrguez: 111$ y las operaciones correspondientes se entrelazan sin control alguno, estas ofertas se pueden almacenar como Prez: 111$ y Rodrguez: 122$.

La moraleja de esta historia es que cada objeto que represente un recurso compar tido en un sistema distribuido debe responsabilizarse de garantizar que opera correctame nte en un entorno concurrente. De este modo cualquier programador que recoge una implementacin de un objeto que no est concebido para su aplicacin en un entorno distribuido deber realizar las modificaciones necesarias para que sea seguro su u so en un entorno concurrente. Para que un objeto sea seguro en un entorno concurrente, su s operaciones deben sincronizarse de forma que sus datos permanezcan consistentes. Esto puede lograrse mediante el empleo de tcnicas conocidas como los semforos, que se usan en la mayora de los sistemas operativos. TRANSPARENCIA Se define transparencia como el ocultamiento al usuario y al programador de apli caciones de la separacin de los componentes en un sistema distribuido, de forma que se per ciba el sistema como un todo ms que como una coleccin de componentes independientes. Las implicaciones de la transparencia son de gran importancia en el diseo del softwar e del sistema. El Manual de Referencia ANSA (ANSA Reference Manual} [ANSA 1989] y el Modelo de Referencia para el Procesamiento Distribuido Abierto (RM-ODP: Reference Model for Open Distributed Processing) de la Organizacin Internacional de Estndares [ISO 1992] identifican ocho formas de transparencia. 1. Transparencia de acceso que permite acceder a los recursos locales y remotos empleando operaciones idnticas. 2. Transparencia de ubicacin que permite acceder a los recursos sin conocer su localizacin. 3. Transparencia de concurrencia que permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua. 4. Transparencia de replicacin que permite utilizar mltiples ejemplares de cada recurso para aumentar la fiabilidad y las prestaciones sin que los usuarios y lo s programadores de aplicaciones necesiten su conocimiento. 5. Transparencia frente a fallos que permite ocultar los fallos, dejando que los us uarios y programas de aplicacin completen sus tareas a pesar de fallos del hardware o de l os componentes software. 6. Transparencia de movilidad que permite la reubicacin de recursos y clientes en un sistema sin afectar la operacin de los usuarios y los programas. 7. Transparencia de prestaciones que permite reconfigurar el sistema para mejorar l

as prestaciones segn vara su carga.

8. Transparencia al escalado que permite al sistema y a las aplicaciones expandirse en tamao sin cambiar la estructura del sistema o los algoritmos de aplicacin. Las dos ms importantes son la transparencia de acceso y la transparencia de ubica cin; su presencia o ausencia afecta principalmente a la utilizacin de recursos distrib uidos. A veces se les da el nombre conjunto de Transparencia de Red. Como ilustracin de la transparencia de acceso, considere una interfaz grfica de us uario basada en carpetas, donde los contenidos de las carpetas se observan igual ya se an stas locales o remotas. Otro ejemplo pudiera ser el de una interfaz de programacin de aplicaciones [API] para archivos que emplea las mismas operaciones para acceder a stos ya sean locales o remotos. Como ejemplo de carencia de transparencia de acceso, considere un sistema distri buido que no permite acceder a los archivos de un computador remoto a menos que se emplee el programa ftp. Los nombres de recursos web o URLs son transparentes a la ubicacin dado que la pa rte del URL que identifica el nombre del dominio del servidor web se refiere a un no mbre de computador en un dominio, ms que a una direccin en Internet. Sin embargo, un URL no es transparente a la movilidad, porque una pgina web dada no puede moverse a u n nuevo lugar en un dominio diferente sin que todos los enlaces anteriores a esta pgina sigan apuntando a la pgina original. En general, los identificadores como los URLs que incluyen los nombres de domini o en los computadores contravienen la transparencia de replicacin. Aunque el DNS permi te que un nombre de dominio se refiera a varios computadores, slo se escoge uno de e llos cuando se utiliza un nombre. Ya que un esquema de replicacin generalmente necesit a ser capaz de acceder a todos los computadores del grupo, sera necesario acceder a cada entrada del DNS por nombre. Como ilustracin de la presencia de transparencia de red, considere el uso de una direccin de correo electrnico como Pedro.Picapiedra@piedradura.com. La direccin consta de un nombre de usuario y un nombre de dominio. Observe que a pesar de qu e los programas de correo aceptan nombres de usuario para usuarios locales, aaden el no mbre del dominio. El envo de correo a un usuario no implica el conocimiento de su ubic acin fsica en la red. Tampoco el procedimiento de envo de un mensaje de correo depende de

la ubicacin del receptor. En resumen, el correo electrnico en Internet proporciona ambas cosas: transparencia de ubicacin y transparencia de acceso (en definitiva, transparencia de red). La transparencia frente a fallos puede ilustrarse tambin en el contexto del corre o electrnico, el cual eventualmente se enva, incluso aunque los servidores o los enl aces

de comunicaciones fallen. Los fallos se enmascaran intentando retransmitir los m ensajes hasta que se envan satisfactoriamente, incluso si lleva varios das. Para ilustrar la transparencia a la movilidad, considere el caso de los telfonos mviles. Supongamos que ambos, el emisor y el receptor, viajan en tren por diferentes par tes del pas, movindose de un entorno (clula) a otro. Veamos al terminal del emisor como un cliente y al terminal del receptor como un recurso. Los dos usuarios telefnicos n o perciben el desplazamiento de sus terminales (el cliente y el recurso) entre dos clulas. La transparencia oculta y difumina annimamente los recursos que no son relevantes directamente para la tarea entre manos de los usuarios y programadores de aplica ciones. Por ejemplo, en general es deseable que el uso de ciertos dispositivos fsicos sea intercambiable. Por ejemplo, en un sistema multiprocesador, la identificacin del procesador en que se ejecuta cada proceso es irrelevante. En otro ejemplo, un us uario viajero que conecta un computador porttil a una red local, en cada oficina que vi sita hace uso de servicios locales como el correo, utilizando diferentes servidores e n cada ubicacin. Incluso dentro de un edificio, es normal enviar la impresin de documento s a una impresora u otra dependiendo cual es actualmente la ms prxima.