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.