monografia de sistemas distribuidos

Sistemas Distribuidos

DEDICATORIA

A nuestros padres por darnos la mejor educación y enseñarme que todas las cosas hay que

valorarlas, trabajarlas y luchar para logra los objetivos de la vida. A nuiestras madres por todo su

amor y ternura que nos han brindado a lo largo de nuestra vida. A mis parientes por estar en

buenos y malos momentos de mi vida. A la Unversidad Privada San Pedro por enseñarnos que la

inteligencia es la fuente de un hombre prospero y que estudiar es un valor incalculable de la

vida. A nuestro profesor Omar Meca Rosales por enseñarme ha escuchar y comprender las cosas

de la vida y aprender que el mejor músculo del hombre es el cerebro.

Pagina 2


Sistemas

Distribuidos

Pagina 3


ÍNDICE DE LA TABLA DE CONTENIDO

-Dedicatoria---------------------------------------------------------------------------------02

-Titulo o portada --------------------------------------------------------------------------03

-Introducción ------------------------------------------------------------------------------ 10

-Glosario ------------------------------------------------------------------------------------ 11

-Objetivos ---------------------------------------------------------------------------------- 14

-CAPITULO 1: SISTEMAS DISTRIBUIDOS ---------------------------------- 15

1.1 Historia de los Sistemas Distribuidos -------------------------------------------- 16

1.2 Que es un Sistema Distribuido---------------------------------------------- ---------17

1.3 Objetivos ---------------------------------------------------------------------- -------- 21

1.4 Conceptos de Hardware ------------------------------------------------------------ 23

1.5 Conceptos de Software --------------------------------------------------------------26

1.6 Aspectos de Diseño ---------------------------------------------------------- ---------27

1.7 Componentes de los Sistemas Distribuidos---------------------------------------- 31

-CAPITULO 2: RECURSOS DE LOS SISTEMAS DISTRIBUIDOS --------34

2.1 Comunicación En Los Sistemas Distribuidos---------------------------------- 35

Pagina 4


2.1.1 Protocolo con capas -------------------------------------------------------- --------36

2.1.2 Redes con modo de transferencia ---------------------------------------- ------- -38

2.1.3 El modelo cliente-servidor----------------------------------------------- - --------41

Llamada de Procedimiento Remoto (RPC) ---------------------------------- --------45

2.2 Sincronización en los Sistemas Distribuidos ----------------------------------- 49

2.2.1 Sincronización de los relojes ------------------------------------------- --------49

2.2.2 Exclusión mutua--------------------------------------------------------------------- 53

2.2.3 Algoritmos de elección---------------------------------------------------- -------- 56

2.2.4 Transacciones atómicas------------------------------------------------------------- 57

2.2.5 Bloqueos en sistemas distribuidos ------------------------------------------------ 59

2.3 Procesos y procesadores en los Sistemas Distribuidos----------------------- --62

2.3.1 Hilos ------------------------------------------------------------------------------ -62

2.3.2 Modelos de sistemas -------------------------------------------------------------- 66

2.3.3 Asignación de procesadores ---------------------------------------------------- 69

2.3.4 Planificación en Sistemas distribuidos---------------------------------- -------- 72

2.3.5 Tolerancia de fallas ------------------------------------------------------------- 73

2.3.6 Sistemas distribuidos en tiempo real ---------------------------------- -------- 76

Pagina 5


2.4 Sistemas de archivos ------------------------------------------------------------ 80

2.4.1 Diseño de sistemas de archivos --------------------------------------------------- 81

2.4.2 Implantación de un sistema distribuido---------------------------------- -------- 83

2.4.3 Tendencias en los sistemas distribuidos de archivos -------------------------- 87

2.5 Memoria Distribuida ---------------------------------------------------------------- 89

2.5.1 Que es la memoria compartida ---------------------------------------------------- 90

2.5.2 Modelos de consistencia ---------------------------------------------------------- 92

2.5.3 Memoria compartida distribuida con bases a páginas ------------------------ 94

2.5.4 Memoria compartida distribuida con variables compartidas ---------------- 96

2.5.5 Memoria compartida distribuida basada en objetos ------------------------- 97

-UNIDAD 3: MODELOS DE SISTEMAS DISTRIBUIDOS -------------------- 100

3.1 AMOEBA

3.1.1 Introducción a la AMOEBA ---------------------------------------------------- 101

3.1.2 Objetos y posibilidades de AMOEBA ---------------------------------------- 102

3.1.3 Administración de procesos de memoria --------------------------------------- 103

3.1.4 Administración de memoria en AMOEBA ---------------------------------- 104

Pagina 6


3.1.5 Comunicación en AMOEBA --------------------------------------------------- 105

3.1.6 Los servidores de AMOEBA -------------------------------------------------- 107

3.2 CHORUS

3.2.1 Introducción a CHORUS -------------------------------------------------------- 108

3.2.2 Administración de procesos en CHORUS ------------------------------------- 113

3.2.3 Administración de memoria en CHORUS ------------------------------------- 120

3.2.4 Comunicación en CHORUS --------------------------------------------------- 121

-UNIDAD 4: PROYECTOS DE MODELAMIENTO -------------------------- 123

4.1 Metodología para la realización de proyectos basados en S.D ----------------- 124

-Conclusiones ------------------------------------------------------------------------------ 129

-Anexos---------------------------------------------------------------------------------------131

-Bibliografía ------------------------------------------------------------------------------ 148

Pagina 7


ÍNDICE DE LA TABLA DE IMAGENES

Sistemas distribuido historia (imagen 1 y 2) ----------------------------------------------132

Factores ventajas y desventajas de un sistema distribuido (imagen 3)-----------------133

Tolerancia a fallos de un sistema distribuidos (imagen 4)-------------------------------133

Hardware de un sistema distribuido (imagen 5)--------------------------------------------133

Desempeño y escalabilidad de un sistema distribuido (imagen 6)-----------------------134

Servicio de seguridad componentes de un sistema distribuido (imagen 7)-------------134

Modelo OSI (imagen 8)------------------------------------------------------------------------135

Redes con modo de transferencia (imagen 9)-----------------------------------------------135

Atm (imagen 10)--------------------------------------------------------------------------------136

Modelo cliente servidor (imagen 11)---------------------------------------------------------136

Solicitud y respuesta del modelo cliente servidor (imagen 12) -------------------------136

implantación del modelo cliente servidor (imagen 13 y 14)-------------------------------137

Lla nada de un procedim iento remoto (imagen 15)----------------------------------------138

Sincronización de relojes (imagen 16)--------------------------------------------------------138

Algoritmo para sincronizar relojes (imagen 17)---------------------------------------------138

Exclusión mutua (imagen 18)------------------------------------------------------------------139

Algoritmo de elección (imagen 19)-----------------------------------------------------------139

Bloqueos de sistemas (imagen 20)------------------------------------------------------------139

Implantación de paquetes de hilos (imagen 21) --------------------------------------------140

Modelos de asignación (imagen 22)----------------------------------------------------------140

Fallas comunes (imagen 23)-------------------------------------------------------------------140

Pagina 8


DTR (imagen 24)--------------------------------------------------------------------------------141

Servidores de archivos (imagen 25)-----------------------------------------------------------141

Protocolo de actualización (imagen 26)-------------------------------------------------------142

Memoria distribuida (imagen 27)--------------------------------------------------------------142

Memoria compartida (imagen 28)-------------------------------------------------------------142

Modelos de consistencia (imagen 29)---------------------------------------------------------143

Memoria compartida distribuida con bases de paginas (imagen 30)----------------------143

Memoria compartida distribuida con bases de objetos (imagen 31)-----------------------143

Objetos (imagen 32 y 33)------------------------------------------------------------------------144

Amoeba (imagen 34)-----------------------------------------------------------------------------145

Objetos y posibilidades (imagen 35)-----------------------------------------------------------145

Procesos (imagen 36)-----------------------------------------------------------------------------145

Funcionamiento RPC (imagen 37)-------------------------------------------------------------146

Servidor de archivos (imagen 38 y 39)--------------------------------------------------------146

Servidor de directorios (imagen 40)-----------------------------------------------------------147

Servidor de ejecución (imagen 41)-------------------------------------------------------------147

CHORUS (imagen 42)---------------------------------------------------------------------------147

Administración en memoria en CHORUS (imagen 43)-------------------------------------148

Comunicación en CHORUS (imagen 44)-----------------------------------------------------148

Pagina 9


INTRODUCCIÓN

El presente trabajo se refiere del tema Sistemas Distribuidos, que se puede definir como una

colección de computadoras separadas físicamente y conectadas entre sí por una red de

comunicaciones; cada máquina posee sus componentes de hardware y software que el

programador percibe como un solo sistema (no necesita saber qué cosas están en qué máquinas).

El programador accede a los componentes de software (objetos) remotos, de la misma manera

en que accedería a componentes locales, en un grupo de computadoras que usan un middleware

entre los que destacan (RPC) y SOAP para conseguir un objetivo.

La característica principal de los Sistemas Distribuidos es la compartición de recursos. La idea

de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los

sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus

usuarios.

Los objetivos principales que buscan los sistemas distribuidos son los siguientes:

Transparencia

Fiabilidad (disponibilidad y coherencia)

Rendimiento

Escalabilidad

Flexibilidad

Seguridad

Cada uno de los distintos modelos de sistemas distribuidos requiere diferentes facetas de estos

objetivos.

Pagina 10


GLOSARIO

Sistema

Es el conjunto de partes que se interrelacionan entre sí como el hardware, software y de recurso

humano que permiten almacenar y procesar la información dependiendo de la actividad a la que

este dedicado el sistema.

Estos elementos suele incluirse los elementos físicos, el software, entre otros relacionados. Suele

contener este término el software básico, tal como el sistema operativo, y los compiladores,

depuradores, enlazadores, entre otros.

Distribuido

En un término de informática la distribución es un nuevo modelo para resolver problemas de

computación masiva utilizando un gran número de computadoras estas organizadas en racimos

incrustados en una infraestructura de telecomunicaciones distribuida.

Modelo

Es una estructura de datos que permite hacer o realizar alguna actividad o acción

dependiendo el objetivo del modelo. Otro enfoque es pensar que un modelo permite describir

los elementos de la realidad que intervienen en un problema dado y la forma en que se

relacionan esos elementos entre sí.

Pagina 11


Minicomputadora

Es una computadora que tiene un circuito integrado que tiene la mayoría de las capacidades de

procesamiento de las grandes computadoras llamados microprocesadores, y como mínimo algún

tipo de memoria semiconductora.

Generalmente son computadoras que ocupan espacios físicos pequeños, comparadas a sus

predecesoras históricas, las mainframes y las minicomputadoras.

Microprocesador

Es el circuito integrado central y más complejo de un sistema informático, este circuito está

integrado por millones de componentes electrónicos que constituye la unidad central de

procesamiento de un PC catalogado binarias y accesos a memoria.

Este ejecuta instrucciones que se le dan a la computadora a muy bajo nivel haciendo operaciones

lógicas simples, como sumar, restar, multiplicar y dividir.

Operativo

Se trata de un dispositivo o un plan que lleva a cabo para desarrollar una acción y conseguir un

objetivo.

Proceso

Es una parte que puede entenderse informalmente como un programa en ejecución.

Formalmente un proceso es una unidad de actividad que se caracteriza por la ejecución de una

secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistema asociados.

Pagina 12


Recurso

Ha sido aplicado en diversos ámbitos, en particular, con respecto a las ciencias de la

computación, que refiriéndose a estas es una fuente o suministro del cual se produce un

beneficio. Normalmente, los recursos son material u otros activos que son transformados para

producir beneficio y en el proceso pueden ser consumidos o no estar más disponibles.

Migración

Migración en la cuestión informática se denomina a todo desplazamiento de la de datos y/o

información que se produce de un lugar de origen a otro de destino y lleva consigo un cambio de

la residencia de almacenamiento.

Sincronización

Se describe como el ajuste temporal de eventos, se habla de sincronización cuando determinados

fenómenos ocurran en un orden predefinido o a la vez. Se utiliza para regresar a un estado

anterior conocido en caso de error durante la sesión. Aunque parezca innecesario (la capa de

transporte sólo recupera errores de comunicación) ocurren muchos errores a nivel de sesiones

entre usuarios (capas superiores).

Sistema Distribuido

Es una colección de computadoras conectadas en red, las cuales se comunican y coordinan entre

sí para lograr un objetivo. se establecen una o varias comunicaciones mediante el esquema

Cliente-Servidor.

Pagina 13


OBJETIVOS

Objetivo General:

El objetivo general de este trabajo es comprender el buen funcionamiento, la eficacia y la

fiabilidad de los sistemas distribuidos.

Objetivos Específicos:

Entender como está estructurado un Sistema Distribuido

Conocer que tipos de Sistemas Distribuidos que existen

Dar a entender las nuevas tecnologías y metodologías que trabajan junto a los sistemas

distribuidos.

Conocer proyectos de modelamiento basados en sistemas distribuidos.

Pagina 14


Capítulo 1: Sistemas

Distribuidos

Pagina 15


1.1 HISTORIA DE LOS SISTEMAS DISTRIBUIDOS

En el inicio de la era de la informática las computadoras eran grandes y caras. Debido a su

escasez y coste, éstas funcionaban de forma independiente entre ellas.

A partir de los años 70, surgen los primeros miniordenadores, que competirían con los grandes

ordenadores tanto por las prestaciones como por su precio, con lo que se extendió su uso. Los

grandes sistemas centralizados fueron dejando paso lentamente a sistemas mucho más

descentralizados, y formados por varios ordenadores o a sistemas multiprocesador. Pronto

surgieron nuevas necesidades de interconexión de los equipos, y se desarrollaron las redes de

área local (LAN), como Ethernet o Token ring.

ETAPAS

En los 40's, se introducen los programas bit a bit, por medio de interruptores mecánicos y

después se introdujo el lenguaje máquina que trabajaba por tarjetas perforadas.

Con las primeras computadoras, desde finales de los años 40 hasta la mitad de los años 50, el

programador interactuaba de manera directa con el hardware de la computadora, no existía

realmente un Sistema Operativo; las primeras computadoras utilizaban bulbos, la entrada de

datos y los programas se realizaban a través del lenguaje máquina (bits) o a través de

interruptores.

Durante los años 50's y 60's.- A principio de los 50's, la compañía General's Motors implanto

el primer sistema operativo para su IBM 170. Empiezan a surgir las tarjetas perforadas las cuales

permiten que los usuarios (que en ese tiempo eran programadores, diseñadores, capturistas, etc.),

Pagina 16


se encarguen de modificar sus programas. Establecían o apartaban tiempo, metían o introducían

sus programas, corregían y depuraban sus programas en su tiempo. A esto se le llamaba trabajo

en serie. Todo esto se traducía en pérdida de tiempo y tiempos de programas excesivos.

En los años 60's y 70's se genera el circuito integrado, se organizan los trabajos y se generan

los procesos Batch (por lotes), lo cual consiste en determinar los trabajos comunes y realizarlos

todos juntos de una sola vez. En esta época surgen las unidades de cinta y el cargador de

programas, el cual se considera como el primer tipo de Sistema Operativo.

En los 80's, inició el auge de la INTERNET en los Estados Unidos de América. A finales de

los años 80's comienza el gran auge y evolución de los Sistemas Operativos. Se descubre el

concepto de multiprogramación que consiste en tener cargados en memoria a varios trabajos al

mismo tiempo, tema principal de los Sistemas Operativos actuales.

En los 90's y en adelante, entramos a la era de la computación distribuida y del

multiprocesamiento a través de múltiples redes de computadoras, aprovechando el ciclo del

procesador (ver imagen 1 e imagen 2).

1.2 ¿QUÉ ES UN SISTEMA DISTRIBUIDO?

Un sistema distribuido se define como una colección de computadoras separadas físicamente y

conectadas entre sí por una red de comunicaciones; cada máquina posee sus componentes de

hardware y software que el programador percibe como un solo sistema (no necesita saber qué

cosas están en qué máquinas). El programador accede a los componentes de software (objetos)

remotos, de la misma manera en que accedería a componentes locales, en un grupo de

Pagina 17


computadoras que usan un middleware entre los que destacan (RPC) y SOAP para conseguir un

objetivo.

Los sistemas distribuidos deben ser muy confiables, ya que si un componente del sistema se

descompone otro componente debe ser capaz de reemplazarlo. Esto se denomina tolerancia a

fallos.

El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts (red de

área local), centenas de hosts (red de área metropolitana), o miles, o millones de hosts (Internet);

esto se denomina escalabilidad.

Colección de elementos de cómputo autónomo que se encuentran físicamente separados y no

comparten una memoria común, se comunican entre sí a través del intercambio de mensajes

utilizando un medio de comunicación. Los sistemas autónomos pueden tener características no

homogéneas.

Características de los Sistemas Distribuidos.

1.-Cada elemento de cómputo tiene su propia memoria y su propio Sistema Operativo.

2.-Control de recursos locales y remotos.

3.- Sistemas Abiertos (Facilidades de cambio y crecimiento).

4.-Plataforma no standard (Unix, NT, Intel, RISC, Etc.).

5.-Medios de comunicación (Redes, Protocolos, Dispositivos, Etc.).

6.- Capacidad de Procesamiento en paralelo.

7.-Dispersión y parcialidad.

Pagina 18

http://es.wikipedia.org/wiki/Host


Factores que han afectado el desarrollo de los Sistemas Distribuidos.

1.-Avances Tecnológicos.

2 .Nuevos requerimientos.

3.-Globalización.

4.-Aspectos Externos (Culturales, Políticos, Económicos).

5.-Integración.

Ventajas y Desventajas de los Sistemas Distribuidos.

Ventajas:

Procesadores más poderosos y a menos costos

Desarrollo de Estaciones con más capacidades

Las estaciones satisfacen las necesidades de los usuarios.

Uso de nuevas interfaces.

Avances en la Tecnología de Comunicaciones.

Disponibilidad de elementos de Comunicación.

Desarrollo de nuevas técnicas.

Compartición de Recursos.

Dispositivos (Hardware).

Programas (Software).

Eficiencia y Flexibilidad.

Pagina 19


Respuesta Rápida.

Ejecución Concurrente de procesos (En varias computadoras).

Empleo de técnicas de procesamiento distribuido.

Disponibilidad y Confiabilidad.

Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad del sistema).

