Doors es una instalación de comunicación entre procesos para sistemas informáticos Unix . Proporcionan una forma de llamada a procedimiento .
Las puertas fueron desarrolladas por Sun Microsystems como parte central del sistema operativo Spring y luego se agregaron a Solaris en la versión 2.5 como una interfaz interna no documentada. [1] Se convirtieron en una característica documentada en Solaris 2.6. Las versiones recientes de Solaris utilizan Doors en muchos lugares, incluido nscd(el demonio de caché del servicio de nombres ) y syslog .
En 2003 se lanzó una versión Linux de Doors, pero sólo está disponible para la versión 2.4.18. [2]
El subsistema Doors se implementa como una biblioteca de espacio de usuario con cierto soporte de kernel y depende en gran medida de subprocesos . Está diseñado para reducir los gastos generales y la implementación de Solaris utiliza algún código ensamblador para lograr la máxima eficiencia.
Las puertas son creadas por procesos del servidor (que deben usar subprocesos) y llamadas por procesos del cliente. Es posible que un proceso cree y llame a una puerta. Al crear una puerta, el servidor debe especificar un procedimiento de servidor, que será llamado por la biblioteca de Doors en nombre de los clientes. A diferencia de la mayoría de los sistemas de llamadas a procedimientos remotos , cada puerta tiene un solo procedimiento de servidor. Un servidor puede "adjuntar" una puerta a un archivo, permitiendo a los clientes conectarse a esa puerta simplemente abriendo ese archivo. Luego, el ls -lcomando mostrará el archivo con un 'tipo' de "D" (no debe confundirse con "d" para un directorio), por ejemplo:
$ ls -l total 9 Drw-r--r-- 1 jmorrison dev 876 8 de diciembre 19:43 myfileLos clientes suelen door_call()invocar el procedimiento del servidor de la puerta, pasando una región contigua de memoria y una lista de descriptores de archivos como argumentos, y recuperando otra región contigua y una lista de descriptores de archivos. Cualquiera de las regiones puede estar vacía, al igual que cualquiera de las listas. Normalmente, se definirán dos C struct , uno para los datos de entrada y otro para los datos de salida. (Alternativamente, se pueden usar uniones etiquetadas , lo que permite que un procedimiento de puerta proporcione múltiples acciones de manera muy similar a la llamada al sistema ioctl ). Cada descriptor de archivo va acompañado de una palabra de bandera. La DOOR_RELEASEbandera solicita que se cierre un descriptor de archivo en el proceso de envío después de duplicarlo en el proceso de recepción. Si se envía un descriptor de archivo que hace referencia a una puerta, el sistema registra las propiedades de esa puerta en la palabra flags.
Además de representar un procedimiento o un grupo de procedimientos, una puerta puede representar un objeto de datos con estado , lo que permite pasar referencias a dichos objetos entre procesos. Una puerta de este tipo normalmente tomaría una unión etiquetada como datos de entrada y cada valor de etiqueta indicaría un método diferente .
El sistema Doors también proporciona una forma para que los clientes y servidores obtengan información entre sí. Por ejemplo, un servidor puede verificar el usuario del cliente o la identificación del proceso para implementar el control de acceso .
La biblioteca de Doors normalmente crea y administra un grupo de subprocesos en el proceso del servidor para manejar llamadas, pero es posible anular este comportamiento. El sistema Doors no proporciona ningún tipo de sincronización, pero los servidores pueden usar las primitivas de sincronización normales a nivel de subproceso. Las puertas se pueden utilizar para sincronizar el acceso a segmentos de memoria compartida , lo que permite la transferencia de datos en una sola copia. [3]
El concepto de Doors es muy similar a la especificación X/Open XATMI API, donde los procesos del cliente invocan las funciones expuestas de los procesos del servidor: door_call()es análogo a tpcall()los clientes XATMI, mientras que door_return()es análogo a tpreturn()los servidores XATMI.