IPC (Comunicação Entre Processos)

Este tópico explica várias maneiras de executar a IPC (comunicação entre processos) entre SDK do Aplicativo Windows aplicativos da área de trabalho e outros aplicativos Win32. Como aplicativos da área de trabalho do SDK do Aplicativo Windows são executados como processos Win32 de confiança total, eles têm acesso direto a todos os mecanismos de IPC em nível de sistema operacional. Alguns mecanismos têm requisitos adicionais quando os aplicativos são empacotados com MSIX, conforme observado nas seções abaixo.

Serviços de aplicativo

Os serviços de aplicativo permitem que os aplicativos exponham serviços que aceitam e retornam conjuntos de propriedades de tipos primitivos (ValueSet) em segundo plano. Objetos complexos podem ser transmitidos se forem serializados.

Os serviços de aplicativo podem ser executados fora do processo como uma tarefa em segundo plano ou em processo dentro do aplicativo em primeiro plano.

Note

Os serviços de aplicativo exigem um aplicativo empacotado com a identidade do pacote. Eles estão disponíveis para aplicativos do SDK do Aplicativo Windows empacotados com MSIX.

Os serviços de aplicativo são melhor usados para compartilhar pequenas quantidades de dados em que a latência quase em tempo real não é necessária.

COM

O COM é um sistema distribuído orientado a objetos para criar componentes de software binário que podem interagir e se comunicar. Como desenvolvedor, você usa COM para criar componentes de software reutilizáveis e camadas de automação para um aplicativo. Os componentes COM podem estar em processo ou fora do processo e podem se comunicar por meio de um modelo de cliente e servidor . Os servidores COM fora de processo têm sido usados há muito tempo como um meio de comunicação entre objetos.

Aplicações empacotadas com o recurso runFullTrust podem registrar servidores COM fora de processo para IPC por meio do manifesto do pacote. Isso é conhecido como COM empacotado.

Os aplicativos da área de trabalho do SDK do Aplicativo Windows são executados como processos com privilégios totais, portanto também podem registrar e usar servidores COM diretamente por meio do Registro do Windows, assim como os aplicativos Win32 tradicionais.

Filesystem

BroadFileSystemAccess

Aplicativos empacotados podem executar IPC usando o amplo sistema de arquivos declarando a broadFileSystemAccess funcionalidade restrita. Essa funcionalidade concede às APIs Windows.Storage e às APIs Win32 FromApp acesso ao amplo sistema de arquivos.

Por padrão, o IPC por meio do sistema de arquivos para aplicativos empacotados é restrito aos outros mecanismos descritos nesta seção.

PublisherCacheFolder

O PublisherCacheFolder permite que aplicativos empacotados declarem pastas no manifesto que podem ser compartilhadas com outros pacotes do mesmo fornecedor.

A pasta de armazenamento compartilhado tem os seguintes requisitos e restrições:

  • Os dados na pasta de armazenamento compartilhada não passam por backup nem são sincronizados entre dispositivos.
  • O usuário pode limpar o conteúdo da pasta de armazenamento compartilhado.
  • Você não pode usar a pasta de armazenamento compartilhado para compartilhar dados entre aplicativos de diferentes editores.
  • Você não pode usar a pasta de armazenamento compartilhado para compartilhar dados entre usuários diferentes.
  • A pasta de armazenamento compartilhado não tem gerenciamento de versão.

Se você publicar vários aplicativos e estiver procurando um mecanismo simples para compartilhar dados entre eles, o PublisherCacheFolder será uma opção simples baseada em sistema de arquivos.

Tubos

Os pipes permitem uma comunicação simples entre um servidor de pipe e um ou mais clientes de pipe.