Mayores servicios que elevan la funcionalidad (Monitoreo, Telecontrol, Correo Eléctrico,

Etc.).

Crecimiento Modular.

Es inherente al crecimiento.

Inclusión rápida de nuevos recursos.

Los recursos actuales no afectan.

Desventajas:

-Requerimientos de mayores controles de procesamiento.

-Velocidad de propagación de información (Muy lenta a veces).

-Servicios de replicación de datos y servicios con posibilidades de fallas.

-Mayores controles de acceso y proceso (Commit).

-Administración más compleja.

-Costos. (ver imagen 3)

Pagina 20


1.3 OBJETIVOS DE UN SISTEMA DISTRIBUIDO

-Transparencia.

El objetivo esencial de un sistema distribuido es proporcionar al usuario y a las aplicaciones una

visión de los recursos del sistema como gestionados por una sola máquina virtual. La

distribución física de los recursos es transparente.

Pueden describirse diferentes aspectos de la transparencia:

• De identificación. Los espacios de nombres de los recursos son independientes de la topología

de la red y de la propia distribución de los recursos. De esta forma, una aplicación puede

referirse a un recurso con un nombre independientemente de en qué nodo se ejecute.

-Escalabilidad.

Una de las características de los sistemas distribuidos es su modularidad, lo que le permite una

gran flexibilidad y posibilita su escalabilidad, definida como la capacidad del sistema para

crecer sin aumentar su complejidad ni disminuir su rendimiento. Uno de los objetivos del diseño

de un sistema distribuido es extender la escalabilidad a la integración de servicios.

- Complejidad/rendimiento.

El crecimiento de un sistema distribuido puede introducir cuellos de botella y latencias que

degradan su rendimiento. Además del incremento de los costes de comunicación por el aumento

de la distancia física entre los componentes del sistema, la complejidad estructural de los

algoritmos distribuidos es a menudo más que lineal con respecto al tamaño del sistema, como

iremos comprobando a lo largo del curso. Es necesario, por tanto, establecer compromisos entre

tamaño del sistema, rendimiento y complejidad.

Pagina 21


Fiabilidad y tolerancia a fallos.

La fiabilidad de un sistema puede definirse como su capacidad para realizar correctamente y en

todo momento las funciones para las que se ha diseñado. La fiabilidad se concreta en dos

aspectos:

• Disponibilidad. Es la fracción de tiempo que el sistema está operativo.

El principal parámetro para medir la disponibilidad es el tiempo medio entre fallos (MTBF),

pero hay que considerar también el tiempo de reparación. La disponibilidad se puede

incrementar de dos formas: (a) utilizando componentes de mayor calidad, y/o (b) con un diseño

basado en la replicación de componentes que permita al sistema seguir operando aun cuando

alguno(s) de ellos falle(n). Ambas alternativas incrementan el coste del sistema; sin embargo, en

el estado tecnológico actual, la replicación resulta, en general, menos costosa. Los sistemas

distribuidos proporcionan inherentemente la replicación de algunos recursos (por ejemplo,

unidades de proceso), mientras que otros normalmente compartidos (por ejemplo, un servidor de

ficheros) pueden replicarse para aumentar la disponibilidad.

. • Tolerancia a fallos. Aún con una alta disponibilidad, un fallo en un momento determinado

puede tener consecuencias desastrosas. Piénsese en sistemas de tiempo real críticos que

controlan dispositivos vitales (por ejemplo en medicina, centrales nucleares...). Es decir, aunque

la replicación aumenta la disponibilidad, no garantiza por sí sola la continuidad del servicio de

forma transparente. La tolerancia a fallos expresa la capacidad del sistema para seguir operando

correctamente ante el fallo de alguno de sus componentes, enmascarando el fallo al usuario o a

la aplicación. Por lo tanto, la tolerancia a fallos implica (1) detectar el fallo, y (2) continuar el

servicio, todo ello de forma transparente para la aplicación (transparencia de fallos).Sobre

Pagina 22


nuestro ejemplo cabe decir que, al carecer de replicación del servicio, NFS no proporciona

tolerancia a fallos. En cambio, se han propuesto otros sistemas de fichero que sí tienen la

tolerancia a fallos como objetivo de diseño, como es el caso de AFS. (ver imagen 4)

Consistencia.

La distribución de recursos introduce importantes beneficios. Por una parte, contribuye al

incremento del rendimiento a través del paralelismo y promoviendo el acceso a copias locales

del recurso (disminuyendo los costes de comunicación). Por otra, como se acaba de ver, la

replicación aumenta la disponibilidad, siendo la base para proporcionar tolerancia a fallos. No

obstante, distribuir recursos acarrea algunos problemas. Por una parte, la red de interconexión es

una nueva fuente de fallos. Además, la seguridad del sistema es más vulnerable ante accesos no

permitidos. Pero el problema de mayor complejidad es el de la gestión del estado global para

evitar situaciones de inconsistencia entre los componentes del sistema. Este es un aspecto

fundamental en el diseño del sistema distribuido, por lo que lo comentaremos a continuación:

El problema radica en la necesidad de mantener un estado global consistente en un sistema con

varios componentes.

1.4 CONCEPTOS DE HARDWARE

Se ha mencionado que en un sistema distribuido existen varias unidades centrales de procesos y

es necesario organizar las formas de interconectarlas para que puedan comunicarse entre sí.

Durante el transcurso de la evolución de los sistemas distribuidos, han surgido diferentes

propuestas para clasificar a las computadoras con varios CPU. Es probable que una de las

propuestas más aceptadas sea la de Flynn (1972) y en ella, Flynn propone dos características

Pagina 23


consideradas por el cómo esenciales: el número de flujos de instrucciones y el número de flujo

de datos. Se puede catalogar a los equipos de cómputo de acuerdo a lo anterior de la siguiente

forma:

Una computadora con un solo flujo de instrucciones y un flujo de datos (SISD, Single

Instruction Single Data). Dentro de esta categoría caen todas las computadoras tradicionales con

un solo procesador.

Computadoras con un flujo de instrucciones y varios flujos de datos (SIMD, Single

Instruction Multiple Data). En esta categoría se incluyen aquellas computadoras que pueden

instruir a varios procesadores para que, en paralelo, ejecuten instrucciones.

Computadoras con múltiples flujos de instrucciones y varios flujos de datos (MIMD, Multiple

Instruction Multiple Data). Esto significa un grupo de computadoras independientes, cada una

con su propio contador de programa y datos. En conjunto, un sistema distribuido recae en esta

clasificación.

Existe otra propuesta en las que los sistemas MIMD se subdividen en dos grupos:

Maquinas multiprocesadores. Existe un espacio de direcciones virtuales, compartido por

todos los CPU del sistema.

Computadoras multi computadoras. Cada máquina tiene su propia memoria en particular.

Asi mismo, cada una de las dos categorías anteriores puede clasificarse de acuerdo a la red de

comunicación con la que se interconectan los CPU, en las dos siguientes categorías.

Tecnología de bus, en la que existe una sola red, plano de base, cable o cualquier otro medio

que conecta a las computadoras.

Pagina 24


La tecnología de conmutador, cuenta con cables individuales que van de una maquina a otra y

utilizan diferentes patrones de cableado. Los mensajes van a través de los cables y se hace una

decisión de conmutación, para dirigir el mensaje a lo largo de la red.

A continuación se detallan cuatro categorías de sistemas de cómputo, incluyendo las dos

categorías de red para conexión.

1. Multiprocesadores con base en buses. Estos sistemas cuentan con un número de CPU,

conectados a un bus común, junto con un módulo de memoria, común para todos. El problema

que podría existir en este esquema, es que el bus puede sobrecargarse, disminuyendo el

rendimiento del sistema en general. Este problema se solucionaría instalando un cache en cada

CPU, de tal forma que los CPU actualicen la información del cache y de la memoria, al

momento de realizar escrituras.

2. Multiprocesadores con conmutador. Este esquema puede usarse en la construcción de

máquinas con más de 64 procesadores y conectarlos a una memoria común. Una solución, es

dividir la memoria en módulos y conectarlos a los CPU con un conmutador de cruceta, como se

muestra en la siguiente figura. Cada CPU y cada memoria cuentan con una conexión y en cada

intersección, existe un conmutador del punto de cruce electrónico, que el hardware puede abrir y

cerrar, asi que cuando un CPU desea tener acceso a un bloque de memoria en particular, cierra

momentáneamente al conmutador del punto de cruce. Un punto en contra del conmutador de

cruceta es que con n CPU y n memorias, se requieren n2 conmutadores en los puntos de cruce.

Se cree la red omega como una solución a este problema. Esta red contiene conmutadores 2 x 2,

cada uno de los cuales tienen dos entradas y dos salidas, y cada entrada se puede dirigir a

cualquier salida.

Pagina 25


3. Multicomputadoras con base en buses. La construcción de este sistema implica una

conexión directa entre el CPU y una memoria lógica, pero el problema que existe, es lograr que

los CPU se comuniquen. Un sistema de este tipo puede ser una LAN de velocidad desde los 10

hasta los 100 Mb/seg.

4. Multicomputadoras con conmutador. En esta categoría, se utilizan una retícula y un

hipercubo, como base de interconexión entre los CPU del sistema. (ver imagen 5)

1.5 CONCEPTOS DE SOFTWARE

En todo sistema de cómputo, el hardware resulta muy importante, pero el software lo es aún

más, pues el software representa la interfaz con los usuarios. Similarmente al hardware, los

sistemas operativos se clasifican en débilmente acoplados y fuertemente acoplados.

El software débilmente acoplado permite que las máquinas de un sistema distribuido

fundamentalmente sean independientes entre sí, pero que interactúen cuando sea necesario. A

continuación se describen tres tipos de software a utilizar en un sistema de multiprocesadores o

Multicomputadoras.

1. Software débilmente acoplado en hardware débilmente acoplado. El ejemplo más común

de este tipo es una LAN, en la que cada usuario cuenta con su propia estación de trabajo, con o

sin disco duro, además de contar con su propio sistema operativo. Para mejorar la comunicación

y la distribución de información, en este modelo se utilizan una o varias computadoras llamadas

servidores de archivos, que se encargan de resolver las solicitudes de escritura y lectura de

información por los usuarios, a quienes se les llama clientes.

Pagina 26


2. Software fuertemente acoplado en hardware débilmente acoplado

(Multicomputadoras). El principal objetivo de este tipo de sistema, es que para los usuarios,

toda la red de computadoras, funcione como un sólo sistema, en lugar de un conjunto de

máquinas interconectadas entre si. Los verdaderos sistemas distribuidos recaen en esta

clasificación.

3. Software fuertemente acoplado en hardware fuertemente acoplado. Aunque aquí existen

varias máquinas de propósito específico (como los servidores de bases de datos), los ejemplos

más comunes a mostrar son los sistemas de tiempo compartido con más de un CPU. Para la

ejecución de los procesos, se utiliza una cola de procesos listos para ejecución. La cola de

ejecución es una estructura de datos almacenada en la memoria compartida, y existe un

planificador para la asignación de cada proceso para uno de los CPU del sistema. El planificador

hace uso de monitores o semáforos para la lograr exclusión mutua necesaria, para que un mismo

proceso no sea asignado a más de un CPU.

1.6 ASPECTOS DEL DISEÑO

Los aspectos claves en el diseño de S. O. distribuidos son:

Transparencia

Un aspecto muy importante es la forma de lograr la imagen de un único sistema

Los usuarios deben percibir que la colección de máquinas conectadas es un sistema de tiempo

compartido de un solo procesador:

Pagina 27


Un sistema que logre este objetivo se dice que es transparente.

Desde el punto de vista de los usuarios, la transparencia se logra cuando:

Sus pedidos se satisfacen con ejecuciones en paralelo en distintas máquinas.

Se utilizan una variedad de servidores de archivos.

El usuario no necesita saberlo ni notarlo.

La transparencia desde el punto de vista de los programas significa diseñar la interfaz de

llamadas al sistema de modo que no sea visible la existencia de varios procesadores.

Flexibilidad.

Existen dos escuelas de pensamiento en cuanto a la estructura de los sistemas distribuidos.

Núcleo monolítico:

o Cada máquina debe ejecutar un núcleo tradicional que proporcione la mayoría de los

servicios.

Micronúcleo (microkernel):

o El núcleo debe proporcionar lo menos posible.

o El grueso de los servicios del S. O. se debe obtener a partir de los servidores al nivel usuario.

Confiabilidad

Un importante objetivo de los sistemas distribuidos es que si una máquina falla, alguna otra debe

encargarse del trabajo

Pagina 28


La confiabilidad global teórica del sistema podría ser el “or” booleano de la confiabilidad de los

componentes; ejemplo:

Se dispone de 5 servidores de archivos, cada uno con una probabilidad de 0,95 de funcionar

en un instante dado.

La probabilidad de falla simultánea de los 5 es (0,05)5 = 0,000006.

La probabilidad de que al menos uno esté disponible es 0,999994.

La confiabilidad práctica se ve disminuida ya que muchas veces se requiere que ciertos

servidores estén en servicio simultáneamente para que el todo funcione, debido a ello algunos

sistemas tienen una disponibilidad más relacionada con el “and” booleano de las componentes

que con el “or” booleano.

Desempeño

Cuando se ejecuta una aplicación en un sistema distribuido no debe parecer peor que su

ejecución en un único procesador, pero esto es difícil de lograr.

Algunas métricas del desempeño son:

Tiempo de respuesta.

Rendimiento (número de trabajos por hora).

Uso del sistema y cantidad consumida de la capacidad de la red.

El problema se complica por el hecho de que la comunicación entre equipos es lenta comparada

con:

La velocidad de proceso.

Pagina 29


La velocidad de la comunicación dentro de un mismo procesador.

Se requiere el uso de protocolos de comunicaciones en los extremos (procesadores) que

intervienen en la comunicación, con lo que se incrementa el consumo de ciclos de procesador.

Escalabilidad

La tendencia indica que el tamaño de los sistemas distribuidos es hacia cientos de miles y aun

decenas de millones de usuarios conectados.

Existen cuellos de botella potenciales que se debe intentar evitar en los sistemas distribuidos de

gran escala:

Componentes centralizados:

o Ej.: un solo servidor de correo para todos los usuarios.

Tablas centralizadas:

o Ej.: un único directorio telefónico en línea.

Algoritmos centralizados:

o Ej.: realización de un ruteo con base en la información completa.

Se deben utilizar algoritmos descentralizados con las siguientes características:

Ninguna máquina tiene la información completa acerca del estado del sistema.

Las máquinas toman decisiones solo en base a la información disponible de manera local.

El fallo de una máquina no arruina el algoritmo.

No existe una hipótesis implícita de la existencia de un reloj global.(ver imagen 6)

Pagina 30


1.7 COMPONENTES DE LOS SISTEMAS DISTRIBUIDOS

El desarrollo de un sistema distribuido complejo requiere el uso de las siguientes funciones y

servicios:

– Servicios de comunicación.

– Sistemas de ficheros y nombrado distribuido.

– Servicios de sincronización y coordinación.

– Memoria compartida distribuida.

– Gestión de procesos.

– Servicio de seguridad.

Estas funcionalidades se plasman en elementos concretos del sistema: componente

Servicios de Comunicación.

• Modelos de interacción:

– Cliente/servidor: (2-niveles, 3-niveles o n-niveles)

– Peer-to-peer: Equilibrio de roles.

– Intermediarios: Proxy, Dispacher, Caches,...

– Unicast vs Multicast

– Fiabilidad.

– Síncronos vs Asíncronos

– Tecnologías de comunicación:

– Paso de mensajes: Berkeley sockets.

– Llamada a procedimientos remotos: RPC.

Pagina 31


– Tecnologías de objetos distribuidos: CORBA, DCOM, EJB

Código móvil: Entornos de agentes

Sistemas de Ficheros Distribuidos.

Identificación, localización y acceso a elementos del entorno distribuido.

Comprende:

– Sistemas de ficheros distribuidos (SFD): NFS, AFS.

– Servicios de nombres: DNS, COS-Naming (CORBA).

– Servicios de directorio: X.500, LDAP, JNDI.

Servicios de Sincronización y Coordinación.

Comprende los conceptos de:

– Tiempo en entornos distribuidos: Sincronización de relojes y relojes lógicos.

– Concurrencia y Paralelismo: Exclusión mutua e interbloqueos.

– Algoritmos distribuidos: Elección de líder, coordinación,...

– Transacciones: Propiedades ACID, modelos de commit/rollback.

Afecta a otros servicios:

– Nombrado e identificación.

– Seguridad y fiabilidad.

– Comunicaciones

Pagina 32


Memoria Compartida Distribuida (DSM).

Hardware:

– Memoria físicamente compartida.

– Memoria distribuida (lógicamente compartida).

– Acceso uniforme vs acceso no uniforme.

Distributed Shared Memory:

– Basada en páginas.

– Basada en variables compartidas.

– Basada en objetos.

Gestión de Procesos

– Taxonomía de los procesos:

– Niveles de granularidad.

– Congelación de procesos (persistencia).

– Migración de procesos (estado/código).

Servicio de Seguridad

Tipología de los ataques:

– Privacidad y confidencialidad.

– Autenticación (spoofing).

– Denegación de servicio. (ver imagen 7)

Pagina 33


Capítulo 2: Recursos

De Los Sistemas

Distribuidos

Pagina 34


2.1 COMUNICACIÓN EN LOS SISTEMAS DISTRIBUIDOS

La diferencia más importante entre un sistema distribuido y un sistema de un único procesador

es la comunicación entre procesos.

En un sistema de un solo procesador la comunicación supone implícitamente la existencia de

la memoria compartida:

Ej.: problema de los productores y los consumidores, donde un proceso escribe en un buffer

compartido y otro proceso lee de él.

En un sistema distribuido no existe la memoria compartida y por ello toda la naturaleza de la

comunicación entre procesos debe replantearse.

Los procesos, para comunicarse, deben apegarse a reglas conocidas como protocolos.

Para los sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la

forma de varias capas y cada capa tiene sus propias metas y reglas.

Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseño al

respecto; una importante opción es la “llamada a un procedimiento remoto”. También es

importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre

dos procesos.

Pagina 35


2.1.1 PROTOCOLOS CON CAPAS

Debido a la ausencia de memoria compartida, toda la comunicación en los sistemas distribuidos

se basa en la transferencia de mensajes.

Cuando el proceso “A” quiere comunicarse con el proceso “B”:

