Versin traducida de 2 - Chorus.

doc

Versin traducida de 2 - Chorus.doc

Originalmente publicado en pp 566-79 de Coulouris, Dolllimore y Kindberg, Sistemas Distribuidos, Edicin 2, 1994.

Permiso para copiar para todos los fines no comerciales se concede

George Coulouris, Jean Dollimore y Tim Kindberg 1994

Archivo de material de la Edicin 2 de Sistemas Distribuidos: Conceptos y Diseo

microkernel apoyo a los servicios de sistema abierto, consultado por el paso de mensajes; apoyo a nivel operativo de emulacin del sistema binario (en particular, la emulacin de UNIX) y otros subsistemas; extensibilidad transparente de las instalaciones del ncleo de funcionamiento de la red; virtual de la aplicacin flexible de la memoria; Coro tiene los objetivos de diseo en comn con Mach (vase la seccin 18.1 de edicin 3):

Objetivos de diseo y las caractersticas del diseo principal

Coro ha sido implementado como una base para el tiempo de proceso de sistemas de control real que se ejecutan en incrustado multiprocesadores de memoria distribuida basada en 68020, 80386 y microprocesadores Transputer. 4.3 emulacin de UNIX se est aplicando. Un sistema de Coro se compone de ordenadores monoprocesador o multiprocesador conectado por una red. Coro es arquitectnicamente similar a Mach en muchos aspectos. El ncleo de Coro es un microkernel destinado a apoyar los subsistemas. Un subsistema de Coro es una coleccin de servidores que proporcionan una emulacin binaria de un sistema operativo (UNIX, en particular), o que ofrecen algn servicio importante a otras aplicaciones, tales como la compatibilidad en tiempo de ejecucin para un idioma. Genrico compatibilidad en tiempo de ejecucin para la orientacin lenguas-objeto en la parte