Há suporte para pipes anônimos e pipes nomeados com as seguintes restrições:

  • Por padrão, pipes nomeados em aplicativos empacotados têm suporte apenas entre processos dentro do mesmo pacote, a menos que um processo seja de confiança total.
  • Os pipes nomeados podem ser compartilhados entre pacotes seguindo as diretrizes para compartilhar objetos nomeados.
  • Pipes nomeados em aplicativos empacotados devem incluir LOCAL\ no nome do pipe (por exemplo, \\.\pipe\LOCAL\<pipename>). O segmento LOCAL\ delimita o pipe para a sessão de logon do chamador e é necessário para aplicativos empacotados em MSIX. Ao usar .NET APIs como NamedPipeServerStream, passe apenas a LOCAL\<pipename> parte – o \\.\pipe\ prefixo é tratado internamente.

Os aplicativos de desktop do SDK do Aplicativo Windows são executados como processos com confiança total, de modo que podem criar e usar pipes nomeados sem a restrição de pertencer ao mesmo pacote. No entanto, se você estiver se comunicando com outro aplicativo empacotado que não tenha total confiança, as restrições acima ainda se aplicam.

Exemplo de pipe nomeado (C#)

O exemplo a seguir demonstra um servidor e um cliente de pipe nomeado completos, na forma de dois aplicativos de console. Como os aplicativos da área de trabalho do SDK do Aplicativo Windows são processos totalmente confiáveis, o IPC por pipe nomeado funciona sem recursos especiais nem entradas no manifesto.

Para experimentar este exemplo, crie dois projetos de aplicativo de console (direcionamento net8.0-windows com ImplicitUsings habilitado) e execute o servidor primeiro e, em seguida, o cliente em um terminal separado.

Servidor de pipe — cria um pipe nomeado e retorna as mensagens ao 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 pipe – conecta-se ao servidor e envia a entrada do usuário:

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.");

Quando você executa ambos os aplicativos, o cliente envia mensagens que o servidor ecoa de volta, confirmando a comunicação entre processos entre dois processos de área de trabalho de confiança total sem nenhuma configuração especial necessária.

Registry

O uso do Registro para IPC geralmente não é recomendado, mas há suporte para código existente. Os aplicativos empacotados podem acessar somente as chaves do Registro que têm permissão para acessar.

Os aplicativos de desktop empacotados (consulte Criando um pacote MSIX a partir do seu código) usam a virtualização do Registro, de modo que as gravações globais no Registro fiquem contidas em uma ramificação privada dentro do pacote MSIX. Isso permite a compatibilidade do código-fonte minimizando o impacto global do registro e pode ser usado para IPC entre processos no mesmo pacote. Se você precisar usar o Registro, esse modelo será preferencial versus manipular o registro global.

RPC

O RPC pode ser usado para conectar um aplicativo empacotado a um ponto de extremidade win32 RPC, desde que o aplicativo empacotado tenha os recursos corretos para corresponder às ACLs no ponto de extremidade RPC.

As capacidades personalizadas permitem que OEMs e IHVs definam capacidades arbitrárias, apliquem ACLs a seus pontos de extremidade RPC com elas e, em seguida, concedam essas capacidades a aplicativos clientes autorizados. Para obter um aplicativo de exemplo completo, consulte o exemplo CustomCapability .

Os pontos de extremidade RPC também podem ter ACL aplicada a aplicativos empacotados específicos para limitar o acesso ao ponto de extremidade apenas a esses aplicativos, sem exigir a sobrecarga de gerenciamento de capacidades personalizadas. Você pode usar a API DeriveAppContainerSidFromAppContainerName para derivar um SID a partir de um nome de família de pacotes e, em seguida, aplicar uma ACL ao ponto de extremidade RPC com o SID, conforme mostrado no exemplo CustomCapability.

Memória compartilhada

O mapeamento de arquivo pode ser usado para compartilhar um arquivo ou memória entre dois ou mais processos com as seguintes restrições:

  • Por padrão, os mapeamentos de arquivos em aplicativos empacotados têm suporte apenas entre processos dentro do mesmo pacote, a menos que um processo seja de confiança total.
  • Os mapeamentos de arquivo podem ser compartilhados entre pacotes seguindo as diretrizes para compartilhar objetos nomeados.

SDK do Aplicativo Windows aplicativos da área de trabalho são executados como processos de confiança total, para que possam criar e usar mapeamentos de arquivos de memória compartilhados sem restrições. Ao se comunicar com outro aplicativo empacotado que não tenha total confiança, use a abordagem ACL descrita no compartilhamento de objetos nomeados.

A memória compartilhada é recomendada para compartilhar e manipular com eficiência grandes quantidades de dados.

Loopback

Loopback é o processo de comunicação com um servidor de rede escutando localhost (o endereço de loopback).

Para manter a segurança e o isolamento de rede, as conexões de loopback de IPC são bloqueadas por padrão para aplicativos empacotados. Você pode ativar conexões de loopback entre aplicativos empacotados confiáveis usando capacidades e propriedades do manifesto.

  • Todos os aplicativos empacotados que participam de conexões de loopback precisam declarar a privateNetworkClientServer funcionalidade em seus manifestos de pacote.
  • Dois aplicativos empacotados podem se comunicar por meio de loopback declarando LoopbackAccessRules em seus manifestos de pacote.
    • Cada aplicativo deve listar o outro em seu LoopbackAccessRules. O cliente declara uma regra "out" para o servidor, e o servidor declara regras "in" para seus clientes suportados.

Note

O nome da família de pacotes necessário para identificar um aplicativo nessas Regras pode ser encontrado por meio do editor de manifesto do pacote em Visual Studio durante o tempo de desenvolvimento, por meio do Partner Center para aplicativos publicados por meio do Microsoft Store ou por meio do comando Get-AppxPackage PowerShell para aplicativos que já estão instalados.

Aplicativos e serviços não empacotados não têm identidade de pacote, portanto, eles não podem ser declarados em LoopbackAccessRules. Você pode configurar um aplicativo empacotado para se conectar, via loopback, a aplicativos e serviços não empacotados por meio de CheckNetIsolation.exe; no entanto, isso só é possível em cenários de instalação por sideload ou de depuração, nos quais você tem acesso local ao computador e privilégios de administrador.

  • Se um aplicativo empacotado estiver se conectando a um aplicativo ou serviço não empacotado, execute CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> para adicionar uma isenção de loopback para o aplicativo empacotado.
  • Se um aplicativo ou serviço não empacotado estiver se conectando a um aplicativo empacotado, execute CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> para habilitar o aplicativo empacotado a receber conexões de loopback de entrada.
    • CheckNetIsolation.exe deve ser executado continuamente enquanto o aplicativo empacotado está escutando conexões.

Note

O nome da família de pacotes necessário para o parâmetro -n de CheckNetIsolation.exe pode ser encontrado por meio do editor de manifesto do pacote no Visual Studio durante o desenvolvimento, por meio do Partner Center para aplicativos publicados pela Microsoft Store ou por meio do comando do PowerShell Get-AppxPackage para aplicativos que já estão instalados.

Escolhendo um mecanismo de IPC

A tabela a seguir resume os mecanismos de IPC e seus melhores casos de uso:

Mecanismo Mais adequado para Requirements
Serviços de aplicativo Pequena troca de dados com property bags Aplicativo empacotado com a identidade do pacote
COM Componentes reutilizáveis, camadas de automação Nenhum (Win32) ou manifesto do pacote (COM empacotado)
Pipes nomeados Comunicação bidirecional baseada em fluxo Nenhum para aplicativos de confiança total
Memória compartilhada Dados grandes, alto desempenho Nenhum para aplicativos de confiança total
RPC Programas de cliente/servidor distribuídos As ACLs devem permitir o acesso
Registry Compatibilidade de código herdado Não recomendado para código novo
Loopback Protocolos baseados em rede (TCP/UDP) privateNetworkClientServer funcionalidade para aplicativos empacotados

Conteúdo relacionado

  • Last updated on