Construye un mensaje en su propio espacio de direcciones.

Ejecuta una llamada al sistema para que el S. O. busque el mensaje y lo envíe a través de la

red hacia “B”.

Para evitar el caos, “A” y “B” deben coincidir en el significado de los bits que se envíen.

Los puntos de acuerdo necesarios incluyen lo siguiente:

¿Cuántos voltios hay que utilizar para un bit “0” y cuántos para un bit “1”?.

¿Cómo sabe el receptor cuál es el último bit del mensaje?

¿Cómo puede detectar si un mensaje ha sido dañado o perdido, y qué debe hacer si lo

descubre?

¿Qué longitud tienen los números, cadenas y otros elementos de datos y cuál es la forma en

que están representados?

La ISO (Organización Internacional de Estándares) desarrolló un modelo de referencia que

Identifica en forma clara los distintos niveles.

Estandariza los nombres de los niveles.

Señala cuál nivel debe realizar cuál trabajo.

Pagina 36


Este modelo se denomina “modelo de referencia para interconexión de sistemas abiertos” (ISO

OSI o modelo OSI) (ver imagen 8).

El “modelo OSI” está diseñado para permitir la comunicación de los sistemas abiertos:

Son aquellos preparados para comunicarse con cualquier otro sistema abierto mediante reglas

estándar:

o Establecen el formato, contenido y significado de los mensajes recibidos y enviados.

o Constituyen los protocolos, que son acuerdos en la forma en que debe desarrollarse la

comunicación.

El “modelo OSI” distingue entre dos tipos generales de protocolos:

Orientados hacia las conexiones:

o Antes de intercambiar los datos, el emisor y el receptor:

Establecen en forma explícita una conexión.

Probablemente negocien el protocolo a utilizar.

Al finalizar, deben terminar la conexión.

El teléfono es un sistema de comunicación orientado hacia la conexión.

Sin conexión:

o No es necesaria una configuración de antemano.

o El emisor transmite el primer mensaje cuando está listo.

o El depósito de una carta en un buzón es una comunicación sin conexión.

Pagina 37


Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste de

un conjunto de operaciones para definir el servicio que la capa está preparada para ofrecer a sus

usuarios.

El protocolo de la capa “n” utiliza la información de la capa “n”.

Cada protocolo de capa se puede cambiar independientemente de los demás:

Esto es de fundamental importancia.

Confiere gran flexibilidad.

La colección de protocolos utilizados en un sistema particular se llama una “suite de

protocolo” o “pila de protocolo”.

2.1.2 REDES CON MODO DE TRANSFERENCIA

Transmisión Asíncrona

Cada carácter se trata de manera independiente para fines de sincronización de reloj y de

carácter y el receptor se resincroniza al principio de cada carácter recibido. Cuando los datos que

se van a transmitir se generan a intervalos aleatorios, cuando el usuario se comunica con una

computadora, la tasa de transmisión al teclear es indeterminada, con intervalos de tiempo

aleatorio y posiblemente largos entre cada digitación sucesiva. Esto significa que la señal de la

línea de transmisión estará en el estado inactivo durante largos intervalos de tiempo entre

caracteres.

Pagina 38


Cada carácter o byte transmitido debe encapsularse entre un bit de inicio y uno o más bits de

paro adicionales. Como se puede apreciar en la siguiente figura el bit de inicio y el bit de paro

tiene diferente polaridad para que el receptor sepa en donde inicia y donde termina cada

carácter. (ver imagen 9)

ATM.

Tres letras - ATM - se repiten cada vez más en estos días en los ambientes Informáticos y de

Telecomunicaciones. La tecnología llamada Asynchronous Transfer Mode (ATM) Modo de

Transferencia Asíncrona es el corazón de los servicios digitales integrados que ofrecerán las

nuevas redes digitales de servicios integrados de Banda Ancha (B-ISDN), para muchos ya no

hay cuestionamientos; el llamado tráfico del "Cyber espacio", con su voluminoso y tumultuoso

crecimiento, impone a los operadores de redes públicas y privadas una voraz demanda de anchos

de banda mayores y flexibles con soluciones robustas.

El protocolo ATM consiste de tres niveles o capas básicas (Ver figura 10).

La primera capa llamada capa física (Physical Layer):

Define las interfaces físicas con los medios de transmisión y el protocolo de trama para la red

ATM es responsable de la correcta transmisión y recepción de los bits en el medio físico

apropiado. A diferencia de muchas tecnologías LAN como Ethernet, que especifica ciertos

medios de transmisión, (10 base T, 10 base 5, etc.) ATM es independiente del transporte físico.

Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network),

SDH (Synchronous Digital Hierarchy), T3/E3, TI/EI o aún en modems de 9600 bps. Hay dos

Pagina 39


subcapas en la capa física que separan el medio físico de transmisión y la extracción de los

datos:

La segunda capa es la capa ATM.

Ello define la estructura de la celda y cómo las celdas fluyen sobre las conexiones lógicas en

una red ATM, esta capa es independiente del servicio. El formato de una celda ATM es muy

simple. Consiste de 5 bytes de cabecera y 48 bytes para información.

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numérica a través de

la red. El tamaño de la celda ha sido escogido como un compromiso entre una larga celda, que

es muy eficiente para transmitir largas tramas de datos y longitudes de celdas cortas que

minimizan el retardo de procesamiento de extremo a extremo, que son buenas para voz, vídeo y

protocolos sensibles al retardo.

La capa de adaptación de ATM.

La tercera capa es la ATM Adaptation Layer (AAL). La AAL juega un rol clave en el manejo de

múltiples tipos de tráfico para usar la red ATM, y es dependiente del servicio. Especificamente,

su trabajo es adaptar los servicios dados por la capa ATM a aquellos servicios que son

requeridos por las capas más altas, tales como emulación de circuitos, (circuit emulation), vídeo,

audio, frame relay, etc. La AAL recibe los datos de varias fuentes o aplicaciones y las convierte

en los segmentos de 48 bytes.

Pagina 40


La capa de Adaptación de ATM yace entre el ATM layer y las capas más altas que usan el

servicio ATM. Su propósito principal es resolver cualquier disparidad entre un servicio

requerido por el usuario y atender los servicios disponibles del ATM layer. La capa de

adaptación introduce la información en paquetes ATM y controla los errores de la transmisión.

2.1.3 EL MODELO CLIENTE SERVIDOR

El “modelo de la OSI” es una solución elegante y realmente aplicable en muchos casos, pero

tiene un problema:

La existencia de los encabezados genera un “costo” adicional de transmisión.

Cada envío de un mensaje genera:

o Proceso en media docena de capas.

o Preparación y agregado de encabezados en el camino hacia “abajo”.

o Eliminación y examen de encabezados en el camino hacia “arriba”.

Con enlaces del orden de decenas (o centenas) de miles de bits / segundo y cpu poderosas:

La carga de procesamiento de los protocolos no es significativa.

El factor limitante es la capacidad de las líneas.

Ej.: redes de área extendida (WAN).

Con enlaces del orden de millones de bits / segundo y computadoras personales:

La carga de procesamiento de los protocolos sí es frecuentemente significativa.

El factor limitante no es la capacidad de las líneas.

Pagina 41


Ej.: redes de área local (LAN).

La mayoría de los sistemas distribuidos basados en LAN no utilizan los protocolos de capas

completos, sí utilizan un subconjunto de toda una pila de protocolos.

El “modelo OSI” no dice nada acerca de la forma de estructurar al sistema distribuido.

El “modelo cliente - servidor” tiene como idea fundamental la estructuración del S. O. como:

Un grupo de procesos en cooperación, llamados servidores, que ofrecen servicios a los

usuarios.

Un grupo de procesos usuarios llamados clientes. (ver imagen 11)

El “modelo cliente - servidor” se basa en un “protocolo solicitud / respuesta”:

Es sencillo y sin conexión.

No es complejo y orientado a la conexión como OSI o TCP / IP.

El cliente envía un mensaje de solicitud al servidor pidiendo cierto servicio.

El servidor:

o Ejecuta el requerimiento.

o Regresa los datos solicitados o un código de error si no pudo ejecutarlo correctamente.

No se tiene que establecer una conexión sino hasta que ésta se utilice.

La pila del protocolo es más corta y por lo tanto más eficiente.

Si todas las máquinas fuesen idénticas solo se necesitarían tres niveles de protocolos.(ver

imagen 12 e imagen 13)

Pagina 42


Implantación del Modelo C – S.

Las principales opciones de diseño analizadas se resumen en:

Direccionamiento:

o Número de máquina.

o Direcciones ralas de procesos.

o Búsqueda de nombres en ASCII por medio del servidor.

Bloqueo:

o Primitivas con bloqueo.

o Sin bloqueo, con copia al núcleo.

o Sin bloqueo, con interrupciones.

Almacenamiento en buffers:

o No usar el almacenamiento en buffers, descartar los mensajes inesperados.

o Sin almacenamiento en buffers, mantenimiento temporal de los mensajes inesperados.

o Buzones.

Confiabilidad:

o No confiable.

o Solicitud - reconocimiento - respuesta - reconocimiento.

o Solicitud - respuesta - reconocimiento.

Existen 3 4 = 81 combinaciones, pero no todas son igual de buenas.

En el caso de mensajes compuestos por varios paquetes, el reconocimiento puede ser:

Por paquete individual:

Pagina 43


o Ante la pérdida de un paquete, solo retransmite ése paquete.

o Requiere más paquetes en la red.

Por mensaje completo:

o La recuperación es compleja ante la pérdida de un paquete.

o Requiere menos paquetes en la red.

Otro aspecto interesante de la implementación es el protocolo subyacente utilizado en la

comunicación c - s.

Los principales tipos de paquetes son los siguientes:

Req:

o Solicitud.

o De cliente a servidor.

o El cliente desea servicio.

Rep:

o Respuesta.

o De servidor a cliente.

o Respuesta del servidor al cliente.

Ack:

o Reconocimiento.

o De cualquiera de ellos a algún otro.

o El paquete anterior que ha llegado.

Aya:

o ¿Estás vivo?

Pagina 44


o De cliente a servidor.

o Verifica si el servidor se ha descompuesto.

Iaa:

o Estoy vivo.


o El servidor no se ha descompuesto.

Ta:

o Intenta de nuevo.

o De servidor a clientes.

o El servidor no tiene espacio.

Au:

o Dirección desconocida.


o Ningún proceso utiliza esta dirección.

Algunos ejemplos de intercambio de paquetes para la comunicación cliente – servidor. (ver

imagen 14)

2.1.4 LLAMADA DE UN PROCEDIMIENTO REMOTO

La Llamada a Procedimiento Remoto (RPC) es un protocolo que permite a un programa de

ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las

comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el

momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones,

estando éstas encapsuladas dentro de las RPC.

Pagina 45


Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que

inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando

éste de vuelta el resultado de dicha operación al cliente.

Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun

denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de

Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es

compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL)

que define los métodos exportados por el servidor.

Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como

protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden

ser SOAP o XML-RPC.(ver imagen 15)

TIPOS DE SEMÁNTICA

Semántica tal-vez

Procedimiento remoto puede ejecutarse una vez o ninguna vez.

El cliente puede recibir una respuesta o ninguna.

Funcionamiento

1. El cliente envía una petición y se queda a la espera un tiempo determinado.

2. Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.

3. El cliente no tiene realimentación en caso de fallo (no sabe que pasó).

Pagina 46


Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de

respuestas con retraso (fuera de orden).

Semántica al-menos-una-vez

Procedimiento remoto se ejecuta una o más veces.

El cliente puede recibir una o más respuestas.

Funcionamiento

1. El cliente envía una petición y queda a la espera un tiempo.

2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.

3. El servidor no filtra peticiones duplicadas (el procedimiento remoto puede ejecutarse

repetidas veces).

4. El cliente puede recibir varias respuestas.

Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota:

Una operación es idempotente si se puede ejecutar varias veces resultando el mismo efecto que

si se hubiera ejecutado sólo una. En ocasiones una operación no idempotente puede

implementarse como una secuencia de operaciones idempotentes. Admisible en aplicaciones

donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento.

Semántica como-máximo-una-vez

El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna.

El cliente recibe una respuesta o una indicación de que no se ha ejecutado el procedimiento

remoto.

Pagina 47


Funcionamiento

1. El cliente envía la petición y queda a la espera un tiempo.

2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.

3. El servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas

(servidor con memoria). El procedimiento remoto sólo se ejecuta una vez.

4. El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no

recibe informe del error.

Areas de Problemas en RPC.

La RPC mediante el modelo C - S se utiliza ampliamente como base de los S. O. distribuidos

Lo ideal es que la RPC sea transparente:

El programador no debe poder decir si los procedimientos de biblioteca

son locales o remotos.

El programador debe poder escribir procedimientos sin importar si serán ejecutados en forma

local o remota.

La introducción de RPC en un sistema que se ejecutaba antes en una única cpu no debe ir

acompañada de una serie de reglas que:

o Prohiban construcciones antes válidas.

o Exijan construcciones que antes eran opcionales.

La mayoría de los S. O. distribuidos no cumplen totalmente con estos criterios

de transparencia.

Pagina 48


2.2 SINCRONIZACIÓN EN LOS SISTEMAS DISTRIBUIDOS

Además de la comunicación, es fundamental la forma en que los procesos

Cooperan.

Se sincronizan entre sí.

Ejemplos:

Forma de implantar las regiones críticas.

Forma de asignar recursos en un sistema distribuido.

Los problemas relativos a las regiones críticas, exclusión mutua y la sincronización:

Generalmente se resuelven en sistemas de una sola cpu con métodos como los semáforos y

los monitores:

o Se basan en la memoria compartida.

o No son aplicables a sistemas distribuidos.

Otro problema de gran importancia es el tiempo y la forma de medirlo, ya que juega un

papel fundamental en algunos modelos de sincronización.

2.2.1 SINCRONIZACIÓN DE RELOJES

Generalmente los algoritmos distribuidos tienen las siguientes propiedades

La información relevante se distribuye entre varias máquinas.

Los procesos toman las decisiones solo con base en la información disponible en forma local.

Pagina 49


Debe evitarse un único punto de fallo en el sistema.

No existe un reloj común o alguna otra fuente precisa del tiempo global.

Los primeros tres puntos indican que es inaceptable reunir toda la información en un solo lugar

para su procesamiento, pero lograr la sincronización sin centralización requiere hacer las

cosas distintas al caso de los sistemas operativos tradicionales.

El último punto también es crucial:

En un sistema centralizado el tiempo no es ambiguo.

En un sistema distribuido no es trivial poner de acuerdo a todas las máquinas en la hora.

Se requiere un acuerdo global en el tiempo, pues la falta de sincronización en los relojes

puede ser drástica en procesos dependientes del tiempo.

La pregunta es si es posible sincronizar todos los relojes en un sistema distribuido.

Relojes Lógicos.

Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj

Es un cronómetro consistente en un cristal de cuarzo de precisión sometido a una tensión

eléctrica que:

Oscila con una frecuencia bien definida que depende de:

o Al forma en que se corte el cristal.

o El tipo de cristal.

o La magnitud de la tensión.

Pagina 50


A cada cristal se le asocian dos registros:

o Registro contador.

o Registro mantenedor.

Cada oscilación del cristal decrementa en “1” al contador.

Cuando el contador llega a “0”:

o Se genera una interrupción.

o El contador se vuelve a cargar mediante el registro mantenedor.

Se puede programar un cronómetro para que genere una interrupción “x” veces por segundo.

Cada interrupción se denomina marca de reloj.

Lamport utiliza la relación “ocurre antes de”:

o Si “c” sale en “60” debe llegar en “61” o en un tiempo posterior.

o Cada mensaje acarrea el tiempo de envío, de acuerdo con el reloj del emisor.

o Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se

envió el mensaje:

El receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío.(ver

imagen 16)

Relojes Físicos.

El algoritmo de Lamport proporciona un orden de eventos sin ambigüedades, pero

Los valores de tiempo asignados a los eventos no tienen por qué ser cercanos a los tiempos

reales en los que ocurren.

En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:

Pagina 51


o Se precisan relojes físicos externos (más de uno).

o Se deben sincronizar:

Con los relojes del mundo real.

Algoritmos Para la Sincronización de Relojes.

Si una máquina tiene un receptor de UTC, todas las máquinas deben sincronizarse con ella.

Si ninguna máquina tiene un receptor de UTC:

Cada máquina lleva el registro de su propio tiempo.

Se debe mantener el tiempo de todas las máquinas tan cercano como sea posible.

Se supone que cada máquina tiene un cronómetro que provoca una interrupción “h” veces por

segundo.

Cuando el cronómetro se detiene, el manejador de interrupciones añade “1” a un reloj en

software.

El reloj en software mantiene un registro del número de marcas (interrupciones) a partir de

cierta fecha acordada antes; al valor de este reloj se lo llama “C”.

Cuando el tiempo UTC es “t”, el valor del reloj en la máquina “p” es “Cp(t)”:

Lo ideal sería que “Cp(t)” = “t” para toda “p” y todo “t”:

o “dC/dt” debería ser “1”.

Lo real es que los cronómetros no realizan interrupciones exactamente “h” veces por

segundo:

Pagina 52


o Poseen un error relativo de aproximadamente 10-5 .

o El fabricante especifica una constante “ r ” llamada tasa máxima de alejamiento que acota el

error.

o El cronómetro funciona dentro de su especificación si existe una constante “ r ” y se cumple:

1 - r £dC / dt £ 1 + r.

Si dos relojes se alejan de UTC en la dirección opuesta:

En un instante Dt luego de la sincronización podrían estar tan alejados como: 2 rDt.

Para garantizar que no difieran más de d:

o Se deben volver a sincronizar (en software) al menos cada d / 2 r segundos.(ver imagen 17)

2.2.2 EXCLUSIÓN MUTUA

Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas:

Primero ingresa a una región crítica para lograr la exclusión mutua y garantizar que ningún

otro proceso utilizará las estructuras de datos al mismo tiempo.

En sistemas monoprocesadores las regiones críticas se protegen con semáforos, monitores y

similares.

En sistemas distribuidos la cuestión es más compleja.

Un Algoritmo Centralizado

La forma más directa de lograr la exclusión mutua en un sistema distribuido es simular a la

forma en que se lleva a cabo en un sistema monoprocesador.

Pagina 53


Se elige un proceso coordinador.

