Comunicación entre procesos (IPC)

En este tema se explican varias maneras de realizar la comunicación entre procesos (IPC) entre SDK de Aplicaciones para Windows aplicaciones de escritorio y otras aplicaciones Win32. Dado que las aplicaciones de escritorio de SDK de Aplicaciones para Windows se ejecutan como procesos Win32 de confianza total, tienen acceso directo a todos los mecanismos IPC del sistema operativo. Algunos mecanismos tienen requisitos adicionales cuando las aplicaciones se empaquetan con MSIX, como se indica en las secciones siguientes.

Servicios de aplicaciones

Los servicios de aplicación permiten que las aplicaciones expongan servicios que aceptan y devuelven conjuntos de propiedades de tipos primitivos (ValueSet) en segundo plano. Los objetos complejos se pueden transmitir si se serializan.

Los servicios de aplicaciones se pueden ejecutar fuera del proceso como una tarea en segundo plano o en proceso dentro de la aplicación en primer plano.

Los servicios de aplicaciones se usan mejor para compartir pequeñas cantidades de datos en los que no se requiere latencia casi en tiempo real.

COM

COM es un sistema distribuido orientado a objetos para crear componentes de software binarios que pueden interactuar y comunicarse. Como desarrollador, se usa COM para crear componentes de software reutilizables y capas de automatización para una aplicación. Los componentes COM pueden estar en proceso o fuera del proceso, y pueden comunicarse a través de un modelo de cliente y servidor . Los servidores COM fuera de proceso se han usado durante mucho tiempo como medio para la comunicación entre objetos.

Las aplicaciones empaquetadas con la runFullTrust funcionalidad pueden registrar servidores COM fuera de proceso para IPC mediante el manifiesto del paquete. Esto se conoce como COM empaquetado.

SDK de Aplicaciones para Windows aplicaciones de escritorio se ejecutan como procesos de plena confianza, por lo que también pueden registrar y usar servidores COM directamente a través del Registro de Windows, al igual que las aplicaciones win32 tradicionales.

Filesystem

BroadFileSystemAccess

Las aplicaciones empaquetadas pueden realizar IPC mediante el sistema de archivos general al declarar la capacidad restringida broadFileSystemAccess. Esta funcionalidad concede a las API de Windows.Storage y a las API Win32 FromApp acceso al sistema de archivos completo.

De forma predeterminada, IPC a través del sistema de archivos para aplicaciones empaquetadas está restringido a los demás mecanismos descritos en esta sección.

PublisherCacheFolder

PublisherCacheFolder permite a las aplicaciones empaquetadas declarar carpetas en su manifiesto que el mismo publicador puede compartir con otros paquetes.

La carpeta de almacenamiento compartido tiene los siguientes requisitos y restricciones:

• Los datos de la carpeta de almacenamiento compartido no se copian como copia de seguridad ni se sincronizan entre dispositivos.
• El usuario puede borrar el contenido de la carpeta de almacenamiento compartido.
• No puede usar la carpeta de almacenamiento compartido para compartir datos entre aplicaciones de distintos publicadores.
• No puede usar la carpeta de almacenamiento compartido para compartir datos entre distintos usuarios.
• La carpeta de almacenamiento compartido no tiene administración de versiones.

Si publica varias aplicaciones y busca un mecanismo sencillo para compartir datos entre ellas, PublisherCacheFolder es una opción sencilla basada en el sistema de archivos.

Tubería

Las canalizaciones permiten una comunicación sencilla entre un servidor de canalización y uno o varios clientes de canalización.

Las canalizaciones anónimas y las canalizaciones con nombre se admiten con las restricciones siguientes:

• De forma predeterminada, las canalizaciones con nombre en aplicaciones empaquetadas solo son compatibles entre procesos dentro del mismo paquete, a menos que un proceso sea de confianza plena.
• Las canalizaciones con nombre se pueden compartir entre paquetes siguiendo las instrucciones para compartir objetos con nombre.
• Las canalizaciones con nombre de las aplicaciones empaquetadas deben incluir LOCAL\ en el nombre de la canalización (por ejemplo, \\.\pipe\LOCAL\<pipename>). El segmento LOCAL\ restringe la canalización a la sesión de inicio de sesión del llamante y es necesario para las aplicaciones empaquetadas en MSIX. Al usar las API de .NET como NamedPipeServerStream, pase solo la parte LOCAL\<pipename>; el prefijo \\.\pipe\ se gestiona internamente.

