Comunicaciones entre procesos

  • Artículo

El sistema operativo Windows proporciona mecanismos para facilitar las comunicaciones y el uso compartido de datos entre aplicaciones. Colectivamente, las actividades habilitadas por estos mecanismos se denominan comunicaciones entre procesos (IPC). Algunas formas de IPC facilitan la división del trabajo entre varios procesos especializados. Otras formas de IPC facilitan la división del trabajo entre equipos de una red.

Normalmente, las aplicaciones pueden usar IPC clasificadas como clientes o servidores. Un cliente es una aplicación o un proceso que solicita un servicio de alguna otra aplicación o proceso. Un servidor es una aplicación o un proceso que responde a una solicitud de cliente. Muchas aplicaciones actúan como un cliente y un servidor, en función de la situación. Por ejemplo, una aplicación de procesamiento de texto podría actuar como un cliente al solicitar una tabla de resumen de los costos de fabricación de una aplicación de hoja de cálculo que actúa como servidor. La aplicación de hoja de cálculo, a su vez, podría actuar como un cliente para solicitar los niveles de inventario más recientes desde una aplicación de control de inventario automatizada.

Después de decidir que la aplicación se beneficiaría de IPC, debe decidir cuál de los métodos IPC disponibles que se van a usar. Es probable que una aplicación use varios mecanismos IPC. Las respuestas a estas preguntas determinan si una aplicación puede beneficiarse mediante uno o varios mecanismos IPC.

  • ¿La aplicación puede comunicarse con otras aplicaciones que se ejecutan en otros equipos de una red o es suficiente para que la aplicación se comunique solo con las aplicaciones del equipo local?
  • ¿Debe la aplicación poder comunicarse con las aplicaciones que se ejecutan en otros equipos que se pueden ejecutar en diferentes sistemas operativos (como Windows o UNIX de 16 bits)?
  • ¿Debe el usuario de la aplicación elegir las otras aplicaciones con las que se comunica la aplicación o encontrar implícitamente sus asociados cooperantes?
  • ¿La aplicación debe comunicarse con muchas aplicaciones diferentes de forma general, como permitir operaciones de cortar y pegar con cualquier otra aplicación, o debe limitarse a un conjunto restringido de interacciones con otras aplicaciones?
  • ¿El rendimiento es un aspecto crítico de la aplicación? Todos los mecanismos ipc incluyen cierta cantidad de sobrecarga.
  • ¿La aplicación debe ser una aplicación de GUI o una aplicación de consola? Algunos mecanismos IPC requieren una aplicación de GUI.

Windows admite los siguientes mecanismos IPC:

Uso del Portapapeles para IPC

El Portapapeles actúa como depositario central para el uso compartido de datos entre aplicaciones. Cuando un usuario realiza una operación de corte o copia en una aplicación, la aplicación coloca los datos seleccionados en el Portapapeles en uno o varios formatos estándar o definidos por la aplicación. A continuación, cualquier otra aplicación puede recuperar los datos del Portapapeles, eligiendo entre los formatos disponibles que comprende. El Portapapeles es un medio de intercambio muy flexible, donde las aplicaciones solo necesitan aceptar el formato de datos. Las aplicaciones pueden residir en el mismo equipo o en equipos diferentes de una red.

Punto clave: Todas las aplicaciones deben admitir el Portapapeles para esos formatos de datos que comprendan. Por ejemplo, un editor de texto o un procesador de texto debe poder generar y aceptar datos del Portapapeles en formato de texto puro. Para obtener más información, consulte Portapapeles.

Uso de COM para IPC

Las aplicaciones que usan OLE administran documentos compuestos, es decir, documentos formados por datos de una variedad de aplicaciones diferentes. OLE proporciona servicios que facilitan que las aplicaciones llamen a en otras aplicaciones para la edición de datos. Por ejemplo, un procesador de texto que usa OLE podría insertar un grafo de una hoja de cálculo. El usuario podría iniciar la hoja de cálculo automáticamente desde el procesador de texto eligiendo el gráfico incrustado para su edición. OLE se encarga de iniciar la hoja de cálculo y presentar el gráfico para su edición. Cuando el usuario sale de la hoja de cálculo, el gráfico se actualizaría en el documento original del procesador de texto. La hoja de cálculo parece ser una extensión del procesador de texto.

La base de OLE es el modelo de objetos componentes (COM). Un componente de software que usa COM puede comunicarse con una amplia variedad de otros componentes, incluso aquellos que aún no se han escrito. Los componentes interactúan como objetos y clientes. Com distribuido amplía el modelo de programación COM para que funcione a través de una red.