Cuando un proceso desea ingresar a una región crítica:

Envía un mensaje de solicitud al coordinador:

o Indicando la región crítica.

o Solicitando permiso de acceso.

Si ningún otro proceso está en ese momento en esa región crítica:

o El coordinador envía una respuesta otorgando el permiso.

Cuando llega la respuesta el proceso solicitante entra a la región crítica.

La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los

procesos que esperan una respuesta de habilitación de acceso.

Un Algoritmo Distribuido

El objetivo es no tener un único punto de fallo (el coordinador central).

Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala.

Se requiere un orden total de todos los eventos en el sistema para saber cuál ocurrió primero.

Cuando un proceso desea entrar a una región crítica:

Construye un mensaje con el nombre de la región crítica, su número de proceso y la hora

actual.

Envía el mensaje a todos los demás procesos y de manera conceptual a él mismo.

Se supone que cada mensaje tiene un reconocimiento.

Pagina 54


Otro problema es que:

Se utilizará una primitiva de comunicación en grupo o,

Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos que

ingresan, los que salen y los que fallan.

Se complica para gran número de procesos.

Un importante problema adicional es que:

Todos los procesos participan en todas las decisiones referentes a las entradas en las regiones

críticas.

Se sobrecarga el sistema.

Una mejora consiste en permitir que un proceso entre a una región crítica con el permiso de una

mayoría simple de los demás procesos (en vez de todos):

Luego de que un proceso otorgó el permiso a otro para entrar a una región crítica, no puede

otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso.

Un Algoritmo de Anillo de Fichas (Token Ring)

Los procesos se organizan por software formando un anillo lógico asignándose a cada proceso

una posición en el anillo.

Cada proceso sabe cuál es el siguiente luego de él.

Al inicializar el anillo se le da al proceso “0” una ficha (token) que circula en todo el anillo, que

se transfiere del proceso “k” al “k + 1” en mensajes puntuales.

Pagina 55


Cuando un proceso obtiene la ficha de su vecino verifica si intenta entrar a una región crítica:

En caso positivo:

o El proceso entra a la región crítica, hace el proceso necesario y sale de ella.

o Después de salir pasa la ficha a lo largo del anillo:

No se puede entrar a una segunda región crítica con la misma ficha (token o permiso).

En caso negativo:

o La vuelve a pasar. (ver imagen 18)

2.2.3 ALGORITMOS DE ELECCIÓN

Son los algoritmos para la elección de un proceso coordinador, iniciador, secuenciador, etc.

El objetivo de un algoritmo de elección es garantizar que iniciada una elección ésta concluya

con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador.

El Algoritmo del Grandulón o de García-Molina.

Un proceso “P” inicia una elección cuando observa que el coordinador ya no responde a las

solicitudes.

“P” realiza una elección de la siguiente manera:

Envía un mensaje elección a los demás procesos con un número mayor.

Si nadie responde asume que gana la elección y se convierte en el nuevo coordinador.

Si un proceso con un número mayor responde, toma el control y el trabajo de “P” termina.

Pagina 56


Un proceso puede recibir en cualquier momento un mensaje elección de otros procesos con un

número menor:

Envía de regreso un mensaje o.k. al emisor para indicar que está vivo y que tomará el control.

Realiza una elección salvo que ya esté haciendo alguna.

En cierto momento todos los procesos han declinado ante uno de ellos, que será el nuevo

coordinador, que envía un mensaje coordinador a todos los procesos para anunciarlo.

Un Algoritmo de Anillo.

Se supone que los procesos tienen un orden físico o lógico, es decir que cada proceso conoce a

su sucesor.

Cuando algún proceso observa que el coordinador no funciona:

Construye un mensaje elección con su propio número de proceso.

Envía el mensaje a su sucesor.

Concluida la ronda de información el mensaje coordinador se elimina y continúan los

procesos.(ver imagen 19)

2.2.4 EL MODELO DE TRANSACCIÓN

Supondremos que:

El sistema consta de varios procesos independientes que pueden fallar aleatoriamente.

El software subyacente maneja transparentemente los errores de comunicación.

Pagina 57


Almacenamiento Estable

Se puede implantar con una pareja de discos comunes.

Cada bloque de la unidad 2 es una copia exacta (espejo) del bloque correspondiente en la unidad

Cuando se actualiza un bloque:

Primero se actualiza y verifica el bloque de la unidad 1.

Luego se actualiza y verifica el bloque de la unidad 2.

Si el sistema falla luego de actualizar la unidad 1 y antes de actualizar la unidad 2:

Luego de la recuperación se pueden comparar ambos discos bloque por bloque:

o Se puede actualizar la unidad 2 en función de la 1.

Si se detecta el deterioro espontáneo de un bloque, se lo regenera partiendo del bloque

correspondiente en la otra unidad.

Un esquema de este tipo es adecuado para las aplicaciones que requieren de un alto grado de

tolerancia de fallos, por ej. las transacciones atómicas.

Propiedades de las Transacciones

Las propiedades fundamentales son:

Serializacion:

o Las transacciones concurrentes no interfieren entre sí.

Atomicidad:

Pagina 58


o Para el mundo exterior, la transacción ocurre de manera indivisible.

Permanencia:

o Una vez comprometida una transacción, los cambios son permanentes.

2.2.5 BLOQUEOS EN SISTEMAS DISTRIBUIDOS

Son peores que los bloqueos en sistemas monoprocesador

Son más difíciles de evitar, prevenir, detectar y solucionar.

Toda la información relevante está dispersa en muchas máquinas.

Son especialmente críticos en sistemas de bases de datos distribuidos.

Las estrategias usuales para el manejo de los bloqueos son:

Algoritmo del avestruz:

o Ignorar el problema.

Detección:

o Permitir que ocurran los bloqueos, detectarlos e intentar recuperarse de ellos.

Prevención:

o Hacer que los bloqueos sean imposibles desde el punto de vista estructural.

Evitarlos:

o Evitar los bloqueos mediante la asignación cuidadosa de los recursos.

El algoritmo del avestruz merece las mismas consideraciones que en el caso de mono-

procesador.

Pagina 59


Detección Distribuida de Bloqueos

Cuando se detecta un bloqueo en un S. O. convencional se resuelve eliminando uno o más

procesos.

Cuando se detecta un bloqueo en un sistema basado en transacciones atómicas se

resuelve abortando una o más transacciones:

El sistema restaura el estado que tenía antes de iniciar la transacción.

La transacción puede volver a comenzar.

Las consecuencias de la eliminación de un proceso son mucho menos severas si se utilizan

las transacciones que en caso de que no se utilicen.

Detección Centralizada de Bloqueos

Cada máquina mantiene la gráfica de recursos de sus propios procesos y recursos.

Un coordinador central mantiene la gráfica de recursos de todo el sistema, que es la unión de

todas las gráficas individuales.

Cuando el coordinador detecta un ciclo elimina uno de los procesos para romper el bloqueo.

La información de control se debe transmitir explícitamente, existiendo las siguientes variantes:

Cada máquina informa cada actualización al coordinador.

Pagina 60


Cada máquina informa periódicamente las modificaciones desde la última actualización.

El coordinador requiere la información cuando la necesita.

Detección Distribuida de Bloqueos

Un algoritmo típico es el de Chandy-Misra-Haas.

Los procesos pueden solicitar varios recursos (por ejemplo cerraduras) al mismo tiempo, en vez

de uno cada vez.

Se permiten las solicitudes simultáneas de varios procesos:

Un proceso puede esperar a uno o más recursos simultáneamente.

Los recursos que espera un proceso pueden ser locales o remotos (de otra máquina).

Si el proceso “0” se bloquea debido al proceso “1”:

Se genera un mensaje de exploración que se envía al proceso (o procesos) que detienen los

recursos necesarios.

El mensaje consta de tres números:

o El proceso recién bloqueado, el proceso que envía el mensaje y el proceso al cual se envía.

Al llegar el mensaje el receptor verifica si él mismo espera a algunos procesos, en cuyo caso:

o El mensaje se actualiza:

Se conserva el primer campo.

Prevención Distribuida de Bloqueos

Pagina 61


La prevención consiste en el diseño cuidadoso del sistema para que los bloqueos sean

imposibles estructuralmente.

Entre las distintas técnicas se incluye:

Permitir a los procesos que solo conserven un recurso a la vez.

Exigir a los procesos que soliciten todos sus recursos desde un principio.

Hacer que todos los procesos liberen todos sus recursos cuando soliciten uno nuevo.

Probablemente conservan más recursos. (ver imagen 20)

2.3 PROCESOS Y PROCESADORES EN SISTEMAS DISTRIBUIDOS

2.3.1 HILOS

Muchos S. O. distribuidos soportan múltiples hilos de control dentro de un proceso que:

Comparten un único espacio de direcciones.

Se ejecutan quasi - paralelamente como si fueran procesos independientes.

Ej.: servidor de archivos que debe bloquearse ocasionalmente en espera de acceso al disco:

Si tiene varios hilos de control podría ejecutar un segundo hilo mientras el primero espera:

o El resultado sería mejor rendimiento y desempeño.

o No se logra esto con procesos servidores independientes puesto que deben compartir un

buffer caché común y deben estar en el mismo espacio de direcciones.

Pagina 62


En muchos sentidos los hilos son como mini procesos:

Los distintos hilos de un proceso comparten un espacio de direcciones, el conjunto de archivos

abiertos, los procesos hijos, cronómetros, señales, etc.

Los hilos pueden tener distintos estados: en ejecución, bloqueado, listo, terminado.

Uso de Hilos

Los hilos permiten la combinación del paralelismo con la ejecución secuencial y el bloqueo de

las llamadas al sistema

Consideramos el ejemplo del servidor de archivos con sus posibles organizaciones para muchos

hilos de ejecución.

Iniciamos con el modelo servidor / trabajador:

Un hilo, el servidor, lee las solicitudes de trabajo en el buzón del sistema.

Elige a un hilo trabajador inactivo (bloqueado) y le envía la solicitud, despertándolo.

El hilo trabajador verifica si puede satisfacer la solicitud por medio del bloque caché

compartido, al que tienen acceso todos los hilos.

Si no envía un mensaje al disco para obtener el bloque necesario y se duerme esperando el fin

de la operación.

Se llama:

o Al planificador y se inicializa otro hilo, que tal vez sea el servidor, para pedir más trabajo; o.

o A otro trabajador listo para realizar un trabajo.

Pagina 63


Los hilos ganan un desempeño considerable pero cada uno de ellos se programa en forma

secuencial.

Aspectos del Diseño de un Paquete de Hilos

Un conjunto de primitivas relacionadas con los hilos (ej.: llamadas a biblioteca) disponibles para

los usuarios se llama un “paquete de hilos”.

Respecto del manejo de los hilos se tienen hilos estáticos e hilos dinámicos.

En un diseño estático:

Se elige el número de hilos al escribir el programa o durante su compilación.

Cada uno de ellos tiene asociada una pila fija.

Se logra simplicidad pero también inflexibilidad.

En un diseño dinámico:

Se permite la creación y destrucción de los hilos durante la ejecución.

La llamada para la creación de hilos determina:

o El programa principal del hilo.

o Un tamaño de pila.

o Una prioridad de planificación, etc.

La llamada generalmente regresa un identificador de hilo

Un proceso:

o Se inicia con un solo hilo.

o Puede crear el número necesario de hilos.

Pagina 64


Implantación de un Paquete de Hilos

Un paquete de hilos se puede implantar en el espacio:

Del usuario.

Del núcleo.

Implantación del paquete de hilos en el espacio del usuario:

El núcleo no sabe de su existencia.

El núcleo maneja procesos con un único hilo.

No requiere soporte de hilos por parte del S. O.

Los hilos se ejecutan en un sistema de tiempo de ejecución:

o Es un grupo de procedimientos que manejan los hilos.

Cuando un hilo ejecuta una llamada al sistema o cualquier acción que pueda provocar su

suspensión:

o Llama a un procedimiento del sistema de tiempo de ejecución.

o El procedimiento verifica si hay que suspender al hilo, en cuyo caso:

Almacena los registros del hilo en una tabla.

Busca un hilo no bloqueado para ejecutarlo.

Vuelve a cargar los registros de la máquina con los valores resguardados del nuevo hilo.

Las principales ventajas son:

Pagina 65


o El intercambio de hilos es más rápido que si se utilizaran los señalamientos al núcleo.

o Cada proceso puede tener su propio algoritmo adaptado de planificación de hilos.

o Tienen una mejor escalabilidad para un número muy grande de hilos, ya que no afectan al

núcleo con tablas y bloques de control (pila). Un problema fundamental de los paquetes de hilos

a nivel usuario es el de las llamadas al sistema con bloqueo.(ver imagen 21)

2.3.2 MODELOS DE SISTEMAS

En un sistema distribuido, con varios procesadores, un aspecto fundamental del diseño

es cómo se los utiliza.

Los procesadores distribuidos se pueden organizar de varias formas:

Modelo de estación de trabajo.

Modelo de la pila de procesadores.

Modelo híbrido.

El Modelo de Estación de Trabajo

El sistema consta de estaciones de trabajo (PC) dispersas conectadas entre sí mediante una red

de área local (LAN).

Pueden contar o no con disco rígido en cada una de ellas.

Los usuarios tienen:

Una cantidad fija de poder de cómputo exclusiva.

Pagina 66


Un alto grado de autonomía para asignar los recursos de su estación de trabajo.

Uso de los discos en las estaciones de trabajo:

Sin disco:

o Bajo costo, fácil mantenimiento del hardware y del software, simetría y flexibilidad.

o Gran uso de la red, los servidores de archivos se pueden convertir en cuellos de botella.

Disco para paginación y archivos de tipo borrador:

o Reduce la carga de la red respecto del caso anterior.

o Alto costo debido al gran número de discos necesarios.

Disco para paginación, archivos de tipo borrador y archivos binarios (ejecutables):

o Reduce aún más la carga sobre la red.

Uso de Estaciones de Trabajo Inactivas

La idea consiste en ordenar remotamente la ejecución de procesos en estaciones de trabajo

inactivas.

Los aspectos clave son:

¿Cómo encontrar una estación de trabajo inactiva?.

¿Cómo lograr que un proceso remoto se ejecute de forma transparente?.

¿Qué ocurre si regresa el poseedor de la máquina?.

Generalmente se considera que una estación de trabajo está “inactiva” cuando se dan ambas

condiciones:

Pagina 67


Nadie toca el ratón o el teclado durante varios minutos.

No se ejecuta algún proceso iniciado por el usuario.

Los algoritmos para localizar las estaciones de trabajo inactivas se pueden dividir en dos

categorías:

Controlados por el servidor.

Controlados por el cliente.

Algoritmos controlados por el servidor:

Cuando una estación de trabajo está inactiva:

o Se convierte en un servidor potencial.

o Anuncia su disponibilidad:

Proporciona su nombre, dirección en la red y propiedades:

Grabándolos en un archivo, o.

Transmitiéndolos a las otras estaciones.

El Modelo de la Pila de Procesadores.

Se dispone de un conjunto de cpu que se pueden asignar dinámicamente a los usuarios según la

demanda. Los usuarios no disponen de estaciones de trabajo sino de terminales gráficas de alto

rendimiento. No existe el concepto de propiedad de los procesadores, los que pertenecen a todos

y se utilizan compartidamente.

El principal argumento para la centralización del poder de cómputo como una pila de

procesadores proviene de la teoría de colas:

Pagina 68


Llamamos “l” a la tasa de entradas totales de solicitudes por segundo de todos los usuarios

combinados.

Llamamos “m” a la tasa de procesamiento de solicitudes por parte del servidor.

Para una operación estable debe darse que “m > l”:

o Se pueden permitir pequeños lapsos de tiempo en los que la tasa de entrada exceda a la de

servicio.

Llamamos “T” al promedio de tiempo entre la emisión de una solicitud y la obtención de una

respuesta completa:

o T = 1 / ( m - l ).

o Cuando “ l ” tiende a “0”, “T” no tiende a “0”.

2.3.3 MODELOS DE ASIGNACIÓN

Generalmente se utilizan las siguientes hipótesis.

Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo

en la velocidad.

Cada procesador se puede comunicar con los demás.

Las estrategias de asignación de procesadores se dividen en:

No migratorias:

o Una vez colocado un proceso en una máquina permanece ahí hasta que termina.

Migratorias:

Pagina 69


o Un proceso se puede trasladar aunque haya iniciado su ejecución.

o Permiten un mejor balance de la carga pero son más complejas.

Los algoritmos de asignación intentan optimizar algo:

Uso de las cpu:

o Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.

o Minimizar el tiempo de inactividad de las cpu.

Tiempo promedio de respuesta:

o Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.

Tasa de respuesta:

o Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta

máquina dividido por el tiempo que tardaría en cierto procesador de referencia.

Aspectos del Diseño de Algoritmos de Asignación de Procesadores

Los principales aspectos son los siguientes:

Algoritmos deterministas vs. heurísticos.

Algoritmos centralizados vs. distribuidos.

Algoritmos óptimos vs. subóptimos.

Algoritmos locales vs. globales.

Algoritmos iniciados por el emisor vs. iniciados por el receptor.

Pagina 70


Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del

comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en

ciertos casos aproximaciones estadísticas.

Los algoritmos heurísticos son adecuados cuando la carga es impredecible.

Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor

decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante

su posible falla.

Generalmente los algoritmos óptimos consumen más recursos que los subóptimos, además, en la

mayoría de los sistemas reales se buscan soluciones subóptimas, heurísticas y distribuidas.

Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en

otra (política de transferencia):

La decisión se puede tomar “solo con información local” o “con información global”.

Los algoritmos locales son sencillos pero no óptimos.

Los algoritmos globales son mejores pero consumen muchos recursos.

Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde

enviarlo:

Necesita información de la carga en todas partes, obteniéndola de:

o Un emisor sobrecargado que busca una máquina inactiva.

o Un receptor desocupado que busca trabajo.(ver imagen 22)

Pagina 71


2.3.4 PLANIFICACIÓN EN SISTEMAS DISTRIBUIDOS

Generalmente cada procesador hace su planificación local (si tiene varios procesos en ejecución)

independientemente de lo que hacen los otros procesadores.

La planificación independiente no es eficiente cuando se ejecutan en distintos procesadores

un grupo de procesos:

Relacionados entre sí.

Con una gran interacción entre los procesos.