file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (1 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

superior del ncleo de Coro es el tema de la investigacin [Lea et al. 1993]. En el momento de la escritura, el ncleo se ha implementado en el procesador Intel 80386, Motorola 68030 y 88000 microprocesadores, y transputers, entre otros. Una emulacin binaria de System V Release 4 UNIX existe para Intel 88000 de Motorola basado en ordenadores basados en 80386 y, una y BSD Coro naci en 1979 como un proyecto de investigacin sobre sistemas distribuidos en el Institut National de Recherche en Informatique et Automatique (INRIA) de Francia. El objetivo del proyecto era desarrollar un modelo de base de clculo de mensajes para la construccin de un sistema modular del sistema operativo distribuido. Coro pas por tres fases de diseo en el INRIA, y los correspondientes de las versiones del sistema operativo distribuido surgido tres. En la versin 0 de un modelo de comunicacin de los procesos llamados actores se ha desarrollado y una aplicacin prototipo se hizo con un pequeo ncleo. En la versin 1, el diseo anterior fue portado desde un sistema basado en LAN a un multiprocesador de memoria distribuida. Para la versin 2 a un equipo que haba estado trabajando en la implementacin de UNIX se uni al proyecto, y un intento se comenz a emular UNIX utilizando el ncleo Coro y la reutilizacin de una parte del cdigo escrito por el equipo UNIX. Cuando el proyecto dejado en el INRIA, una empresa, Coro Systmes, fue creada para continuar el desarrollo de Coro en redes LAN y multiprocesadores. El ncleo de Coro (versin 3), tambin llamado el ncleo, y una emulacin de UNIX construido en la parte superior de la misma, Chorus / MiX, estn siendo producido y desarrollado por Coro Rozier Systmes et al [. 1988, 1990]. Se describe la versin 3.3 Coro en esta seccin.

Historia y descripcin arquitectnica

Coro
portabilidad (el ncleo Coro est escrito en C + + y est diseado para ser modular y se dividi en dependiente y independiente de la mquina-partes de mquinas); explotacin de los multiprocesadores de memoria compartida. Direccin espacio

Figura 1 Los principales abstracciones Coro (mensajes y cachs locales no se muestran).

el cdigo del servidor y los datos pueden ser cargados dinmicamente en un equipo cuando sea necesario, y se accede a travs de paso de mensajes, pero una decisin por separado se pueden tomar para cada servidor en cuanto a si el programa servidor se agrega al contenido del espacio de direcciones del kernel, o se ejecutan en un dominio de proteccin privada (Figura 2). El precio pagado por esto, sin embargo, es el de los cambios de contexto adicionales que se producen en el acceso a servidores de nivel de usuario, en comparacin con el ncleo servicios prestados. Los diseadores
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (2 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

Coro decidi que, en el caso de algunos servidores, el contexto de los interruptores adicionales incurridos fueron un precio demasiado alto a pagar. Se opt por una arquitectura en la que: Los servidores se cargan dinmicamente en los equipos en los que se necesitan y se accede por la comunicacin basada en mensajes. Los servidores son generalmente corren como el nivel de los procesos de los usuarios para garantizar la proteccin mutua entre el ncleo y los servidores que se ejecuta. El edificio de procesamiento de bloques bsicos de Coro son los actores y las discusiones. Un actor es una tarea similar a Mach y los principales componentes de su entorno de ejecucin son un espacio de direcciones y una coleccin de puertos para recibir los mensajes. Los actores pueden ser cargados dinmicamente en el espacio de direcciones del ncleo, y sus temas se pueden ejecutar en el mbito de la proteccin del ncleo.

Proceso de modelo de gestin

El diseo de la memoria virtual en el coro es muy similar a la de Mach y no vamos a continuar esta labor a pesar de que su aplicacin es interesante [Abrossimov et al. 1989]. Pasamos ahora a las principales caractersticas de diseo que se diferencian de Mach. Regiones, segmentos y cachs locales: actor del espacio de direcciones Una est dividido en regiones, que estn tal como los define en el captulo 6. Una regin puede ser asignada a una parte de un segmento, que es el equivalente de un objeto de memoria Mach. Para cada segmento asignado el ncleo mantiene una cach local, similar a un objeto de cach Mach. Mensajes: Un mensaje de Coro se compone de un cuerpo de longitud variable (limitado a 64 kilobytes), y un tamao fijo (64 bytes) cabecea opcionalmente.

Nota: El grfico muestra el cdigo y los datos de un servidor que se carga dinmicamente en el espacio de direcciones del ncleo, donde se ejecutar. Tambin muestra un cierto nivel servidores-usuario, que se ejecutan dentro de los espacios de direcciones privadas.

Servidores de forma dinmica el espacio de direcciones del ncleo loadedinto

Figura 2 servidores de Coro. grupos de puertos: Los puertos pueden ser miembros de grupos de apoyo. Un grupo de puertos es un destino para los mensajes, y hay varios modos de direccionamiento para el envo de mensajes a un grupo de puertos. grupos de puerto no debe confundirse con los conjuntos de puerto de Mach. Puertos: Un puerto es un canal de comunicacin unidireccional con una cola de mensajes asociada. Los puertos se pueden migrar entre los actores.
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (3 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

Actores: Un actor de Coro es un entorno de ejecucin equivalente a una tarea Mach. Un actor puede tener uno o ms hilos. Las abstracciones principales que ofrece el ncleo Coro (Figura 1) son los siguientes:

Resumen de las principales abstracciones Coro

El funcionamiento en tiempo real: El diseo Coro tiene como objetivo apoyar en tiempo real en los subsistemas del kernel. Con este fin, Coro prev una asignacin flexible de las prioridades de subprocesos y permite personalizar la programacin de las polticas de hilo; subprocesos que se ejecutan dentro del kernel se pueden programar de forma preventiva. Distribuido multiprocesador operacin de memoria: Coro ha sido implementado en varios multiprocesadores de memoria distribuida. Procesadores que se utilizan en los sistemas multiprocesador integrado puede tener soporte de hardware relativamente primitivos para la gestin de la memoria. Esto ha limitado la prestacin de las funciones que asumen la existencia de sofisticados hardware MMU. Apoyo a grupos de servidores y la reconfiguracin del servidor: Coro proporciona apoyo a los grupos de servidores en forma de grupo de modos de direccionamiento para el envo de mensajes, incluyendo multicast. Puerto de la migracin puede ser utilizado para transferir la gestin de un recurso o recaudacin de los recursos de forma dinmica entre los servidores, y es similar a la transferencia de los derechos de puerto de recepcin en Mach. Mejora de UNIX: El diseo Coro anticipa que los usuarios de la emulacin de UNIX que desee utilizar las instalaciones reforzadas previstas por el ncleo subyacente de UNIX en los procesos, tales como hilos mltiples y la capacidad de crear un nuevo proceso en un equipo remoto. Cargables dinmicamente servidores: Coro tiene como objetivo lograr el mismo grado de modularidad y apertura al igual que Mach. Coro apoya cargables dinmicamente servidores que pueden ejecutar ya sea a nivel de usuario o en el espacio de direcciones del ncleo. Coro tambin tiene los siguientes objetivos y caractersticas:

La planta de Coro para permitir cargar los servidores de forma dinmica para ejecutar en el espacio de direcciones del kernel es un intento de mejorar el rendimiento, a costa de perder la proteccin de las fronteras entre el hardware de estos servidores y el ncleo. La instalacin ha sido utilizada en el Coro / subsistema de emulacin de UNIX MiX, como se ver en la siguiente seccin. Las instalaciones de comunicaciones de Coro son menos dependientes que las de Mach a la existencia de sofisticados hardware MMU, y son, por la misma razn, menos flexibles en trminos de estructura del mensaje. El grupo de puertos y la migracin de las instalaciones portuarias permiten servicios a ser aplicado por los grupos de servidores. Sin embargo, el nivel de apoyo a los grupos es limitado a los servicios en que los
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (4 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

recursos se reparten entre los servidores. multidifusin semntica ms fuertes son necesarios cuando los recursos se replican entre los servidores para lograr una alta disponibilidad. Un recurso o grupo de recursos se pueden migrar dinmicamente desde un servidor a otro puerto de la migracin mediante manipulaciones o grupo de puertos. Sin embargo, aunque no mencion este hecho antes, el logro de la migracin de recursos de forma transparente en la prctica implica un considerable trabajo adicional en la transferencia de recursos del Estado entre los dos servidores que participan, y sincronizarlos. El ncleo Coro dispone lo siguiente:-hilo procesos de mltiples llamados actores, la comunicacin con los puertos y los grupos de los puertos como destinos, y el uso sofisticado de la memoria virtual que permite a las regiones deben estar respaldados por megafona externa.

en sistemas distribuidos basados en red y en los multiprocesadores de memoria distribuida. Su arquitectura de programacin est diseada para soportar sistemas de tiempo real. En resumen, el microkernel Coro est dirigido al apoyo de los servicios abiertos, la emulacin de funcionamiento del sistema - en particular de UNIX System V - y otros subsistemas en un sistema distribuido. Funciona Discusin de las principales caractersticas de Coro
El administrador de la red El Gerente de la Red es un actor que se extiende a las facilidades de comunicacin del ncleo de forma transparente a travs de una red, y es en este sentido similar a la red de servidores de Mach. El administrador de la red es responsable tanto de transporte de mensajes y para la ubicacin del puerto. Cuando un hilo presenta un puerto de interfaz de usuario al kernel para enviar un mensaje, esta interfaz de usuario se busca en una lista de puertos conocidos por ser local. Si no se encuentra all, entonces el puerto de interfaz de usuario se enva automticamente por el kernel para el Network Manager, que trata de localizar el puerto de comunicacin con los administradores de red. Una vez que el puerto ha sido localizado, los mensajes enviados al puerto a partir de entonces se entregan directamente a un puerto perteneciente a la Gerente de la Red, lo que les enva de forma transparente. Del mismo modo, el Network Manager se encarga de localizar a miembros de grupos de apoyo que residen en las computadoras a travs de una red de la computadora que enva. Coro utiliza copia en escritura para la transferencia de mensajes grandes cuerpos ipcSend eficientemente cuando se utiliza, si el soporte de MMU se encuentra disponible. A diferencia de Mach, sin embargo, Coro no genera una regin del espacio de direcciones nuevas en el receptor como un subproducto, pero siempre utiliza el intervalo de direcciones especificado por el receptor. Tambin hay una opcin que se puede utilizar con ipcSend que hace que las pginas utilizadas para poner en prctica el cuerpo de un mensaje que se transfiere con el actor direccin del espacio de recepcin de la (se supone que residen en el mismo equipo) - y retirado de la direccin del espacio al remitente. Esto permite que el mensaje que se transmite en su totalidad por manipulaciones de la tabla de pginas. Movimiento en vez de copiar datos entre espacios de direcciones de esta forma es especialmente til cuando, por ejemplo, un mensaje est siendo enviado y el remitente no necesita ms para el cuerpo del mensaje. Mensajes Coro, a diferencia de Mach, utiliza mensajes simples de la mayora en un encabezado de tamao fijo y un cuerpo de tamao variable. Un hilo puede utilizar ipcGetData para extraer el cuerpo de un
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (5 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

mensaje despus de recibir su encabezado y la determinacin de los datos dentro de ella el bfer de recepcin de usar. Temas respuesta a las solicitudes utilizando ipcReply. Normalmente, la respuesta es el ltimo mensaje recibido por el hilo. Sin embargo, si tienen la posibilidad de solicitar la entrada-salida sin el bloqueo, las discusiones pueden aplazar en respuesta a una solicitud hasta que la entrada-salida se ha realizado, y al mismo tiempo responder a otras solicitudes. Esto es til cuando, por ejemplo, llega una peticin de algunos datos que se deben recoger de un disco, pero cuando la siguiente peticin, de un cliente diferente, se puede mantener sin un acceso a disco. En respuesta fuera de servicio se realiza con el concepto del mensaje actual. No es ms un mensaje de corriente por el actor en un momento dado. De forma predeterminada, el mensaje actual es la ltima recibida. Un hilo puede guardar el mensaje actual utilizando ipcSave, a continuacin, recibir y responder a los mensajes ms. Cuando el hilo est listo para responder a la solicitud de guarda, puede restaurarlo a ser el mensaje actual, utilizando ipcRestore citar un identificador de mensaje proporcionado por el ncleo en el momento en que se guard. IpcReply se utiliza para responder a este mensaje . Mediante el establecimiento de una coleccin adecuada de los puertos en el estado habilitado, un hilo puede recibir un mensaje de lo que es el equivalente de un puerto Mach conjunto. Sin embargo, slo puede haber un 'sistema del puerto por el actor - es decir, para todos los hilos en el actor. Para ser miembro de esta serie, un puerto tiene que estar habilitado. Cada puerto est activado o desactivado, y los actores pueden cambiar el estado de sus puertos a voluntad, utilizando portEnable y portDisable. Cuando un puerto se crea, mediante portCreate, el kernel asigna y devuelve una interfaz de usuario para el puerto. PortLi se utiliza para convertir el puerto de interfaz de usuario en un identificador local que puede ser utilizado con ipcReceive. Como hemos explicado anteriormente, el identificador local se utiliza para obtener acceso rpido al puerto estructura interna de datos. Coro es incompatible en no permitir que la IU de los puertos pertenecientes a otros actores para convertirse en LIS, como se debe hacer a los efectos del envo de mensajes eficiente. Sin embargo, los identificadores de estos puertos se pueden enviar en los mensajes, y slo IU va a hacer por ello, desde LI slo son vlidos en el contexto de un solo actor. un miembro de un conjunto de puertos locales. Despus de recibir un mensaje, un hilo, adems, puede llamar a ipcSysInfo para obtener informacin acerca del mensaje, tales como los identificadores de proteccin asociados a ella, antes de decidir si para procesar y responder a ella. Temas recibir las solicitudes utilizando ipcReceive, que se puede dar ya sea un identificador local del puerto, la interfaz de recepcin, o una bandera especial que significa que un mensaje debe ser recibido slo de Al igual que Mach, Coro proporciona primitivas de paso de mensajes asncrono, as como para las interacciones requestreply. IpcSend se utiliza para enviar un mensaje de forma asincrnica. Se puede dar ya sea un puerto de interfaz de usuario como un destino o un identificador de grupo con cualquier modo de direccionamiento. IpcCall enva un mensaje de solicitud y espera una respuesta. Se puede dar cualquier tipo de destino como argumento, excepto un grupo tratado en el modo de multidifusin. La excepcin se debe a que ipcCall no puede apoyar el tratamiento de mltiples copias de una solicitud, o los mensajes de respuesta mltiple que puede sobrevenir.

file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (6 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

puerto de interfaz de usuario traducir del / al identificador local. portLi, portUi Activar / desactivar un puerto. portEnable, portDisable Crear o eliminar un puerto. portCreate, portDelete Devuelven informacin acerca de mensaje actual. ipcSysInfo Recibe el cuerpo del mensaje. ipcGetData Almacenamiento y restauracin de mensaje actual. , IpcRestore ipcSave Responder a un mensaje. ipcReply Recibir un mensaje. ipcReceive Enviar un mensaje de forma asincrnica. ipcSend Enviar una solicitud y recibir una respuesta. ipcCall El sistema de comunicacin llamadas Coro proporciona el sistema principal a raz de convocatorias relacionadas con la comunicacin:

file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (7 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

Modelo de comunicacin y ejecucin

El enfoque de Coro a garantizar que slo los servidores legtimos pueden proporcionar un servicio es hacer que la pertenencia a grupos de puerto seguro. Un actor slo puede agregar un puerto a un grupo si se posee una capacidad para ello. A pesar de la capacidad puede contener un conocido grupo de IU, la parte clave es elegido de forma dinmica a ser difcil de adivinar. Mientras que las capacidades de grupo de puertos se mantienen en secreto, los agentes no pueden pasar por servidores del sistema a travs del mecanismo de grupo de puertos. Por supuesto, este mecanismo proporciona seguridad slo si la asociacin entre los actores y los IP en s est bien aplicada. En un nico equipo, el kernel puede transmitir fcilmente IPs de forma segura. Un protocolo de autenticacin se requiere, sin embargo, para proporcionar una autenticacin segura a travs de una red, en la cara del espionaje es posible, tratar de forzar y jugar de nuevo. Hablamos de protocolos de autenticacin en el Captulo 7. Para habilitar la autenticacin tenga lugar, una proteccin identificador se asocia a cada actor. agente de proteccin de un identificador (IP) es por defecto la del actor que lo cre, pero se puede cambiar por las discusiones supervisor o el actor hilos del sistema. Cuando un actor recibe un mensaje, se puede solicitar el kernel para especificar la IP del actor que lo envi. Un servicio podra utilizar este mecanismo de aplicacin de control de acceso para los recursos que administra. Sin embargo, las capacidades no se puede utilizar como la nica base para un plan de emular a otros UNIX proteccin semntica-grupo de usuarios. Por esta razn, Coro lleva a cabo una forma de autenticacin en nombre de los ejecutores del servicio. Es decir, Coro es capaz de identificar con seguridad el origen de un mensaje a un servidor que lo recibe. Por ejemplo, con el fin de emular UNIX, los agentes que ejecutan los procesos de UNIX pueden estar asociados con el equivalente de los identificadores de usuario de UNIX. Proteccin identificadores puerto Coro y capacidades pueden ser reproducidas libremente en los mensajes entre los procesos, sin intervencin del kernel. identificadores de puerto existe en un nombre de gran espacio suficiente (que son bits IU 64) que adivinar un identificador de puerto que se ha elegido al azar, no es factible en la prctica. Capacidades pueden ser difciles de forjar a travs de la eleccin de sus claves, y as la proteccin de los recursos se pueden aplicar incluso en contra de los actores que conocen el puerto correspondiente referencia. Este mecanismo es equivalente en sus efectos a la transferencia de los derechos de puerto de recepcin en Mach, que difiere slo en el hecho de que el actor en la que reside el puerto inicialmente no est obligado a participar en la migracin. Tenga en cuenta que la migracin de puerto a primera vista parece ser equivalente a poner un actor puerto en un grupo de puertos y la eliminacin de otro actor del puerto. Sin embargo, el mecanismo de grupo, a diferencia de la migracin del puerto, se puede utilizar incluso si el puerto original se convierte en disponible debido a un accidente de su ordenador central. En estas circunstancias, el puerto original se considerar automticamente que han salido del grupo. A favor de la migracin del puerto, sin embargo, tenga en cuenta que la gestin de puertos requiere menos memoria que los gastos generales de administracin de grupos de puerto. Adems, el mecanismo de migracin del puerto ofrece control sobre la continuidad del tratamiento de la peticin, que no se puede garantizar mediante el mecanismo de los grupos. Los mensajes enviados usando el modo de abordar funcionales que fueron entregados previamente al puerto original puede entregarse a cualquier puerto en el grupo despus de este
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (8 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

puerto se quita - y no necesariamente el que pretende ser el puerto de reemplazo. La transferencia de recursos entre los servidores Ya hemos descrito cmo los grupos de puertos se utilizan para implementar servidores reconfigurable. Hay adems un mecanismo de migracin del puerto por el que un puerto puede ser removido de un actor de Coro y se inserta en otro. Esta transferencia de un actor a otro la capacidad de recibir los mensajes enviados al puerto. El uso de este mecanismo, la gestin de un recurso individual - o un grupo de recursos - puede ser transferido de un actor a otro servidor. Despus de una migra puerto, todas las solicitudes enviadas a que se convierta en cola para ser recibidos por el nuevo actor. Esto es as, si los remitentes de esas solicitudes utilizar las capacidades que contienen puerto de interfaz de usuario, o utilizar el identificador de un grupo del que es miembro. Como era de esperar, los puertos siguen siendo miembros de grupos de apoyo cuando migran. Cada equipo administra una base de datos de interfaces de usuario que se busca cuando se intenta enviar un mensaje utilizando selectiva funcional de direccionamiento. Coro incluye en esta base de datos, de forma predeterminada, la IU de la computadora, todos los actores locales y todos los puertos locales. Adems, un actor puede declarar una interfaz de usuario de su eleccin como pertenecientes a su base de datos local con uiDeclare, y se puede quitar ms adelante con el uiForget. Esto permite que los servidores se declaran como asociados a los recursos en particular a los efectos de abordar funcional selectiva.

Figura 6 modo de abordar funcional. modo funcional selectiva El grupo funcional selectiva modo de direccionamiento es til para identificar un servidor particular de un grupo de servidores. Por ejemplo, un servicio que proporciona informacin sobre las cargas de computadora podra ser implementado con un actor en cada equipo, que supervisa la actividad en ese equipo. Cada actor tales lugares un puerto de un grupo comn. Para encontrar la carga en un equipo determinado, una solicitud puede ser enviada a 'cargar' este grupo de control, utilizando selectiva funcional abordar con la interfaz de usuario de la computadora requiere incluido en la direccin. Tenga en cuenta que la entrega de mensajes en grupo de modo funcional puede hacer frente a una aplicacin eficaz como la entrega de mensajes unicast. Una vez que un puerto perteneciente al grupo ha sido localizado, se pueden enviar mensajes utilizando un protocolo unicast a ese puerto hasta que el puerto deja el grupo. En ese momento, el envo de equipos para el grupo recibir una confirmacin negativa se les notifica que tienen que buscar otro puerto en el grupo. modo funcional Para ilustrar el uso funcional de abordar, que ahora consideramos el problema de la sustitucin de un nico servidor que ofrece un servicio determinado - por ejemplo, para sustituir a un servidor con una actualizacin. Una solucin a este problema es que el servicio que debe prestarse a travs de un grupo de puertos de servidor, que normalmente tiene un solo miembro. Todas las solicitudes se envan a este grupo de servidores, usando el modo de abordar funcionales. Este modo de direccionamiento entrega los mensajes de solicitud de un miembro del grupo - y no hay un solo miembro. El servidor de reemplazo puede unirse a este grupo mediante la insercin de su puerto con grpPortInsert; el servidor para ser sustituido puede abandonar el grupo mediante grpPortRemove para eliminar el puerto del grupo (Figura 6). Por razones de transparencia reconfiguracin que deben alcanzarse, el cuidado debe tenerse para sincronizar el procesamiento de mensajes para que las solicitudes de cliente se procesan de forma coherente.
file:///C|/Documents%20and%20Settings/Admi...%20traducida%20de%202%20-%20Chorus.doc.htm (9 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

Tenga en cuenta que el servicio de multidifusin Coro es primitivo, ya que no es confiable y no ofrece garantas con el pedido. Esta es una opcin razonable para un microkernel, teniendo en cuenta que a nivel de los requisitos ms altos son susceptibles de variar, y puede ser implementado en la parte superior del mecanismo de Coro. En el captulo 11 se describi fiable y orden a las instalaciones de multidifusin. Una desventaja importante de este esquema es que todos los procesos en el grupo que recibe el mensaje, aunque no es relevante para ellos. Este arreglo sera poco prctico para el tratamiento de todas las operaciones en los recursos gestionados por el grupo. Es preferible para los clientes de solicitar una capacidad para el recurso al principio, en multidifusin. La capacidad que devuelve el servidor que gestiona el recurso contendr el identificador de un puerto, y todos los posteriores solicitudes de los clientes se pueden enviar directamente al servidor que posee este puerto. La multidifusin inicial es en realidad una bsqueda de nombre: la capacidad se devuelve cuando el cliente presenta un nombre de recurso al grupo. servidor que gestiona los recursos se realice la operacin, los otros servidores se puede ignorar la peticin (Figura 5).

Figura 5 Un mensaje de multidifusin a un grupo. modo de multidifusin Considere el problema de su inters en una operacin en un recurso que es administrado por algn miembro de un grupo de servidores, pero no se sabe cul. La solicitud puede ser de multidifusin en un mensaje que contiene un servicio especfico de identificador del recurso. Esto puede ser un sistema de bajo nivel de identificacin, o, por ejemplo, una ruta de archivo. Una vez recibido el mensaje, slo el A continuacin se dan ejemplos de cmo estos modos de direccionamiento se utiliza para acceder a recursos administrados por los grupos de servidores. modo funcional selectiva: En este modo, el remitente tiene que incluir una interfaz de usuario, as como la capacidad del grupo. El mensaje se entrega a un mximo de un miembro del grupo, uno que exista en el mismo equipo que el recurso con la propuesta de IU. El modo de funcionamiento: El mensaje se entrega a un mximo de un miembro del grupo, pero el miembro elegido no est definido de antemano. el modo de multidifusin: Se intenta entregar el mensaje, poco fiable, a todos los miembros del grupo (esto se conoce tambin como modo de difusin). A los efectos de envo, un puerto de interfaz de usuario de grupo slo se requiere, y no la capacidad. identificadores de grupo ofrecen un nivel de direccionamiento indirecto, por lo que un actor con un identificador de grupo no es necesario saber qu puertos pertenecen al grupo. Cuando se enva un mensaje utilizando un identificador de grupo, el emisor selecciona uno de los modos de direccionamiento siguientes:

file:///C|/Documents%20and%20Settings/Adm...20traducida%20de%202%20-%20Chorus.doc.htm (10 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

Con el fin de manipular la pertenencia a un grupo de puertos, un actor necesita una capacidad para ello. Las capacidades son asignados dinmicamente para grupos de apoyo, a travs de llamadas a grpAllocate. Esta llamada se puede utilizar para obtener una capacidad de un conocido puerto de grupo, bueno, o para asignar una capacidad para un nuevo grupo de marcas. Cualquier actor que conoce la capacidad de grupo puede insertar un puerto en el grupo, utilizando grpPortInsert o eliminar un puerto, utilizando grpPortRemove. Eliminar un puerto de un grupo de puertos. grpPortRemove Inserte un puerto en un grupo de puertos. grpPortInsert Asignar una capacidad para un grupo de puertos. grpAllocate Las llamadas al sistema para crear y manipular grupos de apoyo son los siguientes: La identificacin de los recursos administrados por grupos Para que un servicio puede ser proporcionado por los servidores diferentes en momentos diferentes, o para que un servicio se puede implementar en cualquier momento por varios servidores, los puertos que utilizan procesos para recibir las solicitudes se pueden recoger en los grupos . Los mensajes pueden ser dirigidas a grupos de apoyo, as como los puertos, en uno de los varios grupos modos de direccionamiento. identificadores locales: los identificadores locales se utilizan para nombrar los hilos y los puertos pertenecientes a un actor. Son enteros de 32 bits que slo son vlidas en el actor, que los utiliza. Un actor del puerto puede tener alias: su identificador local y su validez a nivel mundial) de interfaz de usuario (. Usando el identificador local es el ms eficiente, sin embargo: datos locales son generados por el ncleo para un rpido acceso a los recursos con nombre. Son similares a este respecto a los identificadores de Mach. Los identificadores nicos: Puertos y otros recursos gestionados por el ncleo se asignan poco identificadores nicos-64. Los identificadores nicos (IU) se garantiza que sea nico dentro de una red de ordenadores Coro, durante su vida til. Son fabricados como cadenas de bits con tres componentes: el tipo de recurso del ncleo identificados por ellos (por ejemplo, el puerto, el actor o grupo de puertos), el identificador del equipo que lo cre y una indicacin de la hora local garantiza que sea nico durante la vida til de la computadora. de entre los mltiples recursos accede a travs del mismo puerto. Servidores de elegir la clave por lo que es difcil de adivinar, y por lo tanto proporciona un grado de proteccin contra los accesos ilegales a los recursos. Capacidades: Estos son los tipos ms generales de identificador de recursos en Coro. Se utilizan para
file:///C|/Documents%20and%20Settings/Adm...20traducida%20de%202%20-%20Chorus.doc.htm (11 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

identificar y restringir el acceso a recursos tales como segmentos gestionado por los servidores, y tambin algunos recursos gestionados por el propio ncleo, en particular los actores y grupos de apoyo. Una capacidad consta de un identificador nico, que normalmente es el identificador de un puerto, y poco msuna estructura llamada 64 una clave (Figura 4). La clave se puede utilizar para identificar un recurso Coro utiliza las capacidades, los identificadores nicos y los identificadores locales como nombres de base de los recursos.

De nomenclatura y la proteccin
Las discusiones se han programado de forma preventiva por el ncleo de acuerdo a las prioridades de hilos individuales, pero estas prioridades se puede ajustar de forma dinmica por parte de actores. Coro apoya a nivel de la programacin de dos. se establecen las prioridades de un mensaje en relacin con el actor de prioridad de los casos, y los actores se les asigna una prioridad absoluta. la absoluta prioridad del hilo A es la suma de estas dos prioridades. Incluso las discusiones supervisor puede ser programado de forma preventiva, a fin de satisfacer las demandas en tiempo real. Por el contrario, las implementaciones de UNIX horario procesos que se ejecutan cdigo del ncleo sin suscripcin preferente. actores del sistema pueden crear subprocesos supervisor. Cmo puede un actor a nivel de usuario llegado a conocer la direccin de un procedimiento de kernel? La direccin tiene que levant la vista de procedimiento es el nombre del en la tabla de smbolos del kernel. Sin embargo, el puntero de pila de un hilo supervisor asignado por el ncleo, y el valor dado en stackPointer se ignora en este caso. Si tiene el privilegio USUARIO valor, entrada y stackPointer son las direcciones en el espacio de direcciones del actor determinado, que debe ser un agente de usuario o actor del sistema. Si privilegio es el supervisor, a continuacin, la entrada debe ser una direccin de una instruccin en el espacio de direcciones del kernel (normalmente la direccin de un procedimiento de ncleo). threadCreate (actorCap, el privilegio, el estado, prioridad, de entrada, stackPointer) crea un nuevo tema en un actor especificado con el actorCap capacidad, con privilegio de privilegio (usuario o supervisor) y con la prioridad de programacin de prioridad en relacin con el proceso. El programa inicial de contador y puntero de pila son de entrada y stackPointer. El threadCreate llamada al sistema, que sigue, se utiliza para crear un hilo en un actor: y supervisor de las discusiones del usuario Los hilos pertenecientes a los actores del sistema tienen el privilegio de que puedan hacer llamadas al sistema determinado. Esto no implica ningn privilegio especial en lo que respecta al acceso directo a los recursos de hardware como la memoria fsica y el dispositivo se registra. Sin embargo, las discusiones que pertenece a cualquier tipo de actor puede ejecutar como supervisor de las discusiones, que se ejecutan en el espacio de direcciones del ncleo, y con el procesador en modo supervisor. Por lo tanto, tienen acceso ilimitado a los recursos de hardware. Tenga en cuenta que todos los hilos pertenecientes a un actor supervisor tiene que ser supervisor de las discusiones, ya que su cdigo se asigna en el ncleo. (La estructura de las capacidades en el Coro se describe a continuacin.) Un nuevo actor siempre reside en
file:///C|/Documents%20and%20Settings/Adm...20traducida%20de%202%20-%20Chorus.doc.htm (12 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

el mismo equipo que su padre, as que no hay necesidad de especificar un equipo. La creacin de los agentes en equipos remotos se deja a los subsistemas de implementar. actorCreate (actorInit, actorCap, tipo, estado) crea un nuevo actor como un hijo de actorInit, con el tipo de tipo (usuario, sistema o supervisor). Una capacidad para el nuevo actor se devuelve a travs de actorCap; estado no especifica si todos los temas nuevos en el nuevo actor se suspendi inicialmente.

Figura 4 La capacidad de Coro. La llamada al sistema para crear un actor es actorCreate: Creacin de actores Todos los actores son creados con un solo puerto - el llamado puerto por defecto, as, a la que las operaciones sobre el actor son enviados. Un nuevo actor de la marca consiste en estado muy poco: no tiene hilos de rosca y, a diferencia de una tarea de Mach, que siempre tiene un espacio de direcciones vaca. Sin embargo, algunas de las caractersticas iniciales se definen: los actores son creados como hijos de actores existentes, de la que heredan, por ejemplo, su prioridad de planificacin. Tenga en cuenta que no todos los actores supervisor puede hacerse funcionar a nivel de usuario - incluso cuando los actores del sistema. Esto se debe a que el cdigo de un actor supervisor puede, por ejemplo, contienen las instrucciones de la mquina privilegiada para la manipulacin de registros de hardware. El intento de ejecutar estas instrucciones a nivel de usuario dara lugar a una excepcin de hardware. Los tres tipos de actores y sus principales propiedades se muestran en la Figura 3. Supervisor de actores diferentes a los otros dos tipos en que su cdigo y los datos residen en el espacio de direcciones del ncleo. Cualquier programa de prueba como un actor a nivel de usuario se pueden ejecutar sin alteracin del nivel de origen como un actor supervisor. Sin embargo, con el fin de ejecutar en el ncleo, el cdigo binario tiene que ser de enlace editado de forma dinmica. Hay dos aspectos de este. En primer lugar es necesario para el sistema del ncleo llamadas a ser sustituidas por llamadas a los procedimientos del ncleo. Dado que las discusiones que pertenecen a los actores supervisor de ejecutar en el ncleo, que debe aprovechar el mecanismo de invocacin ms barato disponible. En segundo lugar, el espacio tiene que encontrarse en el espacio de direcciones del ncleo, donde supervisor actor cdigo y los datos residirn. Ni el programa de servidor de espacio de direcciones la ubicacin, ni las direcciones de los procedimientos del ncleo que las llamadas son conocidos de antemano. Por lo tanto todos los programas absoluta direcciones utilizadas en el programa de servidor se debe establecer de forma dinmica en tiempo de carga usando la informacin de ubicacin. Actores Cada actor es un actor o de usuario, un actor del sistema o de un agente supervisor. actores del sistema y los agentes de usuario tienen sus propios espacios de direcciones separados, y no pueden acceder a la del ncleo. Sin embargo, los hilos pertenecientes a un actor del sistema puede hacer que el sistema no pide privilegios a disposicin de los agentes de usuario. Por ejemplo, a diferencia de un actor de usuario, sistema de hilos, un actor puede insertar un puerto en un grupo de puerto utilizado para proporcionar un servicio del sistema. actores del sistema se pueden crear slo por las discusiones que pertenece a los actores del sistema existente, o por las discusiones con privilegios de supervisor. En la inicializacin del sistema,
file:///C|/Documents%20and%20Settings/Adm...20traducida%20de%202%20-%20Chorus.doc.htm (13 de 14) [12-05-2011 14:45:06]

Versin traducida de 2 - Chorus.doc

uno o ms actores del sistema se crean en cada equipo, lo que puede crear un sistema de actores ms. The kernel can check whether an actor is a system actor: its status is held securely in a table in the kernel address space. A continuacin se describen estos privilegios en ms detalle, en el contexto de los actores y las discusiones. supervisor privilege : complete access to machine resources. system privilege : no direct access to machine resources, but can invoke all system calls - similar to the level of privilege of a UNIX process bearing the 'root' user identifier; user privilege : no direct access to machine resources; cannot invoke certain system calls; Coro es compatible con tres diferentes niveles de privilegio para las discusiones acceso a los recursos locales. Privilege is sometimes nominally ascribed to actors, but since only threads can take actions with respect to resources, privilege really resides with threads. El nivel tres de privilegio son: They can perform arbitrary accesses to one another's data if they so choose, or if they contain bugs. Ntese, sin embargo, que los actores se pueden depurar a nivel de usuario. If their performance at user-level is deemed unsatisfactory, they can be run later in the kernel, without altering the source code, to gain the performance advantage this brings. User actor Yes Yes Yes (created externally) System actor Yes Yes (system privilege) Yes Supervisor actor No: shares kernel's No Yes Actor type Private address space User threads Supervisor threads Figure 3 Types of actor, showing address spaces and allowable threads. With this scheme, clients are unaware of whether a server with which they communicate is a userlevel actor or is executing within the kernel. Clients and servers use the same message passing interface in either case. Moreover, the message passing interfaces can still be used between servers that reside in the same kernel address space. Inside the kernel, the implementation of message passing is designed to be efficient by taking advantage of shared memory to reduce data copying. Esto ilustra el hecho de que estos servidores utilizan la interfaz de paso de mensajes slo como una convencin.

file:///C|/Documents%20and%20Settings/Adm...20traducida%20de%202%20-%20Chorus.doc.htm (14 de 14) [12-05-2011 14:45:06]