Vanguard es un microkernel experimental descontinuado desarrollado en Apple Computer , [1] en el Apple Advanced Technology Group (ATG) orientado a la investigación a principios de la década de 1990. Basado en el V-System , Vanguard introdujo identificadores de objetos estandarizados y un sistema de encadenamiento de mensajes único para mejorar el rendimiento. Vanguard no se utilizó en ninguno de los productos comerciales de Apple. El desarrollo finalizó en 1993 cuando Ross Finlayson, el investigador principal del proyecto, dejó Apple.
Vanguard era en general muy similar al V-System, pero añadía compatibilidad con la programación verdaderamente orientada a objetos del sistema operativo . Esto significaba que las interfaces del núcleo y del servidor se exportaban como objetos, que podían heredarse y ampliarse en código nuevo. Este cambio no tiene ningún efecto visible en el sistema, es principalmente un cambio en el código fuente que facilita la programación.
Por ejemplo, Vanguard tenía una clase de entrada/salida (E/S) que era compatible con varios servidores diferentes, por ejemplo, servidores de red y de archivos , con los que las nuevas aplicaciones podían interactuar importando la interfaz de E/S y llamando a métodos. Esto también hizo que escribir nuevos servidores fuera mucho más fácil, porque tenían un estándar para programar y podían compartir código más fácilmente.
Un concepto clave para casi todos los microkernels es dividir un kernel más grande en un conjunto de servidores que se comunican . En lugar de tener un programa más grande que controle todo el hardware de un sistema informático, las diversas tareas se reparten entre programas más pequeños a los que se les dan derechos para controlar diferentes partes de la máquina. Por ejemplo, a un servidor se le puede dar el control del hardware de red, mientras que otro tiene la tarea de administrar las unidades de disco duro . Otro servidor manejaría el sistema de archivos , llamando a ambos servidores de nivel inferior. Las aplicaciones de usuario solicitan servicios enviando mensajes a estos servidores, utilizando alguna forma de comunicaciones entre procesos (IPC), en contraste con pedirle al kernel que haga este trabajo a través de una llamada al sistema (syscall) o trap .
En el modelo V, el sistema IPC parece estar conceptualmente modelado en llamadas a procedimientos remotos (RPC) desde la perspectiva de la aplicación cliente . El cliente importaba un archivo de definición de interfaz que contenía información sobre las llamadas admitidas por el núcleo u otras aplicaciones y luego usaba esta definición para empaquetar las solicitudes. Cuando se realizaba la llamada, el núcleo tomaba el control de inmediato, examinaba los resultados y pasaba la información al controlador adecuado, potencialmente dentro del núcleo. Luego, los resultados se enviaban de vuelta a través del núcleo al cliente.
El funcionamiento del sistema tal como lo ve la aplicación cliente es muy similar a trabajar con un núcleo monolítico normal . Aunque los resultados que se devuelven pueden provenir de un controlador de terceros, esto es esencialmente invisible para el cliente. Los servidores que manejan estas solicitudes funcionan de manera similar a los clientes, abriendo conexiones con el núcleo para pasar datos. Sin embargo, los servidores generalmente generan nuevos subprocesos según sea necesario para manejar solicitudes de mayor duración. Cuando se manejan y se publican las respuestas, el subproceso puede desasignarse y los servidores pueden pasar a un modo de recepción a la espera de más solicitudes.
Por el contrario, la mayoría de los sistemas de microkernel se basan en un modelo de comunicaciones asincrónicas , en lugar de llamadas a procedimientos sincrónicos . El sistema de microkernel canónico, Mach , modeló los mensajes como E/S, lo que tiene varios efectos secundarios importantes. El principal de ellos es que los programadores de tareas normales en sistemas tipo Unix normalmente bloquearán a un cliente que esté esperando una solicitud de E/S, por lo que de esta manera las acciones de pausar y reiniciar aplicaciones que esperan mensajes ya estaban integradas en el sistema subyacente. La desventaja de este enfoque es que el programador es bastante pesado , y llamarlo era un cuello de botella de rendimiento serio y condujo a amplios esfuerzos de desarrollo para mejorar su rendimiento. Bajo el modelo V-System, la sobrecarga de paso de mensajes se reduce porque no es necesario consultar al programador de procesos, no hay dudas sobre qué se debe ejecutar a continuación, que es el servidor al que se llama. La desventaja del enfoque V es que requiere más trabajo para el servidor si la respuesta puede tardar algún tiempo en procesarse.
Una de las principales novedades del sistema IPC de Vanguard, en contraste con V, fue el concepto de cadenas de mensajes , que permitían enviar un mensaje entre varios servidores que interactuaban en un solo viaje de ida y vuelta. En teoría, el encadenamiento podría mejorar el rendimiento de las operaciones comunes de varios pasos.
Consideremos el caso en el que una aplicación cliente debe leer un archivo. Normalmente, esto requeriría un mensaje al núcleo para encontrar el servidor de archivos, luego tres mensajes más al servidor de archivos: uno para resolver el nombre del archivo en un identificador de objeto, otro para abrir ese identificador y, finalmente, otro para leer el archivo. Con el encadenamiento de Vanguard, el cliente podría construir un mensaje que contuviera todas estas solicitudes. El mensaje se enviaría al núcleo y luego se pasaría al servidor de archivos, que manejaría las tres solicitudes antes de devolver finalmente los datos.
Gran parte de los problemas de rendimiento que normalmente se asocian con los sistemas de microkernel se deben a los cambios de contexto que se producen cuando los mensajes se pasan de una aplicación a otra. En el ejemplo anterior, que se ejecuta en un sistema V, tendría que haber un total de ocho cambios de contexto; dos para cada solicitud, ya que el cliente cambiaba hacia y desde el kernel. En Vanguard, el uso de una cadena reduciría esto a solo tres cambios: uno desde el cliente hacia el kernel, otro desde el kernel hacia el servidor de archivos y, finalmente, desde el servidor hacia el cliente. En algunos casos, la sobrecarga de un cambio de contexto es mayor que el tiempo que lleva ejecutar realmente la solicitud, por lo que el mecanismo de encadenamiento de Vanguard podría dar como resultado mejoras de rendimiento en el mundo real.
V también había introducido un servicio de nombres distribuido simple . El servicio almacenaba nombres de caracteres bien conocidos que representaban varios objetos en un sistema V distribuido, por ejemplo, 2nd floor laser printer. Las aplicaciones podían pedirle al servidor de nombres objetos por nombre y recibirían de vuelta un identificador que les permitiría interactuar con ese objeto. El servicio de nombres no era un servidor separado y se administraba mediante código en el núcleo. Contraste esto con el servidor de nombres completo bajo el sistema operativo Spring , que no solo conocía los objetos dentro del sistema, sino que también era utilizado por otros servidores en el sistema para traducir sus nombres privados, por ejemplo, nombres de archivos y direcciones IP.
En el sistema V, se hacía referencia a los objetos de los servidores mediante una clave privada ad hoc de algún tipo, por ejemplo, un entero de 32 bits . Los clientes pasaban estas claves a los servidores para mantener una conversación sobre una tarea específica. Por ejemplo, una aplicación podía pedir al núcleo el sistema de archivos y recibir una clave de 32 bits que representara un identificador de programa, y luego usar esa clave para enviar un mensaje al sistema de archivos pidiéndole que abriera el archivo , lo que daría como resultado que se devolviera una clave de 64 bits . Las claves en este ejemplo son propiedad de los servidores, no se utilizaba un formato de clave común en todo el sistema.my addresses
Este tipo de resolución de nombres era tan común en V que los autores decidieron convertir estas claves en claves de primera clase en Vanguard. En lugar de utilizar cualquier ID de objeto que utilizaran los servidores, en Vanguard se esperaba que todos los servidores comprendieran y devolvieran una clave globalmente única de 128 bits , en la que los primeros 64 bits contenían un identificador de servidor y los segundos identificaban un objeto en ese servidor. El ID del servidor se mantenía en el núcleo, lo que le permitía enviar el mensaje a través de la red si el servidor al que se hacía referencia estaba en una máquina remota. Para el cliente, esto era invisible. No está claro si los ID se asignaban aleatoriamente para evitar que un software malintencionado pudiera adivinarlos correctamente.