Se necesita una forma de garantizar que los procesos con comunicación frecuente se ejecuten de

manera simultánea.

En muchos casos un grupo de procesos relacionados entre sí iniciarán juntos.

La comunicación dentro de los grupos debe prevalecer sobre la comunicación entre los grupos.

Se debe disponer de un número de procesadores suficiente para soportar al grupo de mayor

tamaño.

Pagina 72


Cada procesador se multiprograma con “n” espacios para los procesos (multiprogramación de

nivel “n”).

El algoritmo de Ousterhout utiliza el concepto de coplanificación:

Toma en cuenta los patrones de comunicación entre los procesos durante la planificación.

Debe garantizar que todos los miembros del grupo se ejecuten al mismo tiempo.

Se emplea una matriz conceptual donde:

o Las filas son espacios de tiempo.

o Las columnas son las tablas de procesos de los procesadores.

2.3.5 TOLERANCIA A FALLOS

El objetivo de diseñar y construir sistemas distribuidos tolerantes a fallos es garantizar que el

sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.

Se dice que un sistema falla cuando no cumple su especificación. Como las computadoras y los

sistemas distribuidos se utilizan cada vez m[as en misiones donde la seguridad es críticas, la

necesidad de soportar las fallas cada vez es mayor.

Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados

para proveer un servicio específico. Un desperfecto de un sistema ocurre cuando el sistema no

desempeña estos servicios de manera especificada. Un estado erróneo en un sistema es un estado

en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las

Pagina 73

http://samadistribuidos.blogspot.com/2012/05/tolerancia-fallos.html


causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o

en la implementación), problemas de fabricación, deterioro por el uso u otros problemas