Las aplicaciones de escritorio de SDK de Aplicaciones para Windows se ejecutan como procesos de confianza total, por lo que pueden crear y usar canalizaciones con nombre sin la restricción de pertenecer al mismo paquete. Sin embargo, si se está comunicando con otra aplicación empaquetada que no tiene plena confianza, las restricciones anteriores siguen aplicándose.

Ejemplo de una canalización con nombre (C#)

En el ejemplo siguiente se muestra un servidor y un cliente de canalización con nombre completos, en forma de dos aplicaciones de consola. Dado que las aplicaciones de escritorio de SDK de Aplicaciones para Windows son procesos de plena confianza, el IPC mediante canalizaciones con nombre funciona sin ninguna capacidad especial ni entradas en el manifiesto.

Para probar este ejemplo, cree dos proyectos de aplicación de consola (dirigidos net8.0-windows con ImplicitUsings habilitado) y ejecute primero el servidor y, a continuación, el cliente en un terminal independiente.

Servidor de canalización : crea una canalización con nombre y devuelve mensajes al cliente:

using System.Text;

string PipeName = @"LOCAL\WinAppSdkIpcDemo";

Console.WriteLine("Named Pipe Server");
Console.WriteLine($"  Process ID: {Environment.ProcessId}");
Console.WriteLine($"  User:       {Environment.UserName}");
Console.WriteLine($"  Pipe:       \\\\.\\pipe\\{PipeName}");
Console.WriteLine();

using var server = new System.IO.Pipes.NamedPipeServerStream(
    PipeName,
    System.IO.Pipes.PipeDirection.InOut,
    maxNumberOfServerInstances: 1,
    System.IO.Pipes.PipeTransmissionMode.Message,
    System.IO.Pipes.PipeOptions.Asynchronous);

Console.WriteLine("Waiting for client...");
await server.WaitForConnectionAsync();
Console.WriteLine("Client connected!");

byte[] buffer = new byte[4096];

while (server.IsConnected)
{
    try
    {
        int bytesRead = await server.ReadAsync(buffer);
        if (bytesRead == 0) break;

        string received = Encoding.UTF8.GetString(buffer, 0, bytesRead);
        Console.WriteLine($"  Received: \"{received}\"");

        if (received.Equals("QUIT", StringComparison.OrdinalIgnoreCase))
            break;

        // Echo the message back with the server's process ID
        string reply = $"Echo from PID {Environment.ProcessId}: {received}";
        await server.WriteAsync(Encoding.UTF8.GetBytes(reply));
        await server.FlushAsync();
    }
    catch (IOException)
    {
        break;
    }
}

Console.WriteLine("Done.");

Cliente de tubería — se conecta al servidor y envía la entrada del usuario:

using System.Text;

string PipeName = @"LOCAL\WinAppSdkIpcDemo";

Console.WriteLine("Named Pipe Client");
Console.WriteLine($"  Process ID: {Environment.ProcessId}");
Console.WriteLine();

using var client = new System.IO.Pipes.NamedPipeClientStream(
    serverName: ".",
    pipeName: PipeName,
    System.IO.Pipes.PipeDirection.InOut,
    System.IO.Pipes.PipeOptions.Asynchronous);

Console.WriteLine("Connecting...");
await client.ConnectAsync(timeout: 5000);
client.ReadMode = System.IO.Pipes.PipeTransmissionMode.Message;
Console.WriteLine("Connected! Type messages (or QUIT to exit):");

byte[] buffer = new byte[4096];

while (true)
{
    Console.Write("> ");
    string? input = Console.ReadLine();
    if (string.IsNullOrEmpty(input)) continue;

    await client.WriteAsync(Encoding.UTF8.GetBytes(input));
    await client.FlushAsync();

    if (input.Equals("QUIT", StringComparison.OrdinalIgnoreCase))
        break;

    int bytesRead = await client.ReadAsync(buffer);
    string response = Encoding.UTF8.GetString(buffer, 0, bytesRead);
    Console.WriteLine($"  <- {response}");
}

Console.WriteLine("Done.");

Al ejecutar ambas aplicaciones, el cliente envía mensajes que el servidor vuelve a reproducir, confirmando la comunicación entre procesos entre dos procesos de escritorio de plena confianza sin ninguna configuración especial necesaria.

Registro

El uso del registro para IPC suele desaconsejarse, pero es compatible con el código existente. Las aplicaciones empaquetadas solo pueden acceder a las claves del Registro a las que tienen permiso de acceso.

Las aplicaciones de escritorio empaquetadas (consulte Creación de un paquete MSIX a partir del código) aprovechan la virtualización del registro para que las escrituras globales del registro estén contenidas en un subárbol privado dentro del paquete MSIX. Esto permite la compatibilidad con el código fuente al minimizar el impacto global del registro y se puede usar para IPC entre procesos del mismo paquete. Si debe usar el registro, se prefiere este modelo frente a manipular el registro global.

RPC

RPC se puede usar para conectar una aplicación empaquetada a un punto de conexión RPC de Win32, siempre que la aplicación empaquetada tenga las funcionalidades correctas para que coincidan con las ACL en el punto de conexión RPC.

Las funcionalidades personalizadas permiten a los OEM e IMV definir funcionalidades arbitrarias, ACL sus puntos de conexión RPC con ellos y, a continuación, conceder esas funcionalidades a las aplicaciones cliente autorizadas. Para obtener una aplicación de ejemplo completa, consulte el ejemplo CustomCapability .

Los puntos de conexión RPC también pueden protegerse mediante ACL para aplicaciones empaquetadas específicas, a fin de limitar el acceso al punto de conexión únicamente a esas aplicaciones sin requerir la sobrecarga de gestión de capacidades personalizadas. Puede usar la API DeriveAppContainerSidFromAppContainerName para derivar un SID de un nombre de familia de paquete y, a continuación, ACL el punto de conexión RPC con el SID como se muestra en el ejemplo CustomCapability .

Memoria compartida

La asignación de archivos se puede usar para compartir un archivo o memoria entre dos o más procesos con las restricciones siguientes:

• De forma predeterminada, las asignaciones de archivos en las aplicaciones empaquetadas solo se admiten entre procesos dentro del mismo paquete, a menos que un proceso sea de plena confianza.
• Las asociaciones de archivos se pueden compartir entre paquetes siguiendo las directrices para compartir objetos con nombre.

SDK de Aplicaciones para Windows aplicaciones de escritorio se ejecutan como procesos de plena confianza, por lo que pueden crear y usar asignaciones de archivos de memoria compartida sin restricciones. Al comunicarse con otra aplicación empaquetada que no tiene confianza total, use el enfoque de ACL descrito en compartir objetos con nombre.

Se recomienda memoria compartida para compartir y manipular grandes cantidades de datos de forma eficaz.

Loopback

El loopback es el proceso de comunicarse con un servidor de red que escucha en localhost (la dirección de loopback).

Para mantener la seguridad y el aislamiento de red, las conexiones de bucle local usadas para IPC se bloquean de forma predeterminada para las aplicaciones empaquetadas. Puede habilitar conexiones de bucle invertido entre aplicaciones empaquetadas de confianza mediante funcionalidades y propiedades de manifiesto.

• Todas las aplicaciones empaquetadas que participan en conexiones de bucle invertido deben declarar la privateNetworkClientServer funcionalidad en sus manifiestos de paquete.
• Dos aplicaciones empaquetadas se pueden comunicar a través de bucle invertido declarando LoopbackAccessRules dentro de sus manifiestos de paquete.
  • Cada aplicación debe enumerar la otra en su LoopbackAccessRules. El cliente declara una regla de "salida" para el servidor, y el servidor declara reglas de "entrada" para sus clientes compatibles.

Las aplicaciones y servicios sin empaquetar no tienen identidad de paquete, por lo que no se pueden declarar en LoopbackAccessRules. Puede configurar una aplicación empaquetada para conectarse mediante loopback con aplicaciones y servicios no empaquetados mediante CheckNetIsolation.exe; sin embargo, esto solo es posible en escenarios de instalación por carga lateral o depuración en los que se dispone de acceso local al equipo y de privilegios de administrador.

• Si una aplicación empaquetada se conecta a una aplicación o servicio sin empaquetar, ejecute CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> para agregar una exención de bucle invertido para la aplicación empaquetada.
• Si una aplicación o servicio sin empaquetar se conecta a una aplicación empaquetada, ejecute CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> para permitir que la aplicación empaquetada reciba conexiones de bucle invertido de entrada.
  • CheckNetIsolation.exe debe ejecutarse continuamente mientras la aplicación empaquetada escucha las conexiones.

Elección de un mecanismo de IPC

En la tabla siguiente se resumen los mecanismos ipc y sus mejores casos de uso:

Contenido relacionado

• Uso compartido de objetos con nombre
• introducción a SDK de Aplicaciones para Windows
• Introducción al empaquetado MSIX