Comunicaciones entre procesos

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 en 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 de servidor de 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 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.

• ¿Debe la aplicación poder 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 aplicaciones en el equipo local?
• ¿Debe la aplicación poder comunicarse con las aplicaciones que se ejecutan en otros equipos que se pueden ejecutar en sistemas operativos diferentes (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 puede encontrar implícitamente sus asociados cooperantes?
• ¿La aplicación debe comunicarse con muchas aplicaciones diferentes de forma general, como permitir operaciones de corte y pegado con cualquier otra aplicación, o debe limitarse sus requisitos de comunicaciones a un conjunto restringido de interacciones con otras aplicaciones específicas?
• ¿El rendimiento es un aspecto crítico de la aplicación? Todos los mecanismos ipc incluyen cierta cantidad de sobrecarga.
• ¿Debe la aplicación 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:

• del Portapapeles
• COM
• de copia de datos de
• DDE
• de asignación de archivos de
• Mailslots
• canalizaciones de
• RPC
• de Windows Sockets de

Uso del Portapapeles para IPC

El Portapapeles actúa como un depósito 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 acoplado de forma 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 procesador de texto debe poder producir y aceptar datos del Portapapeles en formato de texto puro. Para obtener más información, vea 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 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 salga de la hoja de cálculo, el gráfico se actualizará 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 que una aplicación incluya datos incrustados o vinculados que, cuando se elija, inicie automáticamente otra aplicación para la edición de datos. Esto permite que la aplicación se extienda mediante cualquier otra aplicación que use OLE. Los objetos COM proporcionan acceso a los datos de un objeto a través de uno o varios conjuntos de funciones relacionadas, conocidos como interfaces . Para obtener más información, vea Servicios de objetos COM y ActiveX.

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: 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, vea Data Copy.

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 los nuevos datos estén disponibles.

Los formatos de datos utilizados por DDE son los mismos que los usados por el Portapapeles. DDE puede considerarse 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 continúa funcionando sin 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 las tecnologías más recientes. Sin embargo, puede seguir usando 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 dynamic Data Exchange y Dynamic Data Exchange Management Library.

Usar una asignación de archivos para IPC

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 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: 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, consulte de asignación de archivos y sincronización de .

Uso de mailslot para IPC

Los mailslots 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. El 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 mailslots.

Un cliente mailslot puede enviar un mensaje a un mailslot en su equipo local, a un mailslot en otro equipo o a todos los mailslots con el mismo nombre en todos los equipos de un dominio de red especificado. Los mensajes que se transmiten a todos los mailslots de un dominio no pueden superar los 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 ofrecen una manera fácil de enviar y recibir 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. canalizaciones anónimas permitir 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.

canalizaciones con nombre se usan para transferir datos entre procesos que no están 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: canalizaciones anónimas proporcionan una manera eficaz de redirigir la entrada o salida estándar a los procesos secundarios del 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.

La RPC proporcionada por Windows es compatible con open Software Foundation (OSF) Distributed Computing Environment (DCE). Esto significa que las aplicaciones que usan RPC pueden comunicarse con las 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 Microsoft RPC Components.

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 popularizados por la distribución de software de Berkeley (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 las funcionalidades de red actuales y emergentes. Para obtener más información, vea Windows Sockets 2.

Función de socket unix (AF_UNIX) en Windows

A partir de windows Insider Build 17063, puedes usar la familia de direcciones de socket unix (AF_UNIX) en Windows para comunicarse entre procesos Win32. Los sockets unix permiten la comunicación entre procesos (IPC) entre procesos en la misma máquina. Para obtener más información, consulta la entrada de blog AF_UNIX viene a Windows.

Desuso del protocolo Mailslot remoto

A partir de windows 11 Insider Preview Build 25314 y Windows Server Preview Build 25314, hemos empezado a deshabilitar el protocolo Remote Mailslot de forma predeterminada. Este es un precursor de la desuso y la eliminación final de Windows. Para obtener más información, consulta la entrada de blog El principio del final de Remote Mailslots como parte de Windows Insider.