externos (como condiciones ambientales adversas, interferencia electromagnética, entradas

imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere

de los valores esperados.

Es necesario que el sistema sea capaz de recuperarse de las fallas, entonces necesitamos

deshacernos del estado de error del sistema.

Clasificación De Las Fallas.

Falla De Procesos.

Aquí, la ejecución arroja un resultado incorrecto, los procesos provocan que el sistema se desvíe

de las especificaciones y el proceso puede suspender su progreso. Por ejemplo interbloqueos,

tiempo expirado, violación de protección, error en la entrada provista por el usuario, violaciones

de consistencia.

Falla Del Sistema.

Es cuando el procesador falla en la ejecución. Esto es causado por errores de software y

problemas de hardware, como por ejemplo errores de CPU, falla en la memoria principal, falla

en el bus, falla de energía, etc.

Recuperación De Errores.

Ya dijimos que un error es una parte del estado del sistema que es distinto a los valores

esperados, así, la recuperación de una falla es un proceso que involucra la recuperación de

estados erróneos a un estado libre de error.

Pagina 74


Hay dos enfoques para la recuperación de un estado de error a un estado libre de error.

- Si la naturaleza del error y los daños causados pueden ser completamente calculados, entonces

es posible remover esos errores del estado del proceso (o sistema) y habilitar el movimiento

hacia adelante del proceso a un estado libre de error. Esta técnica es conocida

como recuperación hacia adelante.

Elementos de las estrategias tolerantes a fallas.

Al momento de diseñar un sistema tolerante a fallas se puede hacer desde dos puntos de vista:

- Puede ocultar la falla

- Puede corregir la falla y seguir funcionando

En el primero, al ocurrir una falla, el sistema continua con sus funciones específicas. En el

segundo, el sistema puede o no ejecutar funciones específicas, sin embargo, puede seguir

acciones para recuperación.

Estrategia Tolerante A Fallas.

Redundancia. Con este enfoque, el sistema puede emplear varios procesos, muchos

componentes de hardware, muchas copias de datos, etc. Cada uno con independencia en el modo

de la falla, esto quiere decir que si un componente falla no afecta a los demás componentes.

Se utilizan dos protocolos en las técnicas para sistemas tolerantes a fallas:

Protocolo de compromiso: se utiliza para sistemas que hasta cierto punto pueden corregir las

fallas

Protocolo de elección: es utilizado para sistemas que ocultan las fallas.

Pagina 75


Efectos De Fallas Más Comunes.

Un proceso muere

Cuando un proceso muere, es importante que los recursos asignados al proceso sean

recuperados, de otra manera pueden estar perdidos permanentemente.

La máquina falla

Todos los procesos ejecutándose en la máquina se mueren. La diferencia con el caso anterior es

como detectar la falla.

La red falla (ver imagen 23)

2.3.6 SISTEMAS DISTRIBUIDOS EN TIEMPO REAL

La naturaleza de los sistemas distribuidos de tiempo real (SDTR) requiere técnicas de análisis,

diseño y prueba específicas que permitan representar las situaciones típicas de estos sistemas.

Un sistema distribuido de tiempo real debe interactuar con el mundo real, en puntos físicamente

distantes, en periodos de tiempo que vienen determinados por el contexto o las restricciones de

la especificación (en muchos casos a partir de una activación asincrónica).

La evolución tecnológica en el tratamiento de señales (locales o remotas) y en los sistemas de

comunicaciones ha impulsado enormemente esta área temática, sobre todo en los aspectos de

planificación y desarrollo de software para Sistemas

Distribuidos de Tiempo Real [HAT88] [LAP93] [SHU92].

Pagina 76


Como cualquier sistema basado en computadora, un SDTR debe integrar software, hardware,

personas, bases de datos, no solo para cumplir con los requisitos funcionales del sistema, sino

también con los requerimientos de rendimiento.

Las dificultades principales del desarrollo de software para sistemas de tiempo real son:

• Controlar hardware en forma directa

• Procesar mensajes que arriban en forma asincrónica, con diferentes velocidades y diferentes

prioridades

• Detectar y controlar condiciones de falla. Prever diferentes grados de recuperación del sistema.

• Manejar colas y buffers de almacenamiento y mensajes.

• Modelizar condiciones de concurrencia en un conjunto apropiado de procesos.

• Asignar procesos lógicos a procesadores fisicos (si se dispone de ellos).

• Manejar las comunicaciones inter-procesos e inter-procesadores.

• Proteger datos compartidos por procesos concurrentes.

• Organizar (schedule) y despachar la atención de procesos.

• Manejar las restricciones de tiempo y performance.

• Relacionarse con un reloj de tiempo real y evitar desfasajes de procesadores - tiempos.

• Testear y poner a punto un sistema que normalmente está distribuido en diferentes

procesadores.

• Elaborar herramientas de software que permitan simular o emular dispositivos o eventos de

hardware no disponibles en el desarrollo.

• Reducir y estructurar los requerimientos.

• Seleccionar la estructura de hardware adecuada.

Mecanismos de especificación y verificación de restricciones de tiempo.

Pagina 77


Existen numerosos enfoques que tienden a la especificación y verificación de restricciones de

tiempo entre los que se cuentan los lenguajes de simulación, las aproximaciones axiomáticas y

las Redes de Petri.

En particular las Redes de Petri son un elemento útil para modelar sistemas en los que existen

dependencias secuenciales dinámicas y consideraciones de procesamiento concurrente, por las

siguientes características:

• Son inherentemente paralelas y soportan eventos asincrónicos.

• Permiten una representación explícita de las dependencias causales y de las interdependencias

entre procesos.

• Permiten la descripción de un sistema en diferentes niveles de abstracción

• Favorecen la verificación y en particular la detección de situaciones críticas (por ejemplo

deadlocks).

• Soportan extensiones para manipular temporizaciones aleatorias y/o determinísticas.

Para poder utilizarlas en modelizaciones de Sistemas de Tiempo Real se incorporan restricciones

de tiempo y se han extendido las clases de arcos del grafo de Petri para simular condiciones de

funcionamiento. De esta manera pueden modelarse fenómenos tales como tiempo entre llegadas

de eventos externos, tiempos de reacción, duración de actividades, tiempos de time out, acciones

periódicas, etc. Actualmente se está investigando la incorporación de las Redes de Petri

extendidas a ambientes CASE orientados a tratamiento de sistemas de tiempo real y asimismo se

están estudiando variantes (en particular Queued Petri Nets y la incorporación de atributos a los

tokens) para analizar mejor fenómenos de espera y de manejo de datos distinguidos dentro del

sistema.

Pagina 78


Sistemas DTR:

Los sistemas de tiempo real (STR) y los sistemas distribuidos de tiempo Real (SDTR) son

sistemas de tiempo crítico, es decir, se trata de aplicaciones para las cuales el tiempo en que se

produce la respuesta es un requerimiento esencial.

Por lo general, un STR o SDTR incluye un conjunto de dispositivos independientes (hardware y

software) que operan a diferentes velocidades. Deben satisfacer requerimientos de performance.

Comparando con un sistema tradicional, se debe tener especial control sobre la utilización de

recursos, mejora en los tiempos de respuesta y manejo de distintas prioridades.

Existen algunas diferencias importantes entre un sistema de software tradicional y uno de

tiempo real:

• Control de dispositivos externos.

• Procesamiento de mensajes que pueden llegar en intervalos irregulares.

• Detección y control de condiciones de falla.

• Modelización de condiciones concurrentes.

• A locación y control de procesos concurrentes.

• Manejo las comunicaciones entre procesos.

• Protección de datos compartidos.

• Manejo de requerimientos de tiempos y performance.

• Testeo y debug de procesos concurrentes.

• Diseño de simuladores del hardware que no se encuentra disponible durante la fase de pruebas.

Pagina 79


• Selección del hardware adecuado para soportar el diseño del software.

• Distribución de tareas.

Se espera que un STR se ejecute en forma continua, automática y segura, teniendo un impacto

en los costos de desarrollo y la seguridad.

En particular nos interesan las aplicaciones industriales, caracterizadas por la distribución y el

control del tiempo.

Claramente un STR tiene que emplear herramientas de desarrollo y modelado diferentes a las

utilizadas en el desarrollo de software tradicional que es la temática correspondiente a los temas

del Subproyectos 2 del III-LIDI en relación a la Ingeniería de Software de Sistemas Distribuidos

y Sistemas Distribuidos en Tiempo Real.(ver imagen 24)

2.4 SISTEMAS DE ARCHIVOS

Sistemas Distribuidos De Archivos.

Muchos aspectos son similares a los de los sistemas convencionales centralizados.

En un sistema distribuido es importante distinguir entre los conceptos de servicio de archivos y

el servidor de archivos.

El servicio de archivos:

Es la especificación de los servicios que el sistema de archivos ofrece a sus clientes.

Describe las primitivas disponibles, los parámetros que utilizan y las acciones que llevan a

cabo.

Pagina 80


Define precisamente el servicio con que pueden contar los clientes sin decir nada respecto de

su implantación.

El despachador (servidor) de archivos:

Es un proceso que se ejecuta en alguna máquina y ayuda con la implantación del servicio de

archivos.

Puede haber uno o varios en un sistema.

Los clientes no deben ser conscientes de la forma de implantar el sistema de archivos:

o No precisan conocer el número de servidores de archivos, su posición o función.

o Deberían ver al sistema distribuido de archivos como un sistema de archivos normal de

uniprocesador.

Generalmente un servidor de archivos es un proceso del usuario (a veces del núcleo) que se

ejecuta en una máquina:

Un sistema puede contener varios servidores de archivos, cada uno con un servicio distinto:

o Ej.: un sistema con un servidor de archivos en “UNIX” y otro en “DOS”.

o Cada proceso usuario utilizaría el servidor apropiado.

2.4.1 DISEÑO DE LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS

Los componentes de un sistema distribuido de archivos son:

El verdadero servicio de archivos:

Pagina 81


o Realiza operaciones en los archivos individuales: lectura, escritura, adición.

El servicio de directorios:

o Crea y maneja directorios, añade y elimina archivos de los directorios, etc.

La Interfaz del Servicio de Archivos.

La protección en los sistemas distribuidos utiliza las mismas técnicas de los sistemas con

uniprocesador:

Posibilidades:

o Cada usuario tiene un permiso o posibilidad para cada objeto al que tiene acceso:

Determina los tipos de accesos permitidos.

Listas para control de acceso:

o Se asocia a cada archivo una lista implícita o explícita de:

Los usuarios que pueden tener acceso al archivo.

Los tipos de acceso permitidos a cada uno de ellos.

Los servicios de archivos se pueden clasificar en dos tipos:

Modelo carga / descarga:

o Las principales operaciones son la lectura de un archivo y la escritura en un archivo.

o La lectura transfiere todo un archivo de uno de los servidores de archivos al cliente

solicitante.

o La escritura transfiere en sentido contrario.

o Los archivos se pueden almacenar en memoria o en un disco local.

Modelo de acceso remoto:

Pagina 82


o El sistema de archivos se ejecuta con todas las funciones en los servidores y no en los

clientes.(ver imagen 25)

2.4.2 IMPLANTACIÓN DE UN SISTEMA DISTRIBUIDO DE ARCHIVOS

Uso de Archivos

Antes de implantar un sistema de archivos resulta de interés analizar los “patrones de uso” de

dichos archivos.

Para determinar los patrones de uso es necesario tomar mediciones que pueden ser:

Estáticas:

o Representan una toma instantánea del sistema en un momento dado.

o – Comprenden la distribución de tamaño de los archivos, la distribución de tipo de archivos,

la cantidad de espacio que ocupan los archivos de varios tamaños y tipos, etc.

Dinámicas:

o Registran en una bitácora todas las operaciones que modifican el sistema de archivos.

o Comprenden información sobre la frecuencia relativa de varias operaciones, el número de

archivos abiertos en un momento dado, la cantidad de archivos compartidos, etc.

Las principales propiedades observadas son:

La mayoría de los archivos son pequeños.

La lectura es más común que la escritura.

Pagina 83


La mayoría de los accesos es secuencial.

La mayoría de los archivos son de corta vida.

Es poco usual compartir archivos.

Los procesos promedio utilizan pocos archivos.

Distintas clases de archivos poseen propiedades distintas.

Estructura del Sistema

En ciertos sistemas no existe distinción entre un cliente y un servidor:

Todas las máquinas ejecutan el mismo software básico.

Una máquina que desee dar servicio de archivos lo puede hacer:

o Debe exportar los nombres de los directorios seleccionados, para que otras máquinas los

puedan acceder.

En otros sistemas el servidor de archivos y el de directorios son solo programas del usuario, y se

puede configurar un sistema para que ejecute o no el software de cliente o servidor en la misma

máquina.

Los clientes y servidores también podrían ser máquinas totalmente distintas en términos de

hardware o de software.

Ocultamiento

En un sistema cliente - servidor, cada uno con su memoria principal y un disco, existen

cuatro lugares donde se pueden almacenar los archivos o partes de ellos:

Pagina 84


El disco del servidor.

La memoria principal del servidor.

El disco del cliente (si existe).

La memoria principal del cliente.

Si los archivos se almacenan en el disco del servidor:

Disponen de abundante espacio.

Serían accesibles a todos los clientes.

No habrá problemas de consistencia al existir solo una copia de cada archivo.

Puede haber problemas de desempeño:

o Antes de que un cliente pueda leer un archivo se lo debe transferir:

Del disco del servidor a la memoria principal del servidor.

De la memoria principal del servidor a la memoria principal del cliente, a través de la red.

Se puede mejorar el desempeño ocultando (conservando) los archivos de más reciente uso en

la memoria principal del servidor:

o Un cliente que lea un archivo ya presente en el caché del servidor elimina la transferencia del

disco.

o Se necesita un algoritmo para determinar los archivos o partes de archivos que deben

permanecer en el caché.

Consistencia del Caché

El ocultamiento por parte del cliente introduce inconsistencia en el sistema.

Pagina 85


Si dos clientes leen un mismo archivo en forma simultánea y después lo modifican, aparecen

algunos problemas:

Cuando un tercer proceso lee el archivo del servidor obtendrá la versión original y no alguna

de las nuevas:

o Se puede evitar mediante la “semántica de sesión”:

o No es aplicable cuando se requiere la “semántica de UNIX”.

Cuando dos archivos se escriben de nuevo al servidor, el último de ellos se escribirá sobre el

otro.

Una solución a la inconsistencia del caché es el algoritmo de escritura a través del caché:

Cuando se modifica una entrada del caché (archivo o bloque), el nuevo valor:

o Se mantiene dentro de él.

o Se envía de inmediato al servidor.

Los principales problemas de la escritura a través del caché son los siguientes:

Posible suministro de valores obsoletos:

o Un proceso cliente en la máquina “A” lee un archivo “f ” y mantiene a “f ” en su caché.

o Un cliente en la máquina “B” lee el mismo archivo, lo modifica y lo escribe en el servidor.

o Otro proceso cliente inicia en la máquina “A” abriendo y leyendo “f ”, que se toma del caché.

o El valor de “f” es obsoleto.

Réplica.

Pagina 86


Frecuentemente los sistemas distribuidos de archivos proporcionan la réplica de archivos como

un servicio:

Existen varias copias de algunos archivos.

Cada copia está en un servidor de archivos independiente.

Las principales razones para la réplica son:

Aumentar la confiabilidad al disponer de respaldos independientes de cada archivo.

Permitir el acceso a archivos aun cuando falle un servidor de archivos.

Repartir la carga de trabajo entre varios servidores.

Protocolos de Actualización.

El principal problema es asegurar la sincronización de las distintas copias.

Un algoritmo posible es el de réplica de la copia primaria:

Uno de los servidores se denomina como primario.

Los demás servidores son secundarios.

La actualización se envía al servidor primario:

o Realiza los cambios localmente.

o Envía comandos a los servidores secundarios para ordenarles la misma modificación.

Las lecturas se pueden hacer de cualquier copia.

La desventaja es que si falla el primario no se pueden llevar a cabo las actualizaciones.(ver

imagen 26)

Pagina 87


2.4.3 TENDENCIAS EN LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS

Es probable que los cambios en el hardware tengan un efecto muy importante en los futuros

sistemas distribuidos de archivos.

También es probable el impacto del cambio en las expectativas del usuario.

Consideraciones Respecto del Hardware

El abaratamiento de la memoria principal permitirá disponer de servidores con memorias cada

vez mayores:

Se podría alojar directamente en memoria el sistema de archivos logrando mayor sencillez y

desempeño.

Se debería prever la obtención de respaldos continuos o por incrementos ante la posibilidad

del corte en el suministro eléctrico.

El respaldo podría hacerse en discos ópticos regrabables que tengan una asociación uno a uno

con la memoria:

o El byte “k” de la memoria correspondería al byte “k” del disco.

La disponibilidad de redes de fibra óptica de alta velocidad permitiría esquemas tales como:

Un servidor de archivos en la memoria principal del servidor con respaldo en el disco óptico.

Eliminación del disco del servidor y del caché del cliente.

Se simplificaría significativamente el software.

Pagina 88


La posible construcción de interfaces de red especializadas que permitan resolver por hardware

problemas difíciles de soportar por software:

Cada interfaz de red tendría un mapa de bits con un bit por cada archivo en el caché.

Se podrían habilitar cerraduras por archivo.

Para modificar un archivo un procesador activaría el bit correspondiente en la interfaz.

Escalabilidad.

Una tendencia definida en los sistemas distribuidos es hacia los sistemas cada vez más grandes.

Los sistemas distribuidos de archivos que operan bien para cientos de máquinas podrían fallar en

algún aspecto trabajando con miles o decenas de miles de máquinas.

Generalmente los algoritmos centralizados no se escalan bien ya que el servidor centralizado

podría convertirse en un cuello de botella; por ello se podría separar el sistema en unidades más

pequeñas relativamente independientes entre sí.

Las transmisiones también son un área problemática:

Si cada máquina transmite una vez por segundo:

o Con “n” máquinas habría “n” transmisiones y “n 2” interrupciones por segundo.

o Si “n” crece esto se puede convertir en un problema.

Pagina 89


2.5 MEMORIA DISTRIBUIDA

Es un tipo de implementación hardware y software, en la que cada nodo de un cluster tiene

acceso a una amplia memoria compartida que se añade a la memoria limitada privada, no

compartida, propia de cada nodo.

Los sistemas de software DSM pueden ser implementados bajo un sistema operativo (SO), o

como una biblioteca de programación. Los sistemas de software DSM implementados en el SO

pueden concebirse como extensiones de la arquitectura de memoria virtual subyacente. Estos

sistemas son transparentes al desarrollador, lo que significa que la memoria distribuida

subyacente está completamente oculta para los usuarios. En contraste, los sistemas de software

DSM implementados en una biblioteca no son transparentes y los desarrolladores tienen que

programarlos separadamente. Sin embargo, estos últimos sistemas ofrecen mejores

características de portabilidad en la implementación de sistemas DSM.

Los sistemas de software DSM también tienen capacidad para organizar la región de memoria

compartida de manera flexible. Las aproximaciones basadas en páginas organizan la memoria

compartida en páginas de tamaño fijo. Por su parte, las aproximaciones basadas en objetos

organizan la región como un espacio abstracto en el que se pueden almacenar objetos

compartidos de tamaño variable.(ver imagen 27)

2.5.1 MEMORIA COMPARTIDA

Pagina 90

http://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Cluster_de_computadores

http://es.wikipedia.org/wiki/Nodo_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Hardware


En informática, la memoria compartida es aquel tipo de memoria que puede ser accedida por

múltiples programas, ya sea para comunicarse entre ellos o para evitar copias redundantes. La

memoria compartida es un modo eficaz de pasar datos entre aplicaciones. Dependiendo del

contexto, los programas pueden ejecutarse en un mismo procesador o en procesadores

separados. La memoria usada entre dos hilos de ejecución dentro de un mismo programa se

conoce también como memoria compartida.

Software:

En el software, memoria compartida puede referirse a:

Un método de comunicación entre procesos, por ejemplo: el intercambio de datos entre dos

programas ejecutándose al mismo tiempo. Uno de los procesos creará un área en RAM a la que

el otro pueda acceder, o

Un método para conservar espacio en la memoria, usando mapeos virtuales o bien soporte

explícito del programa en cuestión, dirigiendo los accesos a una sola instancia de datos que

normalmente serían duplicados. Comúnmente destinado para bibliotecas de enlace

dinámico dinámicas y el espacio de usuario (XIP, "execute in place”).

Dado que ambos procesos pueden acceder al área de memoria compartida como memoria de

trabajo regular, esta es una forma de comunicación veloz (al contrario de otros mecanismos de

comunicación entre procesos como tuberías nombradas, socket de dominio UNIX o CORBA.

Pagina 91

http://es.wikipedia.org/wiki/CORBA

http://es.wikipedia.org/wiki/Socket_Unix

http://es.wikipedia.org/wiki/Espacio_de_usuario

http://es.wikipedia.org/wiki/Biblioteca_de_enlace_din%C3%A1mico

http://es.wikipedia.org/wiki/Biblioteca_de_enlace_din%C3%A1mico

http://es.wikipedia.org/wiki/RAM

http://es.wikipedia.org/wiki/Comunicaci%C3%B3n_entre_procesos

http://es.wikipedia.org/wiki/Hilo_de_ejecuci%C3%B3n

http://es.wikipedia.org/wiki/Unidad_central_de_procesamiento

http://es.wikipedia.org/wiki/Programa_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Memoria_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Inform%C3%A1tica


En cambio, este sistema es menos potente, si, por ejemplo, los procesos que se comunican deben

ejecutarse en la misma máquina (en cuanto a otros métodos de comunicación entre procesos,

solo los sockets del Internet Domain (no los sockets de UNIX), pueden usar una red de

computadoras). Esto se debe a que se requiere mayor atención y cuidado si los procesos que

comparten memoria corren en CPUs separadas y la arquitectura subyacente no

soporta coherencia de caché.

Hardware:

Se refiere a la situación dónde cada nodo (computadora) comparte sus tablas de páginas,

su memoria virtual y todo lo que habita en la memoria RAM con otros nodos en la misma red de

interconexión. Un ejemplo de memoria compartida es DSM.

En otras palabras, una computadora convencional tiene una memoria RAM y un CPU (entre

otras partes de hardware), las cuales están comunicadas de manera local. Cuando se habla

de multicomputadoras es necesario entenderlas como un conjunto de máquinas convencionales

trabajando coordinadamente con el objetivo de compartir recursos de software y hardware para

tareas muy específicas, como por ejemplo la investigación. El hecho de que cada CPU sólo

pueda acceder a la RAM local no beneficia mucho y agrega complejidad a los programadores de

Multicomputadoras, con la compartición de memoria se mitiga esta complejidad ya que todas las

CPUs pueden acceder a la misma RAM.

Soporte en otras plataformas:

En Windows se puede usar la función CreateSharedMemory para crear memoria

compartida o CreateFileMapping y MapViewOfFile como alternativa. Algunas bibliotecas

Pagina 92


http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Centro_de_procesamiento_de_datos


http://es.wikipedia.org/wiki/CPU

http://es.wikipedia.org/wiki/Memoria_de_acceso_aleatorio

http://es.wikipedia.org/wiki/Distributed_Shared_Memory

http://es.wikipedia.org/wiki/Memoria_RAM

http://es.wikipedia.org/wiki/Memoria_virtual

http://es.wikipedia.org/wiki/Tabla_de_paginaci%C3%B3n

http://es.wikipedia.org/wiki/Coherencia_de_cach%C3%A9


para C++ proporcionan acceso portable y orientado a objetos de la memoria compartida. Por

ejemplo, Boost incluye Boost.Interprocess y Qt proporciona QSharedMemory .

Además de C/C++ hay otros lenguajes con soporte nativo para memoria compartida. Por

ejemplo PHP provee un API para crear memoria compartida similar a las funciones POSIX.(ver

imagen 28)

2.5.2 MODELOS DE CONSISTENCIA

Un modelo de consistencia es esencialmente un contrato entre procesos y el almacenamiento de

datos. Es decir: si los procesos acuerdan obedecer ciertas reglas, el almacenamiento promete

trabajar correctamente. Normalmente un proceso que realiza una operación de lectura espera que

esa operación devuelva un valor que refleje el resultado de la última operación de escritura sobre

el dato.

En Informática, en un sistema distribuido, tales como una memoria compartida distribuida o

almacenes de datos distribuido, tales como una base de datos, sistema de archivos, caché web o

sistemas de replicación optimista, hay una serie de posibles modelos de consistencia de datos. Se

dice que un sistema soporta un determinado modelo, si las operaciones en memoria siguen

normas específicas. La consistencia de los datos es definida entre el programador y el sistema,

que garantiza que si el programador sigue las reglas, la memoria será consistente y el resultado

de las operaciones de memoria será predecible.

Los lenguajes de alto nivel, tales como C, C++ y Java, respetan parcialmente este modelo

traduciendo operaciones de memoria en operaciones de bajo nivel para preservar la memoria

Pagina 93


semántica. Para mantener el modelo, los compiladores pueden reordenar algunas instrucciones

de memoria, y las llamadas a las bibliotecas como pthread_mutex_lock (), encapsular la

sincronización necesaria.

Los ejemplos incluyen:

Linealizable (también conocido como el estricta o consistencia atómica)

Consistencia secuencial

Consistencia de causalidad

Consistencia liberada

Consistencia eventual

Consistencia delta

Consistencia PRAM (también conocido como consistencia FIFO)

Consistencia débil

Consistencia vector campo

La duplicidad de los bloques compartidos aumenta el rendimiento, pero produce un problema de

consistencia entre las diferentes copias de la página en caso de una escritura. Si con cada

escritura es necesario actualizar todas las copias, el envío de las páginas por la red provoca que

el tiempo de espera aumente demasiado, convirtiendo este método en impracticable.(ver imagen

29)

2.5.3 MEMORIA COMPARTIDA DISTRIBUIDA CON BASES DE

PÁGINAS

Pagina 94


El esquema de DSM propone un espacio de direcciones de memoria virtual que integra la

memoria de todas las computadoras del sistema, y su uso se realiza mediante paginación. Las

páginas quedan restringidas a estar necesariamente en un único nodo. Cuando un programa

intenta acceder a una posición virtual de memoria, se comprueba si esa página se encuentra de

forma local. Si no se encuentra, se provoca un fallo de página, y el sistema operativo solicita la

página al resto de nodos. El sistema funciona de forma análoga al sistema de memoria virtual

tradicional, pero en este caso los fallos de página se propagan al resto de ordenadores, hasta que

la petición llega al nodo que tiene la página virtual solicitada en su memoria local. A primera

vista este sistema parece más eficiente que el acceso a la memoria virtual en disco, pero en la

realidad ha mostrado ser un sistema demasiado lento en ciertas aplicaciones, ya que provoca un

tráfico de páginas excesivo.

Una mejora dirigida a mejorar el rendimiento sugiere dividir el espacio de direcciones en una

zona local y privada y una zona de memoria compartida, que se usará únicamente por procesos

que necesiten compartir datos. Esta abstracción se acerca a la idea de programación mediante la

declaración explícita de datos públicos y privados, y minimiza el envío de información, ya que

sólo se enviarán los datos que realmente vayan a compartirse.

Memoria comparativa distribuida en base a páginas.

Los sistemas de memoria compartida distribuida (MCD) representan la creación hibrida de dos

tipos de computación paralelos:

La memoria distribuida en sistemas multiprocesador.

Pagina 95


Los sistemas distribuidos.Ellos proveen la abstracción de memoria compartida en sistemas con

memorias distribuidas físicamente y consecuentemente combinan las mejores características de

ambos enfoques. Debido a esto, el concepto de memoria compartida distribuida es reconocido

como uno de los enfoques más atractivos para la creación de sistemas escalables, de alto

rendimiento de sistemas multiprocesador;Ventajas / Desventajas De La Memoria Distribuida

(ver imagen 30)

Implementacion De Una Memoria Distribuida.

Acceso compartido a la memoria à comunicación Inter-procesos.

Ningún procesador puede acceder directamente a la memoria de otro procesador à NORMA

(NO Remote Memory Access) Systems.

Los procesadores hacen referencia a su propia memoria local. Hay que aumentar software para

que, cuando un procesador haga referencia a una página remota, esta página sea recuperada.

El espacio de direccionamiento común es particionado en pedazos.

Cada pedazo es situado en una estación.

Cuando un procesador hace referencia a una página no local à "trap" (page fault).

2.5.4 MEMORIA COMPARTIDA DISTRIBUIDA CON VARIABLES

COMPARTIDAS

Pagina 96


Un método más estructurado que la DSM con base a páginas consiste en compartir sólo ciertas

variables y estructuras de datos necesarias para más de un proceso. Ahora el problema pasa a ser

la forma de mantener una base de datos distribuida, en potencia duplicada, consistente en las

variables compartidas.

Uno de los aspectos más importantes a tratar de estos sistemas es el de si las variables

compartidas deben o no duplicarse, y de qué manera, parcial o total. Si se duplicasen existiría

más potencial que en un sistema DSM basado en páginas, en términos de actualización, dado

que las escrituras en las variables compartidas individuales se pueden aislar. Dos de los

ejemplos más interesantes de este tipo de sistemas son el Munin y el Midway; el primero se basa

en una implantación software de la consistencia de liberación, y el segundo consiste en

compartir las estructuras de datos individuales, permitiendo que los programas multiprocesador

existentes y los nuevos se ejecuten de manera eficiente en las Multicomputadoras, con ligeros

cambios de código.

2.5.5 MEMORIA COMPARTIDA DISTRIBUIDA CON BASE DE

OBJETOS

En los MCD basados en objetos se busca el acceso a datos por medio de la encapsulación de la

información y repartida a través de la red, estos objetos serán definidos por el Programador y las

CPU´s cambiaran los estados según procedan con los accesos. Nace como respuesta a la

creciente popularización de los lenguajes orientados por objetos. Los datos se organizan y son

transportados en unidades de objetos, no unidades de páginas

Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria.

Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular

Pagina 97


y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las

restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse

mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no

modulares y se consideran incompatibles.(ver imagen 31)

Ventajas:

Es más modular que otras técnicas.

La implementación es más flexible por que los accesos son controlados. Sincronización y

accesos se pueden integrar juntos, más fácilmente

Desventajas:

No corre en viejos programas para multiprocesadores.

Los accesos se deben hacer invocando a los accesos, lo que significa más trabajo que los

métodos de páginas compartidas.

Ejemplos: Linda y Orca

No existe una memoria lineal en bruto.

La localización y administración de los objetos es controlada por el sistema de tiempo de

ejecución.

Los objetos se pueden duplicar o no. En caso de duplicarse, hay que decidir cómo se harán

las actualizaciones.

Evitan el compartimiento falso.

El Sistema Linda

Pagina 98


El acceso a memoria se hace mediante un pequeño conjunto de primitivas que se agregan a

los lenguajes existentes.

Las ventajas son que no hay que aprender un nuevo lenguaje, es sencillo de implantar y es

portable.

Se basa en un espacio de n-adas global a todo el sistema.

¿Qué son los objetos?

Estructura de datos encapsulada definida por el programador. Se componen de datos internos

(estado) y operaciones o métodos.‡ Cumplen con la propiedad de ocultamiento dela

información, por lo que contribuyen con la modularidad.

No existe una memoria lineal en bruto.‡ La localización y administración de los objetos es

controlada por el sistema de tiempo de ejecución.‡ Los objetos se pueden duplicar o no. En caso

de duplicarse, hay que decidir cómo se harán las actualizaciones. ‡ Evitan el compartimiento

falso.

Sus principales desventajas son que no soportan programas multiprocesadores antiguos y el

costo adicional que genera el acceso indirecto a los datos.

Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria.

Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular

y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las

restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse

mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no

modulares y se consideran incompatibles.(ver imagen 32 e imagen 33)

Pagina 99


Unidad 3:

Pagina 100


Modelos De Sistemas

Distribuidos

3.1 AMOEBA

3.1.1 INTRODUCCION A LA AMOEBA

Es un uso general del sistema operativo distribuido. Está diseñado para tomar una colección de

máquinas y hacerlos actuar en conjunto como un único sistema integrado.

Usos de Amoeba:

· Uso de redes y un sistema compartido de archivos.

Pagina 101


Administración de Memoria:

La arquitectura del sistema Amoeba está constituida principalmente de cuatro componentes:

1ero se encuentran las estaciones de trabajo (Workstations), una por usuario.

2do, está el pool de procesadores, un grupo de procesadores que se alocan de manera dinámica

de acuerdo con la necesidad.

3ero, los servidores especializados, servidores tales como: Servidores de archivos, de directorio,

de impresión, etc.

4to son lo gateways, que son utilizados para la conexión de sistemas Amoeba en distintas

ciudades o países en un solo sistema uniforme.(ver imagen 34)

Forma de Comunicación:

Uno a muchos.

Todos los receptores están garantizados para recibir todos los mensajes de grupo en el mismo

orden.

Este mecanismo simplifica problemas de programación paralela.

3.1.2 OBJETOS Y POSIBILIDADES

Pagina 102


Posibilidades.

Los objetos reciben su nombre y proteccion de manera uniforme mediante boletos especiales

llamadas posibilidades. Para crear un objeto, un cliente realiza una RPC con el servidor

apropiado, donde indica lo que desea. El servidor entonces crea el objeto y regresa una

posibilidad al cliente. En las operaciones siguientes, el cliente debe presentar la posibilidad para

identificar el objeto. Una posibilidad no es mas que un numerobinario de gran tamaño.

Cuando el cliente desea llevar a cabo una operación en un objeto, llama a un procedimiento de

resguardo, el cual construye un mensaje con la posibilidad del objeto y despues hacemos un

señalamiento al nucleo. Este extrael el campo.

Proteccion de objetos.

El algoritmo basico para la proteccion de los objetos es el siguiente. Cuando se crea un objeto, el

servidor elige un campo de verificacion al azar y lo guarda en una nueva posibilidad y dentro de

sus propias tablas. Se activan todos los bits de derechos a una nueva posibilidad y esta

posibilidad del propietario es lo que regresa al cliente. Cuando la posibilidad regresa al servidor

en una solicitud para llevar a cabo una operación, verifica el campo de verificacion.

Operación estandar .

Aunque muchas de las operaciones en los objetos dependen del tipo de los mismos existen

algunas operaciones que se aplican a la mayoria; esta se muestran en la figura. Algunas de ellas

necesitan que algunos bits esten activados, pero otros pueden ser llevadas a cabo por cualquier

persona que puede presentar un servidor con una posibilidad valida para uno de sus objetos.(ver

imagen 35)

Pagina 103


3.1.3 ADMINISTRACIÓN DE PROCESOS EN MEMORIA

Un proceso en Amoeba es básicamente un espacio de direcciones y una colección de hilos que

se ejecutan en el. Un proceso con un hilo es muy semejante a un proceso UNIX o en MS-DOS,

en términos de su comportamiento o su función. En esta sección aplicaremos el funcionamiento

de los procesos e hilos y la forma de implantarlos.

Procesos:

Es un Objeto en Amoeba. Al crear un proceso, el proceso padre obtiene una posibilidad para el

proceso hijo, al igual que con cualquier otro objeto recién creado. Mediante esta posibilidad, el

hijo se puede suspender o reiniciar o destruir. (ver imagen 36)

Hilos:

Amoeba soporta un modelo sencillo de hilos. Al iniciar un proceso, este tiene al menos un hilo.

Durante la ejecución, el proceso puede crear más hilos y los existentes pueden terminar su labor.

Asi, el número de hilos es por completo dinámico. Al crearse un nuevo hilo, los parámetros de la

llamada especifican el procedimiento por ejecutar y el tamaño de la pila.

3.1.4 ADMINISTRACION DE MEMORIA EN AMOEBA

Pagina 104


Amoeba tiene un modelo de memoria en extremo sencillo. Un proceso puede tener el número de

segmentos que desee y estoy se pueden localizar en cualquier parte del espacio de direcciones

virtuales del proceso. Los segmentos no se intercambian ni se paginan, por lo que un proceso

debe estar por completo contenido en la memoria para su ejecución. Además, aunque se utiliza

el hardware MMU, cada segmento se almacena de manera adyacente a los demás en la memoria.

Segmentos:

Los procesos disponen de varias llamadas al sistema para el manejo de los segmentos. Entre las

más importantes están las que permiten crear, destruir, leer y escribir segmentos. Al crear un

segmento, el proceso que hizo la llamada recibe a cambio una posibilidad, la cual es utilizada

para la lectura y escritura del segmento, asi como para las demás llamadas relacionadas con el

segmento.

Segmentos asociados:

Los espacios de direcciones virtuales en Amoeba se construyen a partir de los segmentos. Al

iniciar un proceso, este debe tener al menos un segmento. Sin embargo, durante su ejecución, un

proceso puede crear más segmentos y asociados con un espacio de direcciones en cualquier

dirección virtual no utilizada.

Un segmento se puede asociar con el espacio de direcciones de dos o más procesos a la vez.

Esto permite que los procesos operen en la memoria compartida. Sin embargo, por lo general es

mejor crea un proceso con varios hilos cuando se necesite la memoria compartida. La principal

Pagina 105


razón para tener varios procesos es una mejor protección, pero si los dos procesos la comparten,

lo usual es que no desee la protección.

3.1.5 COMUNICACIÓN EN AMOEBA

Amoeba soporta dos formas de comunicación: RPC mediante la transferencia puntual de

mensajes y la comunicación en grupo. En el nivel más bajo, una RPC consta de un mensaje de

solicitud seguido de un mensaje de respuesta. La comunicación en un grupo utiliza la

transmisión en hardware o multitransmision si se dispone de esta; en caso contrario, la simula de

manera transparente mediante mensajes individuales.

Llamada a procedimientos remotos (RPC)

Concepto y objetivos

Idea: Ocultar/abstraer los detalles relativos a la comunicación que son comunes a diversas

aplicaciones

Gestión de los diálogos petición-respuesta

Aplanamiento y formateo de datos (enteros, reales, cadenas, estructuras,...) [marshaling,

serializacion]

• Aplanar: organizar datos complejos en un mensaje

• Desaplanar: extraer datos complejos de un mensaje aplanado

• Gestionar: representación info. (Orden de bytes, tipos complejos, alineado en memoria),

diferencias de hardware y S.O.

Pagina 106


Gestión de la interfaz de comunicación (crear y configurar sockets, conectar, escribir, leer,...)

Aproximación: llamada a procedimientos remotos (RPC: Remote Procedure Call)

Generar automáticamente el codigo usado en esas tareas comunes

Ofrecer el entorno y los componentes de apoyo necesarios para dar soporte a esa infraestructura

Procedimiento llamante y procedimiento llamado se ejecutan en máquinas distintas

Ofrecer la ilusión de que la llamada remota parezca idéntica a una llamada local (transparencia)

Objetivo: Proporcionar un middleware que simplifique el desarrollo de aplicaciones distribuidas

Evitar que programador tenga que interactuar directamente con el interfaz de Sockets

• Abstraer (ocultar) los detalles relativos a la red

Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales

• Se busca ofrecer un entorno de programación lo más similar posible a un entorno no

distribuido

• El sistema RPC oculta los detalles de implementación de esas llamadas remotas

◦ implementa la llamada remota mediante un diálogo petición respuesta mensaje de petición:

identifica procedimiento llamado contiene parámetros de la llamada ¦ mensaje de respuesta:

contiene valor/es devuelto/s

◦ se encarga de enviar/recibir mensajes para comunicar ambas partes

◦ se encarga de gestionar los contenidos de esos mensajes (empaquetado y formateado de datos)

Pagina 107


Funcionamiento general

Proceso llamador (cliente):

• Proceso realiza la llamada a una función.

• Llamada empaqueta id. De función y argumentos en mensaje

• Envía mensaje a otro proceso.

• Queda a la espera del resultado.

• Al recibirlo, lo desempaqueta y retorna el valor

Proceso llamado (servidor):

• Recibe mensaje con id. De función y argumentos.

• Se invoca función en el servidor.

• Resultado de la función se empaqueta en mensaje

• Se transmite mensaje de respuesta al cliente. (ver imagen 37)

3.1.6 LOS SERVIDORES DE AMOEBA

Servidor de archivos: Los archivos son inmutables. Se crean, se leen y se eliminan, pero no

se modifican, para favorecer la réplica automática.

Servidor de directorios: Ofrece los archivos, pero el manejo de éstos se hace a través del

servidor de archivos. Mayor flexibilidad.

Pagina 108


Servidor de réplicas: Replicas retardadas. Cuando se crea algún objeto se hace una copia y

cuando tenga tiempo la actualizará. Funciona mejor con objetos inmutables como los archivos.

Servidor de ejecución.

La mayoría de los servicios de los sistemas operativos tradicionales se implantan en Amoeba

como procesos servidores.

Todos los servidores estándar de Amoeba se definen mediante un conjunto de procedimientos de

resguardo. Los resguardos más recientes se definen en AIL (Lenguaje de Interfaz de Amoeba),

aunque los más antiguos están escritos a mano en C. Los procedimientos de resguardo son

generados por el compilador AIL a partir de las definiciones de resguardo y se colocan entonces

en la biblioteca, de manera que los usuarios los puedan utilizar. De hecho, los resguardos

definen de manera precisa los servicios que proporcionan un servidor, así como sus parámetros.

El servidor de Archivos

Como todos los sistemas operativos, Amoeba tiene un sistema de archivos. Sin embargo, a

diferencia de la mayoría de los demás, la elección del sistema de archivos no está dictada por el

sistema operativo. El sistema de archivos se ejecuta como colección de procesos servidores.

El sistema de archivos estándar consta de tres servidores, el servidor de archivos, que controla

el espacio de almacenamiento de archivos; el servidor de directorio, que se encarga de los

nombres de los archivos y del manejo de los directorios; y el servidor de réplicas, el cual

controla la réplica de archivos. El sistema de archivos se ha separado en estos componentes

independientes para lograr mayor flexibilidad y hacer que cada uno de los servidores tenga una

implantación directa.

Pagina 109

https://www.blogger.com/blogger.g?blogID=3214997793520030566


Un proceso cliente puede crear un archivo mediante la llamada créate.(ver imagen 38)

El servidor de archivos mantiene una tabla de archivos con una entrada por cada uno de éstos,

similar a la tabla de nodos-i de UNIX. Toda la tabla se lee de memoria cuando se arranca el

servidor de archivos y se mantiene ahí mientas el servidor de archivos esté ejecutándose.(ver

imagen 39)

El servidor TCP/IP.

Aunque Amoeba utiliza el protocolo FLIP de manera interna para lograr un alto desempeño,

necesita hablar TCP/IP, por ejemplo para la comunicación con las terminales X, para enviar y

recibir correo de otras máquinas que no sean de tipo Amoeba, así como para ejecutar con otros

sistemas Amoeba por medio de Internet.

Para establecer una conexión, un proceso en Amoeba hace una RPC con el servidor TCP/IP

dando una dirección TCP/IP. El proceso de la llamada se bloquea hasta que se establece o niega

la conexión. En la respuesta, el servidor TCP/IP proporciona una posibilidad para el uso de la

conexión. Las RPC posteriores pueden enviar y recibir paquetes de la máquina remota sin que el

proceso Amoeba tenga conciencia del uso de TPC/IP. Este mecanismo es menos eficiente que

FLIP, pero se utiliza cuando este no está disponible

Servidor de directorios.

El servidor de directorios, como hemos visto, solo controla el mantenimiento de archivos. La

colocación de nombres y otros objetos se controlan mediante el servidor de directorios. Su

principal función consiste en proporcionar una asociación entre los nombres legibles para los

humanos (ASCII) y las posibilidades. Los procesos pueden crear uno o más directorios, cada

Pagina 110

https://www.blogger.com/blogger.g?blogID=3214997793520030566


uno de los cuales puede contener varios renglones. Cada renglón describe un objeto y contiene

tanto el objeto como su posibilidad. Se dispone de operaciones para la creación y eliminación de

directorios, adición y eliminación de reglones y búsqueda de nombres de directorios. A

diferencia de los archivos, los directorios no son inmutables. Se pueden añadir o eliminar

entradas de los directorios existentes.

Los propios directorios son objetos y están protegidos por posibilidades, al igual que los demás

objetos. Las operaciones en directorios, como la búsqueda de nombres y la adición de nuevas

entradas, son protegidas por bits en el campo de derecho, de manera usual. Las posibilidades de

los directorios se pueden almacenar en otros directorios y estructuras más generales.

Aunque el servidor de directorios se puede utilizar simplemente para almacenar parejas (nombre

del archivo, posibilidad), también puede soportar a un modelo mas general. En primer lugar, una

entrada de un directorio puede nombrar cualquier tipo de objeto descrito mediante una

posibilidad, no solo un archivo o un directorio. El servidor de directorios no sabe ni se preocupa

por el tipo de objetos que controlan las posibilidades. Las entradas de un directorio pueden

corresponder varios tipos de objetosy eston pueden estar muy dispersos en todo e mundo. No

existe el requisito de que los objetos de un directorio sean del mismo tipo o que deban ser

controlados por el mismo servidor. Cuando se busca y utiliza una posibilidad, su servidor lo

localiza ante una transmicion. . (Ver imagen 40)

Servidor de Replicas.

Los objetos por el servidor de directorios se pueden duplicar en forma automática mediante el

servidor de réplicas. Este practica lo que se llama replica retardada. Lo que esto significa es que

Pagina 111


cuando se crea un archivo o algún otro objeto, al principio solo se hace una copia. Entonces se le

puede llamar servidor de réplicas, para producirlas idénticas, cuando tenga tiempo. En vez de

recibir llamadas directas, el servidor de réplicas se mantiene en ejecución en un plano

secundario todo el tiempo, examinando partes especificas del sistema de directorio en forma

periódica. Cuando encuentra una entrada de directorio que supuestamente debe obtener n

posibilidades pero que contiene menos, se pone en contacto con los servidores correspondientes

y ordena la creación de iobjetos adicionales. Aunque el servidor de réplicas se puede utilizar

para copiar cualquier tipo de objetos, funciona mejor para el caso de objetos inmutables, como

los archivos. La ventaja es que los objetos inmutables no pueden cambiar durante el proceso de

réplica, por lo que puede trabajar son seguridad en un plano secundario, aunque un tiempo

considerable. Los objetos inmutables podrían cambiar durante el proceso de réplica agregando

mayor complejidad para evitar la inconsistencia.

Además el servidor de réplicas ejecuta los mecánicos de maduración y de recolección de basura

utilizados para el servidor de archivos y otros servidores. De manera periódica, toca cada objeto

que este bajo el control del servidor de directorios, para evitar que su tiempo expire. También

envía los mensajes age a los servidores con el fin de decrementar todos los contadores de los

objetos y recolectar la basura de aquellas cuyo contador tenga el valor cero.

El Servidor de ejecución.

Cuando el usuario escribe un comando (por ejemplo, sort) en la terminal, hay que tomar dos

decisiones:

1¿en qué tipo de arquitectura se debe ejecutar el proceso?

La primera pregunta se refiere asi el proceso se debe ejecutar en una 386, sparc, 680x0, etc

Pagina 112


2¿Qué procesador se debe elegir?

La segunda se relaciona con la elección del CPU específico y depende de la carga y

disponibilidad de memoria de los procesadores candidatos. El servidor de ejecución ayuda a

tomar decisiones.

Cada servidor de ejecución controla una o varias pilas de procesadores. Una pila de

procesadores se representa mediante un directorio llamado pooldir, el cual contiene

subdirectorios por cada una de las arquitecturas de CPU soportadas. Los subdirectorios

contienen las posibilidades para el acceso a los servidores de procesos para cada una de las

maquinas en pila. (ver imagen 41)

Servidor de arranque.

Como otro ejemplo de servidor de Amoeba, consideremos el servidor de arranque. Este se

utiliza para proporcionar cierto grado de tolerancia de fallas en Amoeba, mediante la

verificación de todos los servidores que deberían estar en ejecución y aquellos en la realidad lo

estén, además de que toma medidas correctivas en caso de que no estén trabajando. Un servidor

interesado en la sobrevivencia de las fallas se puede incluir el archivo de configuración del

servidor de arranque. Cada entrada indica la frecuencia y la forma en que el servidor de arranque

debe realizar una encuesta. Mientras el servidor responda de manera correcta, el servidor de

arranque no realiza ninguna acción posterior.

Sin embargo, si el servidor no responde después de ciertos números de intentos, el servidor de

arranque lo declara muerto. O intenta reiniciarlo. Si eso falla, entonces asigna de alguna manera

un nuevo procesador de la pila donde inicia una nueva copia. De esa forma, los servicios críticos

Pagina 113


vuelven a arrancar de manera automática si llegan a fallar. El servidor de arranque se puede

duplicar asi mismo, para protegerse de sus propias fallas.

.

3.2 CHORUS

3.2.1 Introducción a CHORUS

Chorus es un micro kernel embebido de tiempo real típicamente usado en ambientes de

aplicaciones distribuidas dedicadas de bajo costo, que necesitan un mínimo de funcionalidad y

un mínimo uso de memoria, tal como líneas de tarjetas de crédito, teléfonos portables, y

dispositivos de mano. Pero también se encuentra en otras aplicaciones embebidas como

impresoras, autómatas, etc. es un sistema operativo altamente escalable y de implementación

confiable, tanto así que se ha establecido entre los proveedores superiores de

telecomunicaciones.

Chorus OS es un sistema operativo para aplicaciones empotradas o en tiempo real, desarrollado

por la empresa Sun Microsystems. Actualmente está liberado bajo código abierto.

Es sistema operativo altamente escalable y estable, sirve para sistemas distribuidos, en red,

empotrados o en tiempo real y se ha establecido como un sistema operativo muy utilizado en

hardware para comunicaciones, desde móviles hasta switches. Pero también se encuentra en

otras aplicaciones empotradas, tales como impresoras, autómatas, etc.

Es de arquitectura basada en componentes (módulos), lo que le dota de una alta configurabilidad

y escalabilidad.

Pagina 114

http://es.wikipedia.org/wiki/Aut%C3%B3mata_programable

http://es.wikipedia.org/wiki/Impresora

http://es.wikipedia.org/wiki/Red_de_computadoras

http://es.wikipedia.org/wiki/Sistema_distribuido

http://es.wikipedia.org/wiki/C%C3%B3digo_abierto

http://es.wikipedia.org/wiki/Sun_Microsystems

http://es.wikipedia.org/wiki/Tiempo_real

http://es.wikipedia.org/w/index.php?title=Aplicaci%C3%B3n_empotrada&action=edit&redlink=1

http://es.wikipedia.org/wiki/Sistema_operativo


Este sistema operativo pertenece a la quinta generación de los sistemas operativos.

Historia

CHORUS surgió del instituto francés INRA en 1980, como proyecto de investigación en

sistemas distribuidos desde entonces han aparecido 4 versiones numeradas del cero al 3. La idea

de tras de la versión cero era la de modelar aplicaciones distribuidas como colección de actores.

La Version cero fue escrita en Pascal UCSD interpretado y se ejecutó en una conexión de

máquinas 8086 conectadas mediante una red de anillo.

Version 1

Se centró en la investigación de los multiprocesadores. Fue escrita para el multiprocesador

francés CM90, que constaba de ocho cpu 68020 de Motorola en un bus común.

Un cpu ejecutaba UNIX; las otras 7 ejecutaban CHORUS y utilizaban el cpu de UNIX para los

servicios del sistema

Version 2 (1984/1986)

Fue una reescritura fundamental del sistema. se diseñó en C de modo que las llamadas de

sistema fuesen compatibles con UNIX en el nivel de codigo fuente, lo que significa que podía

recompilar los programas existentes en UNIX en CHORUS y ejecutarlos en él.

Version 3 .

Pagina 115


La Version 3 se inicia en 1987. Esta Version marco la transición de un sistema de investigación

aun producto comercial, ya que los diseñadores de CHORUS salieron de INRIA, y formaron una

compañía, CHORUS SYSTEMES, para seguir desarrollando y comercializando CHORUS.

Los Conceptos Principales De Memoria En Chorus Son Los Siguientes:

Región: Es un rango adyacente de direcciones virtuales. Todos lo bytes de una región tienen las

mismas características de protección (Exclusivo para lecturas. Las regiones son una propiedad

de los procesos y todos los hilos de un proceso ven las mismas regiones.

SEGMENTOS

Colección adyacente de BYTES que reciben el nombre y protección de una posibilidad. Los

archivos y las areas de intercambio son los tipos más comunes de segmentos. Los segmentos se

pueden leer o escribir en ellos utilizando las llamadas al sistema que proporcionen la

posibilidad, el desplazamiento, el número de bytes, el buffer y la dirección de transferencia del

segmento. (ver imagen 42)

3.2.2 ADMINISTRACIÓN DE PROCESOS EN CHORUS

Procesos:

Un proceso en chorus es una colección de elementos activos y pasivos que funcionan juntos para

realizar cierto cálculo. Los elementos activos son los hilos. Los elementos pasivos son un

espacio de direcciones (que contiene ciertas regiones) y una colección de puertos (para él envió

y resecciones de mensajes).

Pagina 116


Existen tres tipos de procesos que difieren en la cantidad de privilegios y confianza como se

enumera en la figura. El privilegio se refiere a la capacidad de ejecutar la E/S y otras

instrucciones. La confianza significa que se permite llamar de manera directa al núcleo.

Los procesos del núcleo son los más poderosos. Se ejecutan en modo núcleo y todos comparten

el mismo espacio .se cargan o se descargan durante la ejecución.

Cada proceso del sistema se ejecuta en un propio espacio d dirección. Los procesos del sistema

no son privilegiados (es decir se ejecutan en modo usuario) y por lo tanto no pueden ser

ejecutados de manera directa E/S. Sin embargo el núcleo confía en ellos para realizar llamadas.

Los procesos usuario no son confiables ni privilegiados. No pueden realizar E/s de manera

directa ni llamar al núcleo.

Hilos:

Cada proceso activo en chorus tiene uno o más hilos que ejecutan código. Cada hilo tiene un

propio contexto privado (es decir, su pila, contador de programa y registro), que se guarda

cuando el hilos bloque en espera de cierto evento y se restaura cuando se reasume de nuevo el

hilo.

Los hilos se comunican entre sí enviándose y recibiendo mensaje .No importa el emisor ni el

receptor o si están en máquinas diferentes.

Se distinguen los siguientes casos que no son mutuamente excluyentes.

1. ACTIVO ---El hilo es lógicamente capas de ejecutar.

Pagina 117


2. SUSPENDIDO ---El hilo se ha suspendido de manera intencional.

3. DETENIDO ---El proceso del hilo ha sido suspendido.

4. EN ESPERA ---El hilo está esperando que ocurra cierto evento.

Planificación:

La planificación del CPU se realiza mediante el uso de prioridad con base en los hilos. Cada

proceso tiene prioridad y cada hilo tiene prioridad relativa dentro de su proceso.

Como podemos lograr ver en el siguiente diagrama

Estos hilos no se separan en intervalos de tiempo

Estos hilos se separan en intervalos de tiempo

Mayor prioridad

Señalamientos, exenciones y interrupciones

El software de chorus distingue tres tipos de entradas al núcleo:

Los señalamientos: son llamados intencionales al núcleo o a un subsistema para llamar a

servicios.

Los programas causan señalamientos llamando aun procedimiento de biblioteca para una

llamada al sistema.

Las excepciones: son eventos inesperados que son causados por accidentes, como la excepción

de división entre cero, el desbordamiento de punto flotante, o un fallo de página.

Pagina 118


Las interrupciones: son causados por eventos asíncronos, como las marcas de reloj o la

terminación de una solicitud de E/S, estas no necesariamente están relacionadas con algo

realizado por el hilo activo, por lo que no es posible permitir que el proceso del hilo las maneje.

Llamadas al núcleo para la administración de procesos:

La mejor forma para ver lo que un núcleo o sistema operativo realiza es examinar su interfaz. La

llamadas a sistema que proporciona a sus usuarios. En esta sección revisaremos las llamadas

más importantes al sistema del núcleo del chorus.

Llamada Descripción

Comenzaremos con las llamadas a procesos, enumeradas en la figura ActorCreate crea un

proceso nuevo y regresa la posibilidad de ese proceso a quien Hizo la llamada. El proceso nuevo

hereda la propiedad, el identificador de protección y el puerto de excepción del proceso padre.

La llamada ActorDelete elimina un proceso .el proceso por eliminar se especifica mediante la

posibilidad trasferida como parámetro.

La llamada ActorStop congela un proceso, colocando todo sus hilos en el estado DETENIDO.

Los hilos solo se ejecutan de nuevo cuando una llamada ActorStart.

La llamada ActorPriority permite que un proceso lea la prioridad de otro proceso y

opcionalmente que le dé un valor nuevo.

ActorExcept se utiliza para obtener o modificar el puerto de excepción para quien hizo la

llamada.

Pagina 119


El siguiente grupo de llamadas al núcleo se relaciona con los hilos y se muestra en el siguiente

dibujo.

Llamada Descripción

ThreadCreate y threadDelete crean y eliminan hilos en algún proceso (no necesariamente quien

hizo la llamada). Los parámetros dethreadCreate especifican el nivel de privilegio, el estado

inicial, la prioridad, el punto de entrada y el apuntador a la pila.

ThreadSuspendythreadResume detienen y reinician los hilos en el proceso objetivo.

ThreadPriority regresa la prioridad relativa actual del hilo objetivo y opcionalmente lo configura

como valor dado como parámetro.

Nuestras últimas tres llamadas se utilizan para controlar el contexto privado de un hilo, las

llamadas threadLoad y threadStore cargan y configuran el registro del contexto actual del

software, respectivamente. Este registro apunta al contexto del hilo, incluyendo sus variables

particulares. La llamada threadContext copia de manera opcional contexto anterior del hilo a un

buffer, y opcionalmente configura el nuevo contexto de otro buffer.

Las operaciones de sincronización aparecen en la figura siguiente. Se dispone de llamas para

iniciar, adquirir y liberar mútex y semáforos. Funciona de la manera usual.

3.2.3 ADMINISTRACIÓN DE LA MEMORIA EN CHORUS

Pagina 120


Los conceptos principales detrás de la administración de memoria en Chorus son las regiones

y los segmentos.

Una región es un rango adyacente de direcciones virtuales. Todos los bytes de una región

tienen las mismas características de protección (por ejemplo, exclusivo para lectura). Las

regiones son una propiedad de los procesos y todos los hilos de un proceso ven las mismas

regiones.

Un segmento es una colección adyacente de bytes que reciben el nombre y protección de una

posibilidad. Los archivos y las áreas de intercambio son los tipos más comunes de segmentos.

Los segmentos se pueden leer o escribir en ellos utilizando llamadas al sistema que

proporcionen la posibilidad, el desplazamiento, el número de bytes, el buffer y la dirección de

transferencia del segmento.

Los segmentos asociados son paginados por lo general según la demanda Cuando un proceso

hace referencia por vez primera a un segmento recién asociado, ocurre un fallo de página y la

página del segmento correspondiente a la dirección de referencia se recupera y se reinicia la

instrucción fallida. De esta forma, se puede implantar la memoria virtual ordinaria, y, además,

un proceso puede hacer que uno o más archivos sean visibles en su espacio de direcciones

virtuales, de modo que tenga un acceso directo a ellos en vez de tener que leerlos o escribir en

ellos mediante llamadas al sistema.(ver imagen 43)

El núcleo soporta segmentos especiales de E/S para al acceso a los registros de E/S de la

máquina en máquinas con registros de dispositivos asociados con memoria. Al utilizar estos

Pagina 121


segmentos, los hilos del núcleo pueden realizar E/S leyendo o escribiendo de manera directa en

la memoria.

3.2.4 COMUNICACIÓN EN CHORUS

Chorus proporciona dos tipos de operaciones de comunicación: envío asíncrono y RPC. El

envío asíncrono permite que un hilo sólo envíe un mensaje a un puerto. No existe garantía de

que el mensaje llegue a su destino y no existe una notificación si algo sale mal.

La otra operación de comunicación es la RPC. Cuando un proceso ejecuta una operación de

RPC, se bloquea en forma automática hasta que llega la respuesta o expira el cronómetro de la

RPC, en cuyo momento se elimina el bloqueo del emisor. Se garantiza que el mensaje que

elimina el bloqueo del emisor es la respuesta a la solicitud.

Las RPC utilizan una semántica "a lo más una vez”, el sistema garantiza que una RPC

regresará un código de error en vez de intentar la ejecución de una operación más de una vez.

También es posible enviar un mensaje a un grupo de puertos. Se dispone de varias opciones,

estas opciones determinan la cantidad de mensajes que se envían y a cuáles puertos.(ver imagen

44)

Conclusión.

Chorus es un poderoso sistema operativo enfocado a trabajar en maquinas que requieren de una

respuesta en tiempo real para realizar determinados trabajos distribuidos; las aplicaciones de

Chorus son variadas y de mucha importancia, van desde hacer funcionar maquinaria de línea de

Pagina 122


producción, impresoras, equipos de mano, etc. Chorus es un ejemplo de un sistema operativo

extremadamente optimizado y seguro. Provee características sin comparación con otros sistemas

operativos, convirtiéndolo en la elección segura en el mercado de los sistemas embebidos

distribuidos.

Pagina 123


Unidad 4: Proyectos

De Modelamiento

4.1 METODOLOGÍA PARA LA REALIZACIÓN DE PROYECTOS DE

TECNOLOGÍA BASADOS EN SISTEMAS DISTRIBUIDOS

Pagina 124


Pagina 125


Pagina 126


Pagina 127


Pagina 128


Pagina 129


CONCLUSIONES

En este trabajo se ha hablado de los sistemas distribuidos, de cómo se ha evolucionado desde los

sistemas monolíticos, pasando por los sistemas Cliente-Servidor, luego los sistemas de

publicación y finalmente lo que se ha convertido en las aplicaciones distribuidas. Se ha

planteado por qué este tipo de aplicaciones son complicadas de construir y mucho más

complejas de operar que las aplicaciones cliente servidor o aplicaciones legacy, pero lo que se

pretende resaltar es el hecho de que un sistema distribuido es una cadena de valor en el que

intervienen múltiples factores, así como múltiples elementos que hacen que el sistema tenga

éxito o sea un rotundo fracaso. La responsabilidad de este tipo de sistemas ya no depende

solamente de los analistas, diseñadores y desarrolladores, ahora es necesario llevar más allá la

responsabilidad del sistema ya que un sistema distribuido necesita una postimplementación, un

seguimiento, un mantenimiento, pero no solo de código, sino también operativo, es necesario

obtener métricas de servicio, realizar un monitoreo constante, medir los tiempos de respuesta,

realizar el cálculo de capacidades antes y después de la liberación para que de ser necesario el

sistema sea escalado. La palabra escalabilidad es uno de los principales objetivos de un sistema

distribuido, y se puede decir que si un sistema es fácil de escalar entonces todo el trabajo del que

se ha hablado en este documento ha sido llevado a buen término, y es que debe recordarse por

qué los sistemas Cliente Servidor han dejado de ser la respuesta a las crecientes demandas del

mercado, por ejemplo su disponibilidad. Este factor ha llevado a las corporaciones a replantearse

sus objetivos en términos de tecnología de la información y pensar en construir sistemas

distribuidos que representen servicios de negocio, ya que hoy día no es suficiente contar con

resultados correctos en términos de cálculo, ni es suficiente dar servicio en horarios hábiles, hoy

es requisito dar un servicio 7 días por 24 horas, los 365 días del año, y quizás el reto mayor es el

Pagina 130


de dar el servicio a todos los clientes, a cualquier hora, cualquier día y sin importar el lugar de

residencia del cliente. También se observó que los sistemas distribuidos ayudan a las

corporaciones a actualizar la versión de estas aplicaciones más fácilmente y sin necesidad de

interrumpir el servicio ya que un sistema distribuido con una buena actualización de versiones

puede dar servicio ininterrumpido mientras es actualizado. Como hemos visto esto puede

lograrse al apagar y luego actualizar una parte de los componentes mientras la otra parte

continua trabajando y una vez realizada la actualización en la partición primaria se puede

continuar con la actualización secundaria mientras la nueva versión implementada en la primera

partición da el servicio ya en su nueva versión. La fórmula como se ha descrito consiste en crear

una arquitectura distribuida en múltiples capas que distribuya la funcionalidad y las

responsabilidades del sistema entre diferentes objetos y capas, con esto es posible armar

múltiples sistemas aprovechando la reusabilidad de componentes al distribuir la funcionalidad

en todos los sistemas, contribuyendo de esta manera a la reducción de costos y más importante

aún, a la reducción del tiempo en el que un sistema es modificado y se libera a producción para

adaptarse a las nuevas necesidades del mercado.

En este trabajo se observó que los sistemas distribuidos basados en capas y componentes

además de tener una gran flexibilidad para realizar actualizaciones y crear nuevos sistemas,

proveen la posibilidad de crear conexiones con aliados de negocios, esto es un beneficio tanto

del diseño como de la tecnología en la que se basan los sistemas distribuidos. Con esto es

posible ofrecer un servicio a un socio de negocio, permitiéndole contar con algunos servicios

que le ayuden a ofrecer sus propios servicios a sus clientes, acrecentando de esta manera la

cadena de valor y creando nuevos negocios al realizar transacciones.

Pagina 131


Anexos

Pagina 132


Imagen 1

Imagen 2

Pagina 133


Imagen 3

Imagen 4

Imagen 5

Pagina 134


Imagen 6

Imagen 7

Pagina 135


Imagen 8

Imagen 9

Pagina 136


Imagen 10

Imagen 11

Imagen 12

Pagina 137


Imagen 13

Imagen 14

Pagina 138


Imagen 15

Imagen 16

Imagen 17

Pagina 139


Imagen 18

Imagen 19

Imagen 20

Pagina 140


Imagen 21

Imagen 22

Imagen 23

Pagina 141


Imagen 24

Ver imagen 25

Pagina 142


Imagen 26

Imagen 27

Imagen 28

Pagina 143


Imagen 29

Imagen 30

Imagen 31

Pagina 144


Imagen 32

Imagen 33

Pagina 145


Imagen 34

Imagen 35

Imagen 36

Pagina 146


Imagen 37

Imagen 38

Imagen 39

Pagina 147


Imagen 40

Imagen 41

Imagen 42

Pagina 148


Imagen 43

Imagen 44

Pagina 149


BIBLIOGRAFÍA

http://es.slideshare.net/AleksNet/antecedentes-de-los-sistemas-distribuidos?from_action=save

http://www1.frm.utn.edu.ar/soperativos/Archivos/Sistemas_Distribuidos.pdf

http://sisdistrib.blogcindario.com/2009/10/00001-que-es-un-sistema-distribuido.html

http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida#Sistemas_distribuidos

http://www.sc.ehu.es/acwlaroa/SDI/Apuntes/Cap1.pdf

http://antares.itmorelia.edu.mx/~antolino/sis-dis-1/capitulo_1.html

http://exa.unne.edu.ar/informatica/SO/SO8.htm

http://es.wikipedia.org/wiki/Remote_Procedure_Call

http://www.geocities.ws/nancy_aguas/rmta.html


http://exa.unne.edu.ar/informatica/SO/SO9.htm#Intro



http://sedici.unlp.edu.ar/bitstream/handle/10915/22203/Documento_completo.%20Modelizaci

%C3%B3n.pdf?sequence=1


http://es.wikipedia.org/wiki/Memoria_compartida

https://sites.google.com/site/sistemasoperativospaty/unidad-4/42-modelos-de-consistencia

https://sites.google.com/site/sistemasoperativospaty/unidad-4/43-mcd-en-base-a-paginas

http://iinfequipo2.es.tl/4-.-3-.--Memoria-comparativa-distribuida-en-base-a-p%E1ginas.htm

Pagina 150

http://iinfequipo2.es.tl/4-.-3-.--Memoria-comparativa-distribuida-en-base-a-p%E1ginas.htm

https://sites.google.com/site/sistemasoperativospaty/unidad-4/43-mcd-en-base-a-paginas

https://sites.google.com/site/sistemasoperativospaty/unidad-4/42-modelos-de-consistencia

http://es.wikipedia.org/wiki/Memoria_compartida


http://sedici.unlp.edu.ar/bitstream/handle/10915/22203/Documento_completo.%20Modelizaci%C3%B3n.pdf?sequence=1

http://sedici.unlp.edu.ar/bitstream/handle/10915/22203/Documento_completo.%20Modelizaci%C3%B3n.pdf?sequence=1





http://www.geocities.ws/nancy_aguas/rmta.html

http://es.wikipedia.org/wiki/Remote_Procedure_Call


http://antares.itmorelia.edu.mx/~antolino/sis-dis-1/capitulo_1.html

http://www.sc.ehu.es/acwlaroa/SDI/Apuntes/Cap1.pdf

http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida#Sistemas_distribuidos

http://sisdistrib.blogcindario.com/2009/10/00001-que-es-un-sistema-distribuido.html

http://www1.frm.utn.edu.ar/soperativos/Archivos/Sistemas_Distribuidos.pdf

http://es.slideshare.net/AleksNet/antecedentes-de-los-sistemas-distribuidos?from_action=save


http://ais-sistemasdistribuidos.blogspot.com/p/tema-8.html

https://sites.google.com/site/sistemasoperativospaty/unidad-4/45-mcd-en-base-a-objetos

http://sod-ingenieria-lasallepachuca.blogspot.com/p/amoeba.html

http://tutoriasprogramacioncucei.blogspot.com/2014/02/amoeba-introduccion-es-un-

sistema_37.html

http://sod-ingenieria-lasallepachuca.blogspot.com/p/chorus.html

https://prezi.com/dv51ytpgwi40/copy-of-chorus/

http://primer-tecnologia.globered.com/

http://www.instituto.continental.edu.pe/biblioteca/images/documentos/proyectos/

proyecto_entorno_educativo_web.pdf

http://www.capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware/

IntroduccionSistemasDistribuidos_SE.pdf

Pagina 151

http://www.capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware/IntroduccionSistemasDistribuidos_SE.pdf

http://www.capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware/IntroduccionSistemasDistribuidos_SE.pdf

http://www.instituto.continental.edu.pe/biblioteca/images/documentos/proyectos/proyecto_entorno_educativo_web.pdf

http://www.instituto.continental.edu.pe/biblioteca/images/documentos/proyectos/proyecto_entorno_educativo_web.pdf

http://primer-tecnologia.globered.com/

https://prezi.com/dv51ytpgwi40/copy-of-chorus/

http://sod-ingenieria-lasallepachuca.blogspot.com/p/chorus.html

http://tutoriasprogramacioncucei.blogspot.com/2014/02/amoeba-introduccion-es-un-sistema_37.html

http://tutoriasprogramacioncucei.blogspot.com/2014/02/amoeba-introduccion-es-un-sistema_37.html

http://sod-ingenieria-lasallepachuca.blogspot.com/p/amoeba.html

https://sites.google.com/site/sistemasoperativospaty/unidad-4/45-mcd-en-base-a-objetos

http://ais-sistemasdistribuidos.blogspot.com/p/tema-8.html

monografia de sistemas distribuidos

Documents