Historia y Objetivo

Amoeba fue desarrollado por Andrew S. Tanenbaum y otros en la Universidad

Libre de Amsterdam. El objetivo del proyecto Amoeba era construir un sistema
de tiempo compartido que hiciera que una red entera de computadores
pareciera a los ojos de un usuario como una única máquina.

Los servicios suministrados por el núcleo incluyen threads, segmentos de

memoria, mecanismos de IPC (RPCs y mensajes) y E/S [160].

El desarrollo parece detenido, dado que la fecha de la última modificación en el

código data de febrero de 2001.

Existen versiones para varias plataformas, incluyendo i386, Sun-3 y SPARC.

El lenguaje de programación Python fue originalmente desarrollado para esta

plataforma.

¿Qué es?

Amoeba es un SO distribuido simple y flexible. En dicho sistema el kernel se

limita a suministrar ciertos servicios básicos y el resto de funcionalidad está
implementado mediante servidores que ejecutan como tareas de usuario. Los
servicios suministrados por el kernel incluyen threads, segmentos de memoria,
mecanismos de IPC (RPCs y mensajes) y E/S. Podemos decir que fue un
sistema innovador y, en muchos sentidos, un adelantado a su tiempo.

Amoeba distribuye no sólo los servicios ``tradicionales'' del sistema operativo,

sino también servicios de más bajo nivel de abstracción tales como el acceso a
los bloques de memoria en disco y los procesadores. En Off exploramos la
distribución del sistema a un nivel de abstracción inferior.

En cuanto a IPC, dos de las contribuciones más interesantes desprendidas del

trabajo efectuado por los arquitectos de Amoeba son la combinación de un
modelo de nombrado basado en capabilities con un sistema de IPC basado en
RPCs que permite distribuir los servicios del sistema con grandes niveles de
transparencia y la sugerencia de que los mecanismos básicos de IPC
empleados en SSOO distribuidos deben facilitar tanto la implementación de
RPCs como la de envío de mensajes. A nuestro juicio, Spring ha dado un paso
atrás al considerar que toda la IPC entre objetos está realizada mediante RPCs.
En todos aquellos casos en que no se espera respuesta del servidor estamos
consumiendo recursos innecesariamente.

Lamentablemente, en la época en que se diseñó Amoeba (que fue un sistema

adelantado a su tiempo, como ya pasó con MULTICS) no se valoraba
demasiado la adaptabilidad como parámetro deseable en la construcción de
SSOO (en parte porque había problemas más acuciantes por resolver). Así,
elementos como la gestión básica de memoria (la implementación de los
``segmentos'') están contenidos por completo en el núcleo del sistema en
Amoeba. No es factible adaptar el funcionamiento de los mismos, lo cual hace
que la flexibilidad del sistema de gestión de memoria no sea muy superior a la
de Spring o Mach.

En realidad el problema de Amoeba no es la falta de adaptabilidad per-se. El

problema principal radica en que Amoeba se centra en ocultar a las
aplicaciones la distribución del sistema suministrando una imagen de sistema
único (por ejemplo, la asignación de procesadores se realiza de modo
centralizado, eliminado cualquier posibilidad de adaptar la política de
asignación de procesos a procesadores). En Off en cambio, aunque el sistema
considera un conjunto de recursos distribuidos, las aplicaciones pueden
controlar la asignación y uso de recursos para evitar la pérdida de eficiencia
que ocasiona el suministro de una transparencia total en cuanto a distribución
de recursos. Por ejemplo, en Off una aplicación puede asegurarse de que
aquellos recursos utilizados intensivamente se encuentran siempre en el nodo
local; En Amoeba esto es difícil puesto que todo el sistema se esfuerza en
ocultar la distribución a las aplicaciones, aunque esto sea con el loable
propósito de hacerles el trabajo más fácil.

Aunque habrá que esperar a tener un SO completo y en producción operando

sobre Off para corroborarlo, esperamos que la distribución de recursos a un
nivel de abstracción inferior y la cesión de la práctica totalidad de políticas de
asignación y revocación de recursos a las aplicaciones, evite esta fuente de
ineficiencia en nuestro sistema.

Finalmente, el modelo de hardware contemplado por Amoeba hace que la

gestión de recursos no se realice de forma simétrica. Amoeba especializa la
operación de los nodos en el sistema de tal modo que unos están dedicados a
servir como pool de procesadores, otros como terminales de usuario y otros
como servidores de bloques de datos para sistemas de ficheros. Tratar de
emplear un nodo para una tarea que no es su tarea primaria es luchar contra la
concepción de Amoeba. Esquemas más radicales de aprovechamiento de
recursos que contemplen todos los recursos presentes en la red por igual se
ven dificultados en cierta medida por el diseño de los servicios del sistema.
Aunque es cierto que esto se debe principalmente a la implementación de los
servidores fuera del núcleo de Amoeba y no a la arquitectura del núcleo en sí.

Administración
La administración de la memoria posee una característica fundamental: Los
segmentos no se paginan ni se intercambian, por tanto un proceso debe estar
contenido en la memoria por completo.

Desempeño: Mayor velocidad en la RPC. Todos los datos están adyacentes en

la memoria virtual y física. No se producen fallos de página.

Sencillez: El no tener paginación el núcleo será más controlable.

Economía: al ser tan barata la memoria se podrá usar memorias de cientos de

Megabytes, con lo que se reduce la necesidad de paginación.

Comunicación

Existen varios modos de comunicación en Amoeba y por cada uno de ellos

existe un servidor que se encarga de gestionarlos.

LLAMADAS A PROCEDIMIENTO REMOTO RPC. Para realizar este tipo de

comunicación el servidor de RPC utiliza tres llamadas principalmente que són
GET_REQUEST, PUT_REPLY y TRANS que permite la comunicación entre clientes
y servidores.

COMUNICACIÓN EN GRUPO.

Las llamadas que proporciona para este tipo de comunicación nos permiten
crear nuevos grupos, unir procesos a grupos existentes, enviar información a
grupos y una serie tareas más para gestionar esta comunicación.

La capa más baja es el protocolo de internet fast local(FLIP) que se utiliza para
la transmisión real de mensajes. FLIP está diseñado para su integración dentro
del hardware por esta razón se le ha especificado un interfaz preciso con la
capa inmediatamente superior(RPC y Comunicación por grupo). Este interfaz
consta de nueve llamadas, siete para el tráfico de salida y dos para el tráfico
de llegada.

Amoeba también posee un servidor de TC/IP que realiza las gestiones

oportunas para comunicarse con máquinas que no son Amoeba y con
máquinas Amoeba a través de internet.

A parte de todos los servidores anteriores amoeba posee un servidor de

arranque al cual utiliza llamadas para comprobar que todos los servidores
necesarios están en ejecución.

Con todo esto se observa que el sistema Operativo Amoeba es un sistema

compartido ideal donde cada usuario del sistema cree que está ejecutando el
sistema en modo exclusivo pero en realidad no sabe donde se están
ejecutando sus procesos y donde está guardando sus archivos. Es por esto que
uno de los bloques más potentes de llamadas al sistema sea el de la
comunicación.