“AMOEBA”
INTRODUCCIÓN
Es un sistema operativo
distribuido que permite que una colección de CPU y equipo de E/S se compartan
en una computadora. Proporciona elementos para la programación en paralelo.
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 implementación.
El sistema evolucionó durante
algunos años, adquiriendo características como la emulación parcial de UNIX, la
comunicación en grupo y un protocolo nuevo de bajo nivel.
Muchos proyectos de investigación
de los sistemas operativos distribuidos han partido de un sistema existente
(por ejemplo, UNIX). El proyecto Amoeba partió de un plan limpio y desarrolló
un sistema nuevo a partir de cero. El objetivo era construir un sistema
operativo distribuido transparente. Para el usuario promedio, el uso de Amoeba
es igual al uso de un sistema tradicional de tiempo compartido,, como UNIX. La
diferencia es que hace uso de varias máquinas dispersas en la red. Otro
objetivo era proporcionar un colchón de prueba para la realización de una
programación distribuida y paralela. Amoeba está escrito en C.
LA ARQUITECTURA DE AMOEBA
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.
Amoeba se basa en un modelo de “PILA DE PROCESADORES”. Una pila de
procesadores consta de varios CPU, cada uno con su propia memoria local y
conexión a la red. No necesita la memoria compartida, ni siquiera se espera que
exista; pero si está presente, se le utiliza para optimizar la transferencia de
mensajes al hacer el copiado de una memoria a otra, en vez de enviar mensajes a
través de la red.
Los CPU en una pila pueden tener
distintas arquitecturas. Amoeba está diseñado de forma que pueda trabajar con
varias arquitecturas y sistemas heterogéneos. Es posible que los hijos de un
proceso se ejecuten en arquitecturas diferentes.
La pila no es “poseída” por
usuario alguno. El sistema operativo les asigna en forma dinámica uno o más
procesadores para ejecutar ese comando. Al terminar, se regresan los recursos a
la pila. Si existe una reducción en el número de procesadores en la pila, se
comparte el tiempo de los procesadores individuales, de modo que los nuevos
procesos sean asignados al CPU con menor carga.
El segundo elemento de la
arquitectura de Amoeba es la terminal. Por medio de este el usuario tiene
acceso al sistema. Una terminal usual de Amoeba es la terminal X, con una pantalla de gran tamaño y un ratón. Otra
alternativa consiste en que también se pueda utilizar como terminal una
computadora personal o una estación de trabajo que ejecute ventanas X.
Los procesadores de pila no tienen que ser computadoras con una
tarjeta. Si no se dispone de éstas, se puede designar un subconjunto de las
computadoras personales existentes como los procesadores de Pila. Tampoco deben
encontrarse en la misma región geográfica.
Otro componente importante son
los “servidores especializados”,
como los servidores de archivos que por razones de hardware o software
necesitan ejecutarse en un procesador aparte. Los servidores proporcionan
servicio. Un “servicio” es una
definición abstracta de lo que el servidor está listo a hacer por los clientes.
Varios servidores pueden realizar un servicio. De este modo, el sistema es
tolerante de fallas.
EL MICRONUCLEO
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 y los servidores especializados. El
micronúcleo tiene 4 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.
Amoeba soporta el concepto de
proceso. También soporta varios hilos de control dentro de un espacio de
direcciones.
1.- Un proceso de direcciones con un hilo es en esencia igual a un
proceso de UNIX. Tiene un espacio de direcciones, un conjunto de registros, un
contador del programa y una pila.
Un proceso con varios hilos posee
también un espacio de direcciones compartido por todos los hilos, cada uno de
éstos tiene, desde el punto de vista lógico sus propios registros, su contador
de programa y su pila.
2.-Los hilos pueden asignar o eliminar la asignación de los bloques
de memoria, llamados segmentos. Estos
segmentos se pueden leer o escribir y ser asociados o desasociados al espacio
de direcciones del proceso al cual pertenece el hilo que realiza la llamada. Un
proceso debe poseer al menos un segmento, pero también puede tener varios. El
sistema no obliga a algún patrón particular de uso de los segmentos.
3.-Se dispone de dos formas de comunicación: puntual y de grupo.
Ambas están muy integradas entre sí, de modo que sean lo más parecidas posible.
La comunicación puntual se basa en el
modelo de un cliente que envía un mensaje a un servidor y que después se bloquea hasta
que el servidor envía una respuesta. Este intercambio solicitud/respuesta es la
base para la construcción de los demás.
La comunicación de grupo Permite el envío de mensajes de una fuente a
varios destinos. Los protocolos en software proporcionan una comunicación en
grupo confiable y tolerante a fallas a los procesos del usuario, en presencia
de mensajes perdidos u otros errores.
4.- Para cada dispositivo de E/S conectado a una máquina, existe un controlador del
dispositivo en el núcleo. Este controlador se encarga de toda la E/S del
dispositivo. Los controladores están ligados con el núcleo y no se pueden
cargar de manera dinámica.
Los controladores de dispositivos
se comunican con el resto del sistema mediante los mensajes usuales de
solicitud y respuesta. En general, el cliente no tiene que saber que se
comunica con un controlador. Desde su punto de vista, sólo se comunica con un
hilo en algún lugar.
Tanto el sistema de mensajes
puntuales como la comunicación en grupo hacen uso de un protocolo especializado
llamado FLIP. Este protocolo es un
protocolo de capas de la red y fue diseñado en especial para cubrir las
necesidades del cómputo distribuido. Trabaja con la unistransmisión como con la
multitransmisión en redes complejas.
SERVIDORES
Todo lo que no se lleva a cabo en
el núcleo lo realizan los procesos servidores. La idea es minimizar el tamaño
del núcleo y mejorar la flexibilidad.
Amoeba se basa en el modelo
cliente-servidor. Los clientes son escritos en general por usuarios, mientras
que los servidores son escritos por programadores del sistema, aunque los
usuarios pueden escribir sus propios servidores si así lo desean.
Los objetos (tipos de datos abstractos) son controladores de
servidores. Cuando un proceso crea un objeto, el servidor que lo controla
regresa al cliente una posibilidad protegida en forma cifrada para el objeto.
Todos los servidores estándar
tienen un procedimiento de resguardo en la biblioteca. Para utilizar un
servidor, por lo general un cliente llama por lo regular al resguardo, el cual
ordena los parámetros, envía el mensaje y se bloquea hasta recibir la
respuesta. Este mecanismo oculta todos los detalles de la implantación del
usuario.
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.
El servidor de directorios controla los directorios y los nombres de
las rutas de acceso y las asocia con las posibilidades. Para leer un archivo, un proceso le pide al
servidor de directorios que regresa la posibilidad correspondiente al archivo
(o algún objeto).
OBJETOS Y POSIBILIDADES
El concepto básico y unificador subyacente en todos los
servidores de Amoeba y los servicios que éstos proporcionan es el objeto. Los objetos son pasivos. No
contienen procesos o métodos o alguna otra entidad activa que “haga” cosas.
Para llevar a cabo 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, sin embargo se pueden
ejecutar otros hilos en el mismo proceso.
Los clientes no son conscientes de las posiciones de los
objetos que utilizan. El protocolo RPC
para comunicarse con los servidores del usuario o los servidores del núcleo, ya
sean locales o remotos, es idéntico en todos los casos.
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. El servidor crea entonces el objeto y regresa una posibilidad al
cliente. Una posibilidad no es más que un número binario de gran tamaño.
Cuando un 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 después hace un
señalamiento al núcleo. Éste extra el campo “Puerto del servidor” de la posibilidad y lo busca en su caché para
localizar una máquina donde reside el servidor. Si el puerto no está en la
caché, lo localiza mediante una transmisión. El puerto es en sí una dirección
lógica mediante la cual se puede alcanzar al servidor. Si un servidor se
desplaza a una nueva máquina, se lleva consigo el puerto del servidor.
El campo “Objeto” Es utilizado por el servidor para identificar el objeto
específico en cuestión.
El campo “Derechos” es un mapa de bits que indica las operaciones permitidas
al propietario de una posibilidad.
El campo “Verificación” se utiliza para dar validez a la posibilidad. Estas
son controladas de forma directa por los procesos del usuario.
PROTECCIÓN DE OBJETOS
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 y una nueva posibilidad y esta posibilidad
del propietario es lo que regresa al cliente. Cuando una posibilidad
regresa al servidor en una solicitud para llevar a cabo una operación, se
verifica el campo “VERIFICACIÓN”.
Para crear una posibilidad
restringida, el cliente debe regresar una posibilidad al servidor, junto con
una plantilla de bits para los nuevos derechos. El servidor toma el campo
original “VERIFICACIÓN” de sus tablas, realiza un “OR EXCLISIVO” con los nuevos
derechos y entonces ejecuta el resultado a través de una función de un solo
sentido.
El servidor crea entonces una
nueva posibilidad , con el mismo valor en e campo “OBJETO”, pero con los nuevos
valores en los bits de derechos en el campo “DERECHOS” y la salida de la
función “f” en el campo “VERIFICACIÓN”. La nueva posibilidad regresa entonces
al punto donde se hizo la llamada.
Un usuario que intente añadir derechos que no le son
permitidos simplemente inválida la posibilidad.
Es a través de esta técnica de cifrado que las posibilidades
quedan protegidas a los curiosos.
OPERACIONES ESTÁNDAR
Aunque muchas de las operaciones en os objetos dependen del
tipo de los mismos, existen algunas operaciones que se aplican a la mayoría.
ADMINISTRACIÓN DE PROCESOS
Un proceso en Amoeba es
básicamente un espacio de direcciones y una colección de hilos que se ejecutan
en él.
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 hilo se pude
suspender, reiniciar o destruir.
Amoeba permite crear un proceso
nuevo en un procesador específico donde la supuesta imagen en memoria comience
justo al principio.
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. Para crear un proceso en
una máquina dada, otro proceso realiza una RPC con el servidor de procesos de
esa máquina, proporcionando la información necesaria.
En el siguiente nivel tenemos un conjunto de procedimientos de
biblioteca que proporcionan una interfaz más conveniente para los programas del
usuario.
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.
Algunas de las llamadas para la
administración de procesos utilizan una estructura de datos llamada “descriptor del proceso” donde se
proporciona la información relativa a un proceso que está por ejecutarse.
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.El número de hilos es dinámico.
Cada hilo tiene su apuntador a la
pila y su copia de los registros de la máquina. Si un hilo desea crear y
utilizar variables globales a todos sus procedimientos pero invisibles para los
demás hilos, se dispone de un procedimiento de biblioteca para tales fines.
Tales variables son glocales.
Se dispone de tres métodos para la sincronización de hilos: señales,
mútex y semáforos.
Las señales son interrupciones asíncronas que se envían de un hilo
a otro en el mismo proceso. Desde el punto de vista conceptual, son similares a
las señales de UNIX. Las señales se pueden enviar, capturar o ignorar.
La segunda forma es la del mútex. Un mútex es como un semáforo
binario. Puede tener uno de dos estados, cerrado o abierto. El intento por
cerrar un mútex abierto cierra éste. El hilo que realiza la llamada continúa.
El intento por cerrar un mútex ya cerrado hace que el hilo que hace la llamada
se bloquee hasta que el otro hilo abra el mútex. Si más de un hilo espera un
mútex, al momento de abrir éste, librea exactamente un hilo.
La tercera forma de comunicación
entre los hilos es mediante el conteo de semáforos.
Son más lentos que los mútex, pero hay ocasiones en que son necesarios.
Funcionan de la manera usual, excepto que en este caso existe una llamada
adicional para permitir que termine el tiempo de una operación DOWN si no tiene
éxito durante cierto intervalo de tiempo.
El núcleo controla todos los hilos.
ADMINISTRACIÓN DE MEMORIA
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.
Segmentos
Los procesos disponen de varias llamadas al sistema para el
manejo de 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, así como para las demás llamadas relacionadas con el segmento.
COMUNICACIÓN
Amoeba soporta dos
formas de comunicación: RPC
mediante la trasferencia puntual de mensajes y la comunicación en grupo.
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 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 especiales. La primitiva que envía la solicitud
bloquea en forma automática al proceso que hizo la llamada hasta recibir de
regreso la respuesta, lo cual obliga la existencia de cierta estructura en los
programas.
Cada servidor estándar define una
interfaz de procedimientos que los clientes pueden llamar.
Para que un hilo cliente realice
una RPC con un hilo servidor, el cliente debe conocer la dirección del
servidor.
Primitivas RPC
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.
Trans: envía un mensaje del cliente al servidor
y espera la respuesta.
Los servidores utilizan las dos
primeras. Los clientes utilizan la tercera para transmitir un mensaje y esperar
a una respuesta. Las tres son verdaderas llamadas al sistema.
Cuando se transmite un mensaje a
través de la red, éste contiene un encabezado y (de manera opcional) un buffer
de datos. El encabezado es una estructura fija de 32 bytes.
Cuando un servidor ejecuta un
get_request, el núcleo calcula el correspondiente puerto de envío y lo almacena
en una tabla de puertos escuchados. Todas las solicitudes “trans” utilizan los puertos de envío, de forma que al arribar un
paquete a una máquina, el núcleo compara el puerto de envío del encabezado con
los puertos de envío de su tabla para ver si coinciden.
La RPC de Amoeba soporta la
semántica “al menos una vez”. En
otras palabras, cuando se lleva a cabo una RPC, el sistema garantiza que una
RPC no se llevará a cabo más de una vez, incluso en el casi de fallas del
servidor y un nuevo arranque rápido.
Comunicación en grupo
Un grupo en Amoeba consta de uno
o más procesos que cooperan para llevar a cabo cierta tarea o proporcionar
algún servicio. Los procesos pueden ser miembros de varios grupos al mismo
tiempo. Los grupos son cerrados, lo que significa que sólo los miembros pueden
realizar transmisiones al grupo. La
forma usual para que un cliente tenga acceso a un servicio proporcionado por un
grupo es que realice una RPC con alguno de sus miembros. Ese miembro utiliza
entonces la comunicación en grupo dentro del mismo, en caso necesario, para
determinar lo que debe realizar cada miembro.
PRIMITIVAS PARA LA COMUNICACIÓN EN GRUPO
El protocolo de transmisión confiable
Amoeba trabaja mejor en las LAN
que soportan la multitransmisión o la transmisión simple. La idea fundamental
que forma la base de la implantación de la comunicación en grupo es la transmisión confiable. Esto quiere decir que si un proceso usuario
transmite un mensaje, el mensaje proporcionado por el usuario se envía de
manera correcta a todos los miembros del grupo, incluso aunque el hardware
pueda perder paquetes.
El hardware de todas las máquinas
es idéntico por lo general y todas ejecutan de igual forma el mismo núcleo. Sin
embargo, cuando la aplicación inicia, una de las máquinas se elige como
secuenciador. Si el secuenciador falla en cierto momento, los demás miembros
eligen uno nuevo.
Se puede utilizar la siguiente
secuencia para lograr una transmisión confiable:
1. ---El
proceso usuario hace un señalamiento al núcleo y le transfiere el mensaje.
2. ---El
núcleo acepta el mensaje y bloquea al proceso usuario.
3. ---El
núcleo envía un mensaje puntual al secuenciador
4. Cuando
el secuenciador recibe el mensaje, le asigna el siguiente número secuencial
disponible, coloca este número en un campo reservado para él en el encabezado y
transmite el mensaje.
5. Cuando
el núcleo emisor ve que el mensaje ha sido transmitido, elimina el bloqueo del
proceso para que continúe su ejecución.
Cuando el proceso de cierta
aplicación ejecuta una primitiva de transmisión, como SendToGroup, ocurre un
señalamiento al núcleo. El núcleo bloquea entonces al proceso que hace la
llamada y construye un mensaje que tiene el encabezado proporcionado por el
usuario y los datos dados por la aplicación. El encabezado contiene el tipo de
mensaje, un identificador único del mensaje, el número de la última transmisión
recibida por el núcleo (que por lo general recibe el nombre de reconocimiento a cuestas) y alguna
información adicional.
Comunicación en grupo Tolerante A Fallas
Cuando un procesador falla, al
principio nadie detecta este evento. Sin embargo, tarde o temprano, alguno de
los núcleos notará que los mensajes enviados a la máquina fallida no son
necesarios, por lo que el núcleo señala al procesador fallido como muerto y al
grupo como inutilizable. Todas las primitivas de comunicación en grupo en esa
máquina fallarán hasta reconstruir el grupo.
Poco después de observar el problema, uno de los procesos
usuario que ha obtenido un retorno de error llama a ResetGroup para iniciar la
recuperación.
En resumen, el esquema de
comunicación en grupo de Amoeba garantiza la transmisión atómica con un
ordenamiento global con respecto del tiempo, aunque fallen k máquinas, donde k
es un valor elegido por el usuario durante la creación del grupo.
LOS SERVIDORES DE AMOEBA
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.
Un proceso cliente puede crear un
archivo mediante la llamada créate.
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.
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.
EN RESUMEN
Amoeba es un nuevo sistema operativo
diseñado para hacer que una colección de computadoras independientes aparezca
ante sus usuarios como un sistema de tiempo compartido. En general, los
usuarios no están conscientes del sitio donde se ejecutan sus procesos, ni del
sitio donde se almacenan sus archivos o las copias de ellos mantenidas por
razones de disponibilidad y desempeño. Sin embargo, los usuarios explícitamente
interesados en la programación paralela pueden explotar la existencia de varios
CPU mediante la subdivisión de un solo trabajo en varias máquinas.
Amoeba se basa en un micronúcleo
que controla los procesos de bajo nivel, la administración de la memoria, la
comunicación y la E/S. El sistema de archivos y el resto del sistema operativo
se pueden ejecutar como procesos usuario. Esta división del trabajo mantiene el
núcleo pequeño y sencillo.
Amoeba tiene un mecanismo para
nombrar y proteger a todos los objetos: las posibilidades. Cada posibilidad
contiene los derechos que indican las operaciones permitidas mediante su uso.
Las posibilidades se protegen por cifrado mediante las funciones de un solo
sentido. Cada una contiene un campo para la suma de verificación, la cual
garantiza la seguridad de la posibilidad.
Se soportan tres mecanismos de
comunicación: RPC y FLIP simple para la comunicación puntual y la comunicación
confiable en grupo para la comunicación entre varías partes. La RPC garantiza
una semántica “Al menos una vez”. La comunicación en grupo se basa en la transmisión confiable
proporcionada por el algoritmo del secuenciador. Ambos mecanismos se soportan
sobre el protocolo FLIP y están fuertemente integrados.
El sistema de archivos de Amoeba
consta de tres servidores: el servidor de archivos para el almacenamiento de
estos, el servidor de directorios para otorgar nombres y el servidor de
réplicas para la réplica de archivos. El servidor de archivos mantiene archivos
inmutables que se almacenan en bloques adyacentes, en el disco y en el caché.
El servidor de directorios es un servidor tolerante a fallas que se asocia a
cadenas en ASCII con las posibilidades. El servidor de réplicas controla la
réplica retrasada.
BIBLIOGRAFIA:
Sistemas Operativos Distribuidos " Andrew S. Tanenbaum"
BIBLIOGRAFIA:
Sistemas Operativos Distribuidos " Andrew S. Tanenbaum"
No hay comentarios:
Publicar un comentario