DCE

DCE

Historia de DCE

OSF fue planteada por un grupo de importantes proveedores de computadoras, entre las que estaban IBM, DEC y Hewlett-Packard, como una respuesta a la firma de un acuerdo por AT&T y Sun Microsystems para seguir desarrollando y comercializando el sistema operativo UNIX.

Objetivos de DCE

El objetivo principal de DCE es el de proporcionar un ambiente coherente, sin costuras que sirva como plataforma para la ejecución de aplicaciones distribuidas. A diferencia de Amoeba, Mach y Chorus, este ambiente se construye sobre los sistemas operativos existentes, en principio sobre UNIX, pero posteriormente fue llevado a VMS,WINDOWS y OS/2. La idea es que el cliente puede considerar una colección de máquinas existentes, añade el software DCE y después ejecuta las aplicaciones distribuidas, todo sin perturbar las aplicaciones existentes.

El sistema distribuido sobre el que se ejecuta DCE puede ser que conste de computadoras de diversos proveedores, cada una de las cuales tiene su sistema operativo local.

Componentes de DCE

El modelo de programación subyacente en todo DCE es el modelo cliente/servidor. Los procesos usuario actúan como clientes para tener acceso a los servicios remotos proporcionados por los procesos servidor. Algunos de estos servicios son parte del propio DCE, pero otros pertenecen a las aplicaciones y son escritos por los programadores de las aplicaciones.
Los principales servicios de DCE son de tiempo, directorio, seguridad y sistema de archivos.

Celdas

Los usuarios, máquinas y otros recursos en un sistema DCE se agrupan para formar celdas. La asignación de nombres, la seguridad, la administración y otros aspectos de DCE se basan en estas celdas.

Para determinar la forma de agrupar las máquinas en celdas, hay que tomar en cuenta cuatro factores:

1. Finalidad.

2. Seguridad.

3. Costo.

4. Administración.

Hilos

El paquete de hilos de DCE se basa en el estándar POSIX P 1003,4a. Es una colección de procedimientos de biblioteca a nivel usuario que permiten a los procesos crear, eliminar, y manejar hilos. Sin embargo, si el sistema anfitrión tiene un paquete de hilos, el proveedor puede configurar a DCE para utilizarlo. Las llamadas básicas permiten crear y eliminar hilos, esperar un hilo, y sincronizar el cálculo entre hilos.

Planificación

La planificación de hilos es similar a la de procesos, excepto que es visible a la aplicación. El algoritmo de planificación determina el tiempo de ejecución de cada hilo, así como el hilo que se ejecuta posteriormente. Al igual que en la planificación de procesos, se pueden construir muchos algoritmos de planificación de hilos. Los hilos en DCE tienen prioridades y éstas son respetadas por el algoritmo de planificación. Se supone que los hilos con prioridad alta son más importantes que los hilos de prioridad baja, y por lo tanto tiene un mejor tratamiento, lo que significa que se ejecutan primero y con una mayor porción del CPU.

Sincronización

DCE proporciona dos formas de sincronizar los hilos
1.- Los mútex
2.- Las variables de condición.
Los mútex se utilizan cuando es esencial evitar que varios hilos tengan acceso al mismo recurso y al mismo tiempo.

Llamadas a hilos

El paquete de hilos de DCE tiene un total de 54 primitivas que son procedimientos de biblioteca. Muchas de ellas no son muy necesarias, pero se proporcionan sólo por conveniencia.

Llamadas a procedimientos remotos

Objetivos de la RPC de DCE

el sistema RPC permite que un cliente tenga acceso a un servicio remoto mediante una sencilla llamada a un procedimiento local. Esta interfaz permite escribir con facilidad los programas clientes es decir, de aplicación, de manera familiar para la mayoría de los programadores.

Estructura a un cliente y un servidor

El sistema RPC de DCE consta de varios componentes, que incluyen lenguajes, bibliotecas, demonios y programas de utilería, entre otros. Juntos permiten escribir los clientes y los servidores.

Conexión de un cliente con un servidor

Antes de que un cliente llame a un servidor, tiene que localizarlo y conectarse a él. Los usuarios ingenuos ignoran el proceso de conexión y dejan que los resguardos se encarguen de esto de manera automática, pero la conexión ocurre a pesar de todo. Los usuarios sofisticados pueden controlarla con todo detalle, para seleccionar un servidor específico en una celda distante particular. El principal problema de la conexión es la forma en que el cliente localiza al servidor correcto.

la localización del servidor se realiza en dos pasos:

1. Localizar la máquina servidor.

2. Localizar el proceso correcto en esa máquina.

Servicio de tiempo

Los datos se envían a través de una red a una computadora central para su procesamiento. Para ciertos tipos de experimentos, es esencial para el análisis que los diversos flujos de datos se sincronicen con exactitud.
Para evitar problemas con el tiempo en DCE, tiene un servicio llamado DTS (Servicio distribuido de tiempo). El objetivo de DTS es mantener sincronizados los relojes de las máquinas separadas. Sincronizarlos una vez no es suficiente, pues los cristales de los diferentes relojes vibran con tasas ligeramente diferentes, de modo que los relojes se apartan de forma gradual.
DTS debe tratar dos aspectos:
1. Mantener los relojes mutuamente consistentes.
2. Mantener los relojes en contacto con la realidad.
Modelo de tiempo DTS
En el modelo DTS el tiempo se registra como intervalos. El registro de tiempos como intervalos introduce un problema que no estaba presente en otros sistemas el cual es  no siempre sirve decir esto si una hora es anterior a otra.
Cuando un programa pide a DTS que compare dos tiempos existen tres respuestas posibles:
1. El primer tiempo es anterior.
2. El segundo tiempo es anterior.
3. DTS no puede decir cuál es anterior.
El software que va a utilizar el DTS debe estar preparado para cualquier posibilidad.
Para mantener una compatibilidad con software anterior, DTS también soporta una interfaz convencional donde el tiempo se representa con un valor
Implantación de DTS
El servicio DTS consta de varias componentes como el empleado del tiempo el cual es un proceso demonio que se ejecuta en las máquinas clientes y mantiene al reloj local sincronizado con los relojes remotos.
El empleado del tiempo resincroniza al hacer contacto con todos los servidores de tiempo en su LAN. Estos son demonios cuyo trabajo es mantener el tiempo consistente y preciso dentro de límites conocidos.
Servicio de directorios
Uno de los objetivos principales de DCE es que todos los recursos son accesibles a cualquier proceso del sistema sin importar la posición relativa del usuario del recurso ni la del proveedor del recurso.
El servicio de directorios de DCE está organizado por celda, cada celda tiene un servicio de directorios de celda (CDS) que guarda los nombres y propiedades de los recursos de la celda. Este servicio está organizado como sistema distribuido de base de datos, con réplicas, para proporcionar un buen desempeño y alta disponibilidad.
Cada recurso tiene un nombre, formado por el nombre de su celda seguido por el que utiliza dentro de ella. Para localizar un recurso, el servicio de directorios necesita una forma para localizar celdas. Se soportan dos de estos mecanismos, el servicio global de directorios (GDS) y el sistema de nombres de dominio (DNS).
El servicio de directorio de celda
El CDS maneja los nombres de una celda. Éstos se ordenan como una jerarquía, aunque como en UNIX, también existen los enlaces simbólicos.
La unidad más primitiva en el sistema de directorios es la entrada de directorios de CDS, que consta de un nombre y un conjunto de atributos. La entrada para un servicio contiene el nombre del servicio, la interfaz soportada y la posición del servidor.
Servicio de seguridad
En todos los sistemas distribuidos la seguridad es importante, el administrador del sistema debe saber quien va a operar el recurso, el termino mas importante es el usuario ya que este necesita comunicarse con seguridad en los servidores y en los de aplicaciones.
La autenticación es un importante proceso para determinar si un principal es quien realmente afirma ser.
La protección en DCE está íntimamente ligada a la estructura de celdas. Cada celda tiene un servicio de seguridad en el que deben confiar los principales. El servicio de seguridad, del que es parte el servidor de autenticación, conserva las claves, las contraseñas y demás información relativa a la seguridad en una base de datos segura llamada registro.
Modelo de seguridad
La criptografia es la ciencia del envió de mensajes secretos y los requisitos e hipótesis de DCE.

Componentes de seguridad
El sistema de seguridad de DCE consta de varios servidores y programas, El servidor de registro controla la base de datos de seguridad, el registro, que contiene los nombres de todos los principales, grupos y organizaciones.
EL servidor de autenticación se utiliza cuando un usuario entra al sistema o cuando se arranca un servidor, verifica la identidad afirmada del principal y emite una especie de boleto.
El servidor de autenticación también es conocido como el servidor emisor de boletos cuando está emitiendo boletos en vez de autenticar usuarios, pero estas dos funciones residen en el mismo servidor.
La facilidad de entrada es un programa que pregunta a los usuarios sus nombres y contraseñas durante la secuencia de entrada. Utiliza los servidores de autenticación y de privilegios para hacer su trabajo, que es permitir la entrada del usuario al sistema y reunir todos los boletos.
Un boleto es una estructura de datos cifrada emitida por el servidor de autenticación, o emisor de boletos para demostrar a un servidor específico que el portador es un cliente con una identidad específica.
Un autenticador es una estructura de datos cifrada que contiene al menos un emisor, suma de verificación y marca de tiempo.
ACL
ACL es una lista de control de acceso, indica quién puede tener acceso al recurso y la forma de este acceso, las ACL son controladas por los controladores de ACL, que son procedimientos de biblioteca incorporados a cada servidor.
Sistema distribuido de archivos
Es un sistema distribuido de archivos a nivel mundial que permite que los procesos dentro de un sistema DCE tengan acceso a todos los archivos que están autorizados a utilizar, aunque los procesos y los archivos estén en celdas distantes.
DFS tiene dos partes principales: la parte local y la parte de área amplia. La parte local es un sistema de archivos con un nodo llamado Episode, que es análogo a un sistema de archivos estándar de UNIX en una computadora independiente.
La parte de área amplia es el pegamento que une todos estos sistemas de archivos individuales para formar un sistema de archivos de área amplia que abarca muchas celdas.

Amoeba

Amoeba

Historia de Amoeba

Amoeba se originó en Vrije Universiteit, Amsterdam, Holanda, en 1981, como proyecto de investigación en cómputo distribuido y paralelo. Fue diseñado en un principio por Andrew S. Tanenbaum y tres de sus estudiantes de doctorado, Frans Kaashoek, Sape J. Mullender y Robbert van Renesse, aunque muchas otras personas contribuyeron en el diseño y la implantación.

Objetivos de investigación

Muchos de los proyectos de investigación en los sistemas operativos distribuidos han partido de un sistema existente y agregando nuevas características como el uso de redes y un sistema compartido de archivos para hacerlo más distribuido. El proyecto Amoeba siguió un método diferente. Partió de un plan limpio y desarrolló un sistema nuevo a partir de cero. La idea era tener un comienzo fresco y experimentar nuevas ideas sin tener que preocuparse por la compatibilidad retroactiva con cualquiera de los sistemas existentes. Para evitar el enorme trabajo de escribir grandes cantidades de software de aplicación, se añadió posteriormente un paquete de emulación de UNIX.

La arquitectura del sistema Amoeba

Antes de describir la forma en que Amoeba está estructurado, es útil delinear en primer lugar el tipo de configuración en hardware para el que fue diseñado Amoeba, puesto que difiere un poco de lo que poseen la mayor parte de las organizaciones actuales. Amoeba se diseñó con dos hipótesis respecto al hardware:

1. Los sistemas tienen un número muy grande de CPU.

2. Cada CPU tendrá decenas de megabytes de memoria.

El micronúcleo de Amoeba

Amoeba consta de dos partes fundamentales: un micronúcleo que se ejecuta en cada procesador, y una colección de servidores que proporcionan la mayor parte de la funcionalidad de un sistema operativo tradicional.

 El micronúcleo de Amoeba se ejecuta en todas las máquinas del sistema. El mismo núcleo se utiliza en los procesadores de la pila, las terminales (suponiendo que sean computadoras en vez de terminales X) y los servidores especializados. El micronúcleo tiene cuatro funciones básicas:

1. Controlar los procesos e hilos.

2. Proporcionar el soporte de la administración de memoria de bajo nivel.

3. Soportar la comunicación.

4. Controlar la E/S de bajo nivel.

Los servidores de Amoeba

Todo lo que no se lleva a cabo dentro del núcleo lo realizan los procesos servidores. La idea detrás de este diseño es minimizar el tamaño del núcleo y mejorar la flexibilidad. Como el sistema de archivos y otros dispositivos estándar no se integran al núcleo, éstos se pueden modificar con facilidad y se pueden ejecutar en forma simultánea varias versiones para las distintas poblaciones de usuarios. Amoeba se basa en el modelo cliente-servidor. Los clientes son escritos en general por los usuarios, mientras que los servidores son escritos por los programadores del sistema,aunque los usuarios pueden escribir sus propios servidores si así lo desean. El concepto de objeto es central en el diseño de todo el software; un objeto es como un tipo de dato abstracto.Cada objeto consta de ciertos datos encapsulados, con ciertas operaciones definidas en ellos. el servidor más importante sea el servidor de archivos. Proporciona las primitivas para la administración de archivos, su creación, lectura, eliminación, etc. A diferencia de la mayoría de los servidores de archivos, los archivos creados son inmutables. Una vez creado, un archivo no se puede modificar, pero puede ser eliminado. Los archivos inmutables facilitan la réplica automática, puesto que evitan muchas de las condiciones de competencia inherentes en la réplica de archivos sujetos a modificaciones durante tal proceso.

Objetos y posibilidades en Amoeba

El concepto básico y unificador subyacente en todos los servidores de Amoeba y los servicios que éstos proporcionan es el objeto. Un objeto es una pieza encapsulada de datos en la que se pueden llevar a cabo ciertas operaciones bien definidas. Es, en esencia, un tipo de dato abstracto. Los objetos son pasivos. No contienen procesos o métodos o alguna otra entidad activa que "haga" cosas; en lugar de esto, cada objeto es controlado por un proceso servidor.

Para llevar acabo una operación en un objeto, un cliente hace una RPC con el servidor, donde se especifica el objeto, la operación por desarrollar y, de manera opcional, los parámetros necesarios. El servidor lleva a cabo el trabajo y regresa la respuesta. Las operaciones se llevan a cabo en forma sincronizada; es decir, después que se inicia una RPC con un servidor para obtener cierto trabajo, el hilo del cliente se bloquea hasta que el servidor responde. Sin embargo, se pueden ejecutar otros hilos en el mismo proceso.

Posibilidades

Los objetos reciben su nombre y protección de manera uniforme mediante boletos especiales llamados posibilidades. Para crear un objeto, un cliente realiza una RPC con el servidor apropiado, donde indica lo que desea una posibilidad al cliente. En las operaciones siguientes, el cliente debe presentar la posibilidad para identificar al objeto. Una posibilidad no es más que un número binario de gran tamaño.

Protección de objetos

El algoritmo básico para la protección de objetos es el siguiente. Cuando se crea un objeto, el servidor elige un campo Verificación al azar y lo guarda en la 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, se verifica el campo verificación.

Administración de procesos en Amoeba

Procesos

Un proceso 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, reiniciar o destruir. 

La administración de procesos es controlada en tres niveles distintos en Amoeba. En el nivel inferior están los servidores de procesos, hilos del núcleo que se ejecutan en cada una de las máquinas.

En el siguiente nivel tenemos un conjunto de procedimientos de biblioteca que proporcionan una interfaz más conveniente para los programas del usuario. Se tienen distintos gustos. Hacen su trabajo al llamar a los procedimientos de interfaz de bajo nivel.

Por último, la forma más sencilla de crear un proceso es utilizar el servidor de ejecución, que hace la mayor parte del trabajo para determinar el lugar donde se ejecuta el nuevo proceso.

Hilos

Amoeba soporta un modelo sencillo de hilos. Al iniciar un proceso, éste tiene al menos un hilo. Durante la ejecución, el proceso puede crear más hilos y los existentes pueden terminar su labor. Así, 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 inicial.

Administración de memoria en Amoeba

Amoeba tiene un modelo de memoria en extremo sencillo. Un proceso puede tener el número de segmentos que desee y éstos 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.

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 grupo utiliza la transmisión en hardware o multitransmisión si se dispone de ésta; en caso contrario, la simula de manera transparente mediante mensajes individuales.

Llamada a un procedimiento remoto (RPC)

La comunicación puntual en Amoeba consta de un cliente que envía un mensaje a un servidor, seguida de una respuesta del servidor al cliente. No es posible que un cliente envíe un mensaje y después haga otra cosa, excepto al pasar por alto la interfaz RPC, lo cual ocurre sólo bajo circunstancias muy especiales.

Cada servidor estándar define una interfaz de procedimientos que los clientes pueden llamar. Estas rutinas de biblioteca son resguardos que empaquetan los parámetros en mensajes y llaman a las primitivas del núcleo para enviar en realidad el mensaje.

Primitivas de RPC

El mecanismo RPC utiliza principalmente tres primitivas del núcleo:

1. get_request, indica la disposición de un servidor para escuchar a un puerto.

2. put_reply, llevada a cabo por un servidor cuando tiene un mensaje que desea enviar.

3. irans, envía un mensaje del cliente al servidor y espera la respuesta.

Los servidores de Amoeba

El servidor de archivos

El sistema de archivos se ejecuta como colección de procesos servidores. Los usuarios que no quieran utilizar los estándares, pueden escribir los suyos propios. 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 directorios, 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.

La interfaz del servidor de archivos

El servidor de archivos soporta seis operaciones:

Chorus

Chorus

Historia de Chorus

Chorus surgió del instituto francés de investigación INRIA en 1980, como proyecto de investigación en sistemas distribuidos. Desde entonces han aparecido cuatro versiones, numeradas del 0 al 3. La idea detrás de la versión 0 era la de modelar aplicaciones distribuidas como colección de actores, en esencia procesos estructurados, cada uno de los cuales alternaban entre la realización de una transacción atómica y la ejecución de un paso de comunicación.

La versión 1, que se utilizó de 1982 a 1984, se centró en la investigación del multiprocesador. Fue escrita para el multiprocesador francés SM90, que constaba de 8 CPU 68020de Motorola en un bus común.

La versión 2 (1984-1986) fue una reescritura fundamental del sistema, en C. Se diseñó de modo que las llamadas al sistema fuesen compatibles con UNIX en el nivel del código fuente. El núcleo de la versión 2 se rediseñó por completo, pasando la mayor funcionalidad posible de éste al código del usuario, y cambiando el núcleo por lo que ahora se conoce como micronúcleo.

La versión 3 se inició en 1987. Esta versión marcó la transición de un sistema de investigación a un producto comercial, ya que los diseñadores de Chorus salieron de INRIA y formaron una compañía, Chorus Systémes, para seguir desarrollando y comercializar Chorus.

Objetivos de Chorus

Los objetivos del proyecto Chorus han evolucionado junto con el sistema. En un principio,

se trataba de una investigación puramente académica, diseñada para explorar nuevas

ideas en el cómputo distribuido con base en el modelo del actor. Al pasar el tiempo, se

volvió más comercial, y se cambió el énfasis. Los objetivos actuales se pueden resumir

como sigue:

1. Emulación de UNIX de alto rendimiento.

2. Uso en sistemas distribuidos.

3. Aplicaciones de tiempo real.

4. Integración de la programación orientada a objetos en Chorus.

Estructura del sistema

Chorus está estructurado en capas En la parte inferior está el micronúcleo (llamado sólo núcleo en la documentación de Chorus). Proporciona la mínima administración de los nombres, procesos, hilos, memoria y comunicación. Se tiene acceso a estos servicios mediante llamadas al micronúcleo. Existen más de 100 llamadas. Los procesos de las capas superiores proporcionan el resto del sistema operativo. Cada máquina de un sistema distribuido basado en Chorus ejecuta una copia idéntica del micronúcleo de Chorus.

Abstracciones del núcleo

El núcleo proporciona y controla seis abstracciones fundamentales que forman la base de Chorus. Estos conceptos son los procesos, los hilos, las regiones, los mensajes, los puertos, los grupos de puerto y los identificadores únicos.

Cada proceso tiene un espacio de direcciones, que por lo general van de 0 a cierta dirección máxima. Todos los hilos de un proceso tienen acceso a este espacio de direcciones. Un rango consecutivo de direcciones es una región.

Estructura del núcleo

En la parte inferior está el supervisor, que controla el hardware y atrapa los señalamientos, las excepciones, las interrupciones y demás detalles del hardware, además de controlar el intercambio de contexto. Está escrito parcialmente en ensamblador y debe volverse a crear si Chorus se lleva a un nuevo hardware. Posteriormente esta el administrador de la memoria virtual, que controla la parte de bajo nivel del sistema de paginación.

El subsistema UNIX

La compatibilidad es tanto a nivel fuente como nivel binario La implantación del subsistema MiX es más modular que UNIX. Consta de cuatro procesos, uno para la administración de procesos, uno para la administración de archivos, uno para la administración de dispositivos y uno para los flujos y la comunicación entre procesos. Estos procesos no comparten variables ni memoria, y se comunican de manera exclusiva mediante las llamadas a procedimientos remotos.

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 y una colección de puertos Un proceso con un hilo es como proceso tradicional en UNIX. Un proceso sin hilos no puede realizar algo útil, y por lo general existe sólo durante un intervalo muy corto, mientras se crea un proceso.

Los procesos del núcleo son los más poderosos. Se ejecutan en modo núcleo y todos comparten el mismo espacio de direcciones entre sí y con el micronúcleo. Se cargan o descargan durante la ejecución, pero fuera de ello, se pueden pensar como extensiones del propio micronúcleo.

Hilos

Cada proceso activo en Chorus tiene uno o más hilos que ejecutan código. Cada hilo tiene su propio contexto privado, que se guarda cuando el hilo se bloquea en espera de cierto evento y se restaura cuando se reasume de nuevo el hilo.

Los hilos se comunican entre sí enviando y recibiendo mensajes. No importa si el emisor y el receptor están en el mismo proceso o si están en máquinas diferentes. Se distinguen los siguientes estados, que no son mutuamente excluyentes:

1. Activo: El hilo es lógicamente capaz de ejecutarse.

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 de los CPU se realiza mediante el uso de prioridades con base en los hilos. Cada proceso tiene prioridad y cada hilo tiene prioridad relativa dentro de su proceso. La prioridad absoluta de un hilo es la suma de la prioridad de su proceso y su prioridad relativa. El núcleo mantiene un registro de la prioridad de cada hilo en estado activo y ejecuta el que tiene la máxima prioridad absoluta.

Administración de memoria de Chorus

Regiones y segmentos

Una región es un rango adyacente de direcciones virtuales una región puede comenzar o terminar en cualquier dirección virtual, pero para hacer algo útil, una región debe estar alineada con respecto de las páginas y tener una longitud igual.a cierto número entero de páginas.

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.

Asociadores

Chorus soporta paginadores externos del estilo de Mách, llamados asociadores. Cada asociador controla uno o más segmentos que son asociados con regiones. Un segmento se asocia con varias regiones, incluso en diferentes espacios de direcciones al mismo tiempo. El administrador de la memoria virtual en cada núcleo mantiene un caché de página y lleva un registro de la página correspondiente a cada segmento. Las páginas en el caché local pertenecen a segmentos con nombre, como archivo, o sin nombre, como las áreas de intercambio.

Memoria compartida distribuida

Chorus soporta la memoria compartida distribuida paginada con el estilo IVY. La unidad para compartir entre las diversas máquinas es el segmento. Los segmentos se dividen en fragmentos de una o más páginas. En cualquier instante, cada fragmento es exclusivo para lectura, y en potencia está presente en varias máquinas; o bien, sirve para lectura y escritura, y sólo está presente en una máquina.

Llamadas al núcleo para la administración de memoria

La administración de memoria en Chorus soporta 26 llamadas al sistema diferentes, más algunas otras llamadas del núcleo a los asociadores.

Comunicación en Chorus

Mensajes

Cada mensaje contiene un encabezado una parte fija opcional y un cuerpo opcional. El encabezado identifica la fuente y destino y contiene varios identificadores de protección y banderas. La parte fija, si está presente, siempre tiene una longitud de 64 bytes y está por completo bajo el control del usuario.

Puertos

Los mensajes se envían a los puertos, cada uno de los cuales contiene un espacio para guardar cierto número de mensajes.

Cool: Un subsistema orientado a objetos

El subsistema UNIX no es más que una colección de procesos de Chorus marcados como un subsistema.

La arquitectura COOL

Desde el punto de vista conceptual, COOL proporciona una capa base COOL que genera las fronteras de la máquina. Esta capa proporciona una forma de espacio de direcciones que es visible a todos los procesos COOL, sin importar el lugar donde se ejecuten, casi en la forma en que un sistema distribuido de archivos proporciona un espacio global de archivos. Sobre esta capa está el sistema genérico de tiempo de ejecución, que también es global al sistema.

Mach

Mach

Los inicios de mach van desde un sistema llamado RIG (Rochester Intelligent Gateway) que inció en la Universidad  de Rochester en 1975. RIG fue escrito para una minicomputadora de 16 bits de Data General llamada Eclipse. Su principal objetivo de investigación era demostrar que se podian estructurar los sistemas operativos de manera modular, como una colección de procesos que se comuniquen entre si mediante la transferencia  de mensajes incluso a través de una red.

En 1984, Accent era utilizado en a PERQ 150 pero perdió terreno debido a UNIX.

Esto hizo que Rashid iniciara un proyecto de sistemas operativos de tercera generación llamado Mach.

La primera versión de Mach apareció  en 1986 para la VAX 11/784 un multiprocesador de 4 CPU. Poco después se realizaron las versiones para la IBM PC/RT y la Sun 3. Para eñ año de 1987, Mach también se ejecutaba en los multiprocesadores Encore y Sequent.

Objetivos de Mach

Mach ha evolucionado de manera considerable a partir de su primera encarnación como RIG. Los objetivos del proyecto también han variado con el tiempo.

Los actuales objetivos de Mach son:

1.- Proporcionar una base para la construcción de otros sistemas operativos.

2.- Soporte de un espacio de direcciones ralo y de gran tamaño.

3.- Permitir el acceso transparente a los recursos de red.

4.- Explotar el paralelismo tanto en el sistema como en las aplicaciones.

5.- Hacer que Mach se pueda transportar a una colección mas grande de maquinas.

El micronúcleo de Mach
Se diseño como base para emular UNIX y otros sistemas operativos. La emulación se lleva a cabo mediante una capa del software que se ejecuta fuera del núcleo, en el espacio del usuario. Cada emulador consta de una parte que esta presente en el espacio de direcciones de los programas de aplicación asi como uno o mas servidores

El núcleo controla cinco abstracciones principales:

1. Procesos.

2. Hilos.

3. Objetos de la memoria.

4. Puertos.

5. Mensajes.

Un concepto exclusivo de Mach es el de objeto de memoria, una estructura de datos que se puede asociar con el espacio de direcciones de un proceso. Los objetos de memoria ocupan una o más páginas y forman la base del sistema de memoria virtual de Mach. Cuando un proceso intenta hacer referencia a un objeto de memoria no presente en la memoria física principal, obtiene un fallo de página. Como en todos los sistemas operativos, el núcleo captura este fallo.

El microucleo de Mach

El micronucleo de Mach se diseño como base para emular UNIX y otros sistemas operativos. La emulacion se lleva a cabo mediante una capa del software que se ejecuta fuera del nucleo, en el espacio de usuario. Cada emulador consta de una parte que esta presente en el espacio 

Administración de procesos en Mach

Procesos

Un proceso en Mach consta principalmente de un espacio de direcciones y una colección de hilos que se ejecutan en ese espacio de direcciones. Los procesos son pasivos. La ejecución se asocia con los hilos. Los procesos se utilizan para recolectar en recipientes convenientes todos los recursos relacionados con un grupo de hilos que cooperan entre sí.

Primitivas de la administración de los procesos

Mach proporciona un pequeño número de primitivas para la administración de los procesos. La mayor parte de éstas se realizan mediante el envío de mensajes al núcleo por medio del puerto del proceso, en vez de hacer llamadas reales al sistema.

Hilos

Las entidades activas en Mach son los hilos. Estos ejecutan instrucciones y controlan sus registros y espacio de direcciones. Cada hilo pertenece con exactitud a un proceso. Este no puede llevar nada a cabo si no tiene uno o más hilos. Los hilos de Mach son controlados por el núcleo; es decir, son lo que a veces se conoce como hilos pesados en vez de ligeros. El núcleo crea y destruye los hilos mediante la actualización de ciertas estructuras de datos de dicho núcleo. Estas estructuras proporcionan los mecanismos básicos para el manejo de múltiples actividades dentro de un espacio de direcciones.

Administración de memoria en Mach

Mach tiene un poderoso sistema para la administración de la memoria, muy elaborado y muy flexible, basado en la paginación, con características que se encuentran poco en otros sistemas operativos. El aspecto de la administración de memoria de Mach que establece la diferencia con los demás es que el código se divide en tres partes. La primera es el módulo pmap, que se ejecuta en el núcleo y se encarga del manejo del MMU y las tablas de páginas de! hardware, además de capturar todos los fallos de página.

Memoria Virtual

Mach proporciona un control fino de la forma de uso de las páginas virtuales El modelo conceptual de memoria que ven los procesos usuario de Mach es un espacio de direcciones virtuales grande y lineal. Para la mayoría de los circuitos de CPU de 32 bits, el espacio de direcciones va de la dirección 0 a la dirección 23l- l puesto que el núcleo utiliza la mitad superior para sus fines particulares. El espacio de direcciones se soporta mediante la paginación. Un concepto fundamental relacionado con el uso del espacio de direcciones virtuales es el objeto de memoria. Un objeto de memoria puede ser una página o un conjunto de ellas, un archivo o alguna otra estructura de datos más particular.

Memoria compartida

El hecho de compartir es muy importante en Mach. No se necesita un mecanismo especial para que un proceso comparta objetos: todos ven el mismo espacio de direcciones de manera automática. Si uno de ellos tiene acceso a una parte de los datos, todos lo harán.

Mach permite que los procesos asignen un atributo de herencia a cada región en su espacio de direcciones. Distintas regiones pueden tener distintos atributos. Se dispone de tres valores:

1. La región no es utilizada en el proceso hijo,

2. La región es compartida entre el proceso prototipo y el hijo.

3. La región en el proceso hijo es una copia del prototipo.

Memoria compartida distribuida en Mach

El concepto de administrador de memoria externo de Mach conduce a una implantación de una memoria compartida distribuida basada en el uso de páginas. Puesto que Mach ya dispone de administradores de memoria para distintas clases de

objetos, es natural introducir un nuevo objeto en la memoria, la página compartida. Las páginas compartidas se controlan mediante uno o más administradores de memoria especiales. Una posibilidad consiste en tener un administrador de memoria que controle a todas las páginas compartidas. Otra es tener un administrador diferente para cada página compartida o para una colección de páginas compartidas, para repartir la carga.

Comunicacion en Mach

El objetivo de la comunicación en Mach es soportar una gama de estilos de comunicación de manera confiable y flexible.

Puertos

La base de toda la comunicación en Mach es una estructura de datos en el núcleo llamada puerto. Un puerto es en esencia Un buzón protegido. Los puertos soportan los flujos de mensajes confiables y secuenciales. Si un hilo envía un mensaje a un puerto, el sistema garantiza su entrega. Los mensajes nunca se pierden debido a errores, desbordamiento u oirás causas.

Primitivas para la administración de puertos

Mach proporciona cerca de 20 llamadas para la administración de puertos. Todas ellas se llaman mediante el envío de un mensaje a un puerto de proceso.

El servidor de mensajes de la red

La comunicación a través de la red se controla mediante servidores a nivel usuario llamados servidores de mensajes de la red, que son algo similar a los administradores externos de memoria ya analizados. Cada máquina en un sistema distribuido Mach ejecuta un servidor de mensajes de la red, los cuales funcionan juntos para administrar los mensajes entre las máquinas, con la intención de simular los mensajes dentro de las máquinas lo mejor que puedan. Un servidor de mensajes de la red es un proceso de varios hilos que lleva a cabo varias funciones. Entre éstas se encuentran la interfaz con los hilos locales, el envío de mensajes a través de la red, la traducción de los tipos de datos de la representación de una máquina a la de otra, la administración de las posibilidades de manera segura, las notificaciones remotas, proporcionar un servicio sencillo de búsqueda de nombres a todo lo ancho de la red y la administración de la autenticación de otros servidores de mensajes de la red. Los servidores de mensajes de la red pueden utilizar una variedad de protocolos, según la reda la que estén conectados.

Emulación de unix en mach

Mach tiene varios servidores que se ejecutan por arriba de él. Tal vez el más importante es un programa que contiene gran parte del UNIX de Berkeley dentro de él. Este servidor es el principal emulador de UNIX(Golub el a i, 1990). Este diseño es un reconocimiento de la historia de Mach como versión modificada del UNIX de Berkeley. La implantación de la emulación de UNiX en Mach consta de dos partes, el servidor de UNIX y una biblioteca de emulación de llamadas al sistema, al arrancar el sistema, el servidor de UNIX indica al núcleo que capture todos los señalamientos de llamadas al sistema y los dirija hacia una dirección dentro de la biblioteca de emulación del proceso UNIX que realiza la llamada al sistema. A partir de ese momento, cualquier llamada al sistema hecha por un proceso UNIX hará que el control pase de manera temporal al núcleo, y de inmediato a su biblioteca de emulación. En el momento en que el control se otorga a la biblioteca de emulación, todos los registros de la máquina recuperan los valores que tenían al momento del señalamiento. Este método de rebotar el núcleo de regreso al espacio del usuario se denomina a veces el mecanismo del trampolín.

Administración de la memoria

Unidad 6.- Administración de la memoria

6.1.- Gestión de memoria

La gestión de memoria representa un vínculo delicado entre el rendimiento (tiempo de acceso) y la cantidad (espacio disponible). Siempre se busca obtener el mayor espacio disponible en la memoria, pero pocas veces existe la predisposición para comprometer el rendimiento. 

La gestión de memoria también debe realizar las siguientes funciones:

permitir que la memoria se comparta (en sistemas de multiprocesos).

asignar bloques de espacio de memoria a distintas tareas;

proteger los espacios de memoria utilizados (por ejemplo, evitar que un usuario modifique una tarea realizada por otro usuario).

optimizar la cantidad de memoria disponible, específicamente a través de sistemas de expansión de memoria.

6.2.- Memoria virtual

Memoria Virtual es el uso combinado de memoria RAM en su computadora y espacio temporero en el disco duro. Cuando la memoria RAM es baja, la memoria virtual mueve datos desde la memoria RAM a un espacio llamado archivo de paginación. El movimiento de datos desde y hacia los archivos de paginación crea espacio en la memoria RAM para completar su tarea.

6.3.- 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.

6.4.- Memoria compartida distribuida

Son sistemas que, mediante software, emulan semántica de memoria compartida sobre hardware que ofrece soporte solo para comunicación mediante paso de mensajes. Este modelo permite utilizar una red de estaciones de trabajo de bajo costo como una maquina paralela con grandes capacidades de procesamiento y amplia escalabilidad, siendo a la vez fácil de programar.

El objetivo principal de estos sistemas es permitir que un multicomputador pueda ejecutar programas escritos para un multiprocesador con memoria compartida.

Cada uno de los nodos en un sistema de MCD aporta una parte de su memoria local para construir un espacio global de direcciones virtuales que será empleado por los procesos paralelos que se ejecuten en el sistema.

6.5.- Paginación

La mayor parte de los sistemas de memoria virtual utilizan una técnica llamada paginación.

La paginación permite que la memoria de un proceso no sea contigua, y que a un proceso se le asigne memoria física donde quiera que ésta esté disponible. 

La paginación evita el gran problema de acomodar trozos de memoria de tamaño variable en el almacenamiento auxiliar.

Cuando es necesario intercambiar fragmento de códigos o datos que residen en la memoria principal, hay que encontrarles espacio en el almacenamiento auxiliar. Por sus ventajas la  paginación es de uso común en muchos SO.

6.6.- Segmentación
La memoria virtual es unidimensional, debido a que las direcciones virtuales van desde 0 hasta cierta dirección máxima, una dirección después de la otra. Para muchos problemas, tener dos o más espacios de direcciones virtuales separados puede ser mucho mejor que tener sólo uno.
Es un esquema para implementar espacios de direcciones virtuales que se usaba en los primeros computadores de tiempo compartido. Una memoria segmentada tiene otras ventajas además de simplificar el manejo de estructuras de datos que aumentan o reducen su tamaño. Si cada procedimiento ocupa un segmento separado, con la dirección 0 como su dirección inicial, la vinculación de procedimientos que se compilan por separado se simplifica de manera considerable.

Sistemas de archivos

Unidad 5.- Sistemas de archivos

5.1.- Archivo
5.1.1.- Concepto
En algunos sistemas operativos un archivo es una secuencia de bytes sin interpretación algún, el significado y estructura de la información en los archivos queda a cargo de los programas de aplicación.
5.1.2.- Tipos
· Archivos regulares: Estos contienen información del usuario.
· Archivos especiales de caracteres: Se relacionan con la entrada/salida y se utilizan para
modelar dispositivos de E/S, en serie como terminales, impresoras, monitores, etc.
· Archivos ASCII: Estos contienen líneas de texto, la ventaja de estos es que se pueden mostrar tal cual se escriben.

5.1.3.- Atributos

Atributo	Significado
Protección	Quien pueda accesar al archivo y como
Contraseña	Contraseña necesaria para entrar al archivo
Creador	ID de la persona que creó el archivo
Propietario	EI del propietario
Bandera de solo lectura	0 para lectura/escritura; 1 para sólo lectura
Bandera oculta	0 para normal; 1 para que no aparezca en los listados
Bandera del sistema	0 para archivos normales; 1 para archivo del sistema
Bandera de archivo	0 si ha sido respaldado; 1 si necesita respaldarse
Bandera ASCII/binario	0 para archivo ASCII; 1 para archivo binario
Bandera de acceso aleatorio	0 para sólo acceso secuencial; 1 para acceso aleatorio
Bandera temporal	0 para normal; 1 para eliminar archivo al salir del proceso
Bandera de bloqueo	0 para desbloqueado; distinto de cero para bloqueado
Longitud de registro	Numero de bytes en un registro
Posición de la llave	Desplazamiento de la llave dentro de cada registro
Longitud de la llave	Numero de bytes en el campo llave
Hora de creación	Fecha y hora en la que fue creado el archivo
Hora de último acceso	Fecha y hora en la que se acceso al  archivo por ultima vez
Hora de última modificación	Fecha y hora en la que se modificó el archivo por última vez
Tamaño actual	Número de bytes en el archivo
Tamaño máximo	Número de bytes hasta donde puede crecer el archivo

5.2.- Los medios de almacenamiento

5.3.- Aspectos de diseño

Por lo general, un sistema distribuido de archivos tiene dos componentes razonablemente distintos: el verdadero servicio de archivos y el servicio de directorios. El primero se encarga de las operaciones en los archivos individuales, como la lectura, escritura y adición, mientras que el segundo se encarga de crear y administrar directorios, añadir y eliminar archivos de los directorios, etc. En esta sección analizaremos la interfaz del verdadero servicio de archivos; en la siguiente analizaremos la interfaz del servicio de directorios.

5.4.- Gestión de entrada/salida y planificación de diseños

Los dispositivos de E/S se pueden dividir básicamente en dos categorías: dispositivos de bloque y dispositivos de carácter. Un dispositivo de bloque almacena información en bloques de tamaño fijo, cada uno con su propia dirección. Los tamaños de bloque comunes varían desde 512 bytes hasta 32,768 bytes. Todas las transferencias se realizan en unidades de uno o más bloques completos (consecutivos). La propiedad esencial de un dispositivo de bloque es que es posible leer o escribir cada bloque de manera independiente de los demás. Los discos duros, CD-ROMs y memorias USBs son dispositivos de bloque comunes.

5.5.- Gestión de archivos

Proporciona a los usuarios y aplicaciones servicios para el uso, acceso y control de accesos, tanto de archivos como a directorios.
Es la administración de los archivos esto se realiza a través del sistema operativo permitiendo que los usuarios tengan acceso así como también, se pueden enviar y compartir archivos con otros usuarios.

5.6.- Protección

Algunos mecanismos de protección para poder implementar políticas de seguridad. Las políticas definen qué hay que hacer (qué datos y recursos deben protegerse de quién; es un problema de administración), y los mecanismos determinan cómo hay que hacerlo.

Objetivos de la protección:

*Inicialmente protección del SO frente a usuarios poco confiables.
*Protección: control para que cada componente activo de un proceso sólo pueda acceder a los recursos especificados, y sólo en forma congruente con la política establecida.
*La mejora de la protección implica también una mejora de la seguridad.