Punto clave: OLE admite documentos compuestos y permite a una aplicación incluir datos incrustados o vinculados que, cuando se elige, inicia automáticamente otra aplicación para la edición de datos. Esto permite que cualquier otra aplicación que use OLE amplíe la aplicación. Los objetos COM proporcionan acceso a los datos de un objeto a través de uno o varios conjuntos de funciones relacionadas, conocidas como interfaces. Para obtener más información, vea COM y ActiveX Object Services.

Uso de la copia de datos para IPC

La copia de datos permite a una aplicación enviar información a otra aplicación mediante el mensaje WM_COPYDATA . Este método requiere la cooperación entre la aplicación de envío y la aplicación receptora. La aplicación receptora debe conocer el formato de la información y poder identificar al remitente. La aplicación de envío no puede modificar la memoria a la que hacen referencia ningún puntero.

Punto clave: La copia de datos se puede usar para enviar rápidamente información a otra aplicación mediante la mensajería de Windows. Para obtener más información, consulte Copia de datos.

Uso de DDE para IPC

DDE es un protocolo que permite a las aplicaciones intercambiar datos en diversos formatos. Las aplicaciones pueden usar DDE para intercambios de datos únicos o para intercambios continuos en los que las aplicaciones se actualizan entre sí a medida que haya nuevos datos disponibles.

Los formatos de datos usados por DDE son los mismos que los usados por el Portapapeles. DDE se puede considerar como una extensión del mecanismo del Portapapeles. El Portapapeles casi siempre se usa para una respuesta única a un comando de usuario, como elegir el comando Pegar en un menú. DDE también se inicia normalmente mediante un comando de usuario, pero a menudo sigue funcionando sin ninguna interacción adicional del usuario. También puede definir formatos de datos DDE personalizados para IPC de propósito especial entre aplicaciones con requisitos de comunicaciones más estrechamente acoplados.

Los intercambios de DDE pueden producirse entre aplicaciones que se ejecutan en el mismo equipo o en equipos diferentes de una red.

Punto clave: DDE no es tan eficaz como tecnologías más recientes. Sin embargo, todavía puede usar DDE si otros mecanismos IPC no son adecuados o si debe interactuar con una aplicación existente que solo admita DDE. Para obtener más información, vea Intercambio dinámico de datos y Biblioteca de administración de Intercambio de datos dinámicos.

Uso de una asignación de archivos para IPC

La asignación de archivos permite a un proceso tratar el contenido de un archivo como si fueran un bloque de memoria en el espacio de direcciones del proceso. El proceso puede usar operaciones de puntero simples para examinar y modificar el contenido del archivo. Cuando dos o más procesos acceden a la misma asignación de archivos, cada proceso recibe un puntero a la memoria en su propio espacio de direcciones que puede usar para leer o modificar el contenido del archivo. Los procesos deben usar un objeto de sincronización, como un semáforo, para evitar daños en los datos en un entorno de multitarea.

Puede usar un caso especial de asignación de archivos para proporcionar memoria compartida con nombre entre procesos. Si especifica el archivo de intercambio del sistema al crear un objeto de asignación de archivos, el objeto de asignación de archivos se trata como un bloque de memoria compartido. Otros procesos pueden acceder al mismo bloque de memoria abriendo el mismo objeto de asignación de archivos.

La asignación de archivos es bastante eficaz y también proporciona atributos de seguridad compatibles con el sistema operativo que pueden ayudar a evitar daños en los datos no autorizados. La asignación de archivos solo se puede usar entre procesos en un equipo local; no se puede usar a través de una red.

Punto clave: La asignación de archivos es una manera eficaz de dos o más procesos en el mismo equipo para compartir datos, pero debe proporcionar sincronización entre los procesos. Para obtener más información, vea Asignación de archivos y sincronización.

Uso de mailslot para IPC

Los gráficos de correo proporcionan comunicación unidireccional. Cualquier proceso que cree un mailslot es un servidor mailslot. Otros procesos, denominados clientes de mailslot, envían mensajes al servidor mailslot escribiendo un mensaje en su mailslot. Los mensajes entrantes siempre se anexan al mailslot. Mailslot guarda los mensajes hasta que el servidor mailslot los haya leído. Un proceso puede ser un servidor mailslot y un cliente mailslot, por lo que la comunicación bidireccional es posible mediante varios gráficos de correo.

Un cliente mailslot puede enviar un mensaje a un mailslot en su equipo local, a un mailslot en otro equipo o a todos los gráficos de correo con el mismo nombre en todos los equipos de un dominio de red especificado. Los mensajes que se transmiten a todos los gráficos de correo de un dominio no pueden tener más de 400 bytes, mientras que los mensajes enviados a un único mailslot solo están limitados por el tamaño máximo de mensaje especificado por el servidor mailslot cuando creó el mailslot.

Punto clave: Mailslots ofrece una manera sencilla para que las aplicaciones envíen y reciban mensajes cortos. También proporcionan la capacidad de difundir mensajes en todos los equipos de un dominio de red. Para obtener más información, vea Mailslots.

Uso de canalizaciones para IPC

Hay dos tipos de canalizaciones para la comunicación bidireccional: canalizaciones anónimas y canalizaciones con nombre. Las canalizaciones anónimas permiten que los procesos relacionados transfieran información entre sí. Normalmente, se usa una canalización anónima para redirigir la entrada o salida estándar de un proceso secundario para que pueda intercambiar datos con su proceso primario. Para intercambiar datos en ambas direcciones (operación dúplex), debe crear dos canalizaciones anónimas. El proceso primario escribe datos en una canalización mediante su identificador de escritura, mientras que el proceso secundario lee los datos de esa canalización mediante su identificador de lectura. Del mismo modo, el proceso secundario escribe datos en la otra canalización y el proceso primario lo lee. Las canalizaciones anónimas no se pueden usar a través de una red, ni se pueden usar entre procesos no relacionados.

Las canalizaciones con nombre se usan para transferir datos entre procesos que no son procesos relacionados y entre procesos en equipos diferentes. Normalmente, un proceso de servidor de canalización con nombre crea una canalización con nombre con un nombre conocido o un nombre que se va a comunicar a sus clientes. Un proceso de cliente de canalización con nombre que conoce el nombre de la canalización puede abrir su otro extremo, sujeto a restricciones de acceso especificadas por el proceso de servidor de canalización con nombre. Después de que el servidor y el cliente se hayan conectado a la canalización, pueden intercambiar datos realizando operaciones de lectura y escritura en la canalización.

Punto clave: Las canalizaciones anónimas proporcionan una manera eficaz de redirigir la entrada o salida estándar a los procesos secundarios en el mismo equipo. Las canalizaciones con nombre proporcionan una interfaz de programación sencilla para transferir datos entre dos procesos, tanto si residen en el mismo equipo como en una red. Para obtener más información, consulte Canalizaciones.

Uso de RPC para IPC

RPC permite a las aplicaciones llamar a funciones de forma remota. Por lo tanto, RPC hace que IPC sea tan fácil como llamar a una función. RPC funciona entre procesos en un solo equipo o en equipos diferentes de una red.

El RPC proporcionado por Windows es compatible con open Software Foundation (OSF) Distributed Computing Environment (DCE). Esto significa que las aplicaciones que usan RPC pueden comunicarse con aplicaciones que se ejecutan con otros sistemas operativos que admiten DCE. RPC admite automáticamente la conversión de datos para tener en cuenta diferentes arquitecturas de hardware y para ordenar por bytes entre entornos diferentes.

Los clientes y servidores RPC están estrechamente acoplados, pero siguen manteniendo un alto rendimiento. El sistema hace un uso extenso de RPC para facilitar una relación de cliente/servidor entre diferentes partes del sistema operativo.

Punto clave: RPC es una interfaz de nivel de función, compatible con la conversión automática de datos y para las comunicaciones con otros sistemas operativos. Con RPC, puede crear aplicaciones distribuidas estrechamente acopladas y de alto rendimiento. Para obtener más información, vea Componentes rpc de Microsoft.

Uso de Windows Sockets para IPC

Windows Sockets es una interfaz independiente del protocolo. Aprovecha las funcionalidades de comunicación de los protocolos subyacentes. En Windows Sockets 2, un identificador de socket se puede usar opcionalmente como identificador de archivo con las funciones de E/S de archivos estándar.

Windows Sockets se basan en los sockets populares por primera vez por Berkeley Software Distribution (BSD). Una aplicación que usa Windows Sockets puede comunicarse con otra implementación de socket en otros tipos de sistemas. Sin embargo, no todos los proveedores de servicios de transporte admiten todas las opciones disponibles.

Punto clave: Windows Sockets es una interfaz independiente del protocolo capaz de admitir funcionalidades de red actuales y emergentes. Para obtener más información, consulte Windows Sockets 2.