Komunikace mezi procesy (IPC)

Toto téma vysvětluje různé způsoby provádění komunikace mezi procesy (IPC) mezi Windows App SDK desktopovými aplikacemi a jinými aplikacemi Win32. Vzhledem k tomu, že Windows App SDK desktopové aplikace běží jako plně důvěryhodné procesy Win32, mají přímý přístup ke všem mechanismům IPC na úrovni operačního systému. Některé mechanismy mají další požadavky, pokud jsou aplikace zabalené pomocí MSIX, jak je uvedeno v následujících částech.

Služby aplikací

App Services umožňují aplikacím zveřejnit služby, které přijímají a vracejí kontejnery vlastností primitiv (ValueSet) na pozadí. Objekty s komplexní strukturou lze předávat, pokud jsou serializovány.

Služby App Services můžou běžet mimo proces jako úlohu na pozadí nebo v procesu v rámci aplikace na popředí.

Note

Služba App Services vyžaduje zabalenou aplikaci s identitou balíčku. Jsou dostupné pro Windows App SDK aplikace, které používají balení MSIX.

Služby aplikací se nejlépe hodí ke sdílení menších objemů dat tam, kde není vyžadována téměř okamžitá odezva.

model COM

COM je distribuovaný objektově orientovaný systém pro vytváření binárních softwarových komponent, které mohou interagovat a komunikovat. Jako vývojář používáte com k vytváření opakovaně použitelných softwarových komponent a vrstev automatizace pro aplikaci. Komponenty modelu COM můžou být v procesu nebo mimo proces a můžou komunikovat prostřednictvím modelu klienta a serveru . Servery COM mimo proces se již dlouho používají jako prostředek k komunikaci mezi objekty.

Aplikace v balíčku s oprávněním runFullTrust mohou prostřednictvím manifestu balíčku registrovat COM servery mimo proces pro IPC. To se označuje jako Packaged COM.

Windows App SDK desktopové aplikace běží jako plně důvěryhodné procesy, takže můžou také zaregistrovat a používat servery COM přímo prostřednictvím Windows Registry, stejně jako tradiční aplikace Win32.

Filesystem

BroadFileSystemAccess

Zabalené aplikace mohou provádět IPC pomocí rozsáhlého systému souborů deklarováním broadFileSystemAccess omezené schopnosti. Tato funkce uděluje rozhraním API Windows.Storage a Win32 FromApp API přístup k širokému systému souborů.

Ve výchozím nastavení je IPC prostřednictvím systému souborů pro zabalené aplikace omezen na ostatní mechanismy popsané v této části.

PublisherCacheFolder

PublisherCacheFolder umožňuje zabaleným aplikacím deklarovat složky v manifestu, které mohou být sdíleny s jinými balíčky stejného vydavatele.

Složka sdíleného úložiště má následující požadavky a omezení:

  • Data ve složce sdíleného úložiště se nezálohují ani nepřesunou.
  • Uživatel může vymazat obsah sdílené složky úložiště.
  • Sdílenou složku úložiště nemůžete použít ke sdílení dat mezi aplikacemi od různých vydavatelů.
  • Sdílenou složku úložiště nemůžete použít ke sdílení dat mezi různými uživateli.
  • Složka sdíleného úložiště nemá správu verzí.

Pokud publikujete více aplikací a hledáte jednoduchý mechanismus pro sdílení dat mezi nimi, pak publisherCacheFolder je jednoduchá možnost založená na systému souborů.

Potrubí

Kanály umožňují jednoduchou komunikaci mezi serverem kanálu a jedním nebo více klienty kanálu.

Anonymní kanály a pojmenované kanály jsou podporovány s následujícími omezeními:

  • Ve výchozím nastavení jsou pojmenované kanály v aplikacích v balíčku podporovány pouze mezi procesy v rámci stejného balíčku, pokud některý z procesů není spuštěn s úplnou důvěrou.
  • Pojmenované kanály je možné sdílet mezi balíčky podle pokynů pro sdílení pojmenovaných objektů.
  • Pojmenované kanály v zabalených aplikacích by měly obsahovat LOCAL\ název kanálu (například \\.\pipe\LOCAL\<pipename>). Segment LOCAL\ rozděluje kanál do přihlašovací relace volajícího a vyžaduje se pro aplikace zabalené pomocí MSIX. Při použití rozhraní API .NET, jako je NamedPipeServerStream, předejte pouze část LOCAL\<pipename> – předpona \\.\pipe\ se zpracovává interně.

Desktopové aplikace Windows App SDK běží jako procesy s úplnou důvěrou, a proto mohou vytvářet a používat pojmenované kanály bez omezení na stejný balíček. Pokud ale komunikujete s jinou balíčkovanou aplikací, která nemá plnou důvěru, platí výše uvedená omezení.

Příklad pojmenované roury (C#)

Následující příklad ukazuje kompletní pojmenovaný kanálový server a klient jako dvě konzolové aplikace. Vzhledem k tomu, že Windows App SDK desktopové aplikace jsou procesy plné důvěryhodnosti, pojmenovaný kanál IPC funguje bez jakýchkoli zvláštních schopností nebo položek manifestu.

Pokud chcete tento příklad vyzkoušet, vytvořte dva projekty konzolové aplikace (cílené na net8.0-windows se zapnutým ImplicitUsings) a nejprve spusťte server, potom v samostatném terminálu klienta.

Server pojmenované roury — vytvoří pojmenovanou rouru a odesílá zprávy zpět klientovi:

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

Klient roury — připojuje se k serveru a odesílá uživatelský vstup:

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

Když spustíte obě aplikace, klient odešle zprávy, které server vrátí zpět, a potvrdí komunikaci mezi dvěma plně důvěryhodnými desktopovými procesy bez nutnosti zvláštní konfigurace.

Registry

Použití registru pro IPC se obecně nedoporučuje, ale podporuje se pro stávající kód. Zabalené aplikace mají přístup pouze ke klíčům registru, ke kterým mají oprávnění k přístupu.

Zabalené desktopové aplikace (viz Sestavení balíčku MSIX z kódu) využívají virtualizaci registru , aby globální zápisy registru byly obsaženy do privátního podregistru v rámci balíčku MSIX. To umožňuje kompatibilitu zdrojového kódu při minimalizaci dopadu globálního registru a lze ji použít pro IPC mezi procesy ve stejném balíčku. Pokud musíte použít registr, je tento model upřednostňován před manipulací s globálním registrem.

protokol RPC

Rpc se dá použít k připojení zabalené aplikace ke koncovému bodu RPC win32 za předpokladu, že zabalená aplikace má správné funkce odpovídající seznamům ACL v koncovém bodu RPC.

Vlastní oprávnění umožňují výrobcům OEM a IHV definovat libovolná oprávnění, nastavit pomocí nich seznamy ACL u svých koncových bodů RPC a poté udělit tato oprávnění autorizovaným klientským aplikacím. Úplnou ukázkovou aplikaci najdete v ukázce CustomCapability .

Koncové body RPC lze také pomocí ACL omezit na konkrétní balíčkované aplikace, takže přístup ke koncovému bodu budou mít pouze tyto aplikace, aniž by bylo nutné spravovat vlastní oprávnění. Rozhraní API DeriveAppContainerSidFromAppContainerName můžete použít k odvození identifikátoru SID z názvu rodiny balíčku a potom nastavit seznam ACL koncového bodu RPC pomocí tohoto identifikátoru SID, jak je znázorněno v ukázce CustomCapability.

Sdílená paměť

Mapování souborů lze použít ke sdílení souboru nebo paměti mezi dvěma nebo více procesy s následujícími omezeními:

  • Ve výchozím nastavení je mapování souborů v aplikacích v balíčku podporováno pouze mezi procesy v rámci stejného balíčku, pokud proces neběží s plnou důvěrou.
  • Mapování souborů je možné sdílet mezi balíčky podle pokynů pro sdílení pojmenovaných objektů.

Windows App SDK desktopové aplikace běží jako procesy plné důvěryhodnosti, aby mohly vytvářet a používat mapování souborů sdílené paměti bez omezení. Při komunikaci s jinou balíčkovanou aplikací, která nemá plnou důvěru, použijte přístup ACL popsaný v části sdílení pojmenovaných objektů.

Sdílená paměť se doporučuje pro efektivní sdílení a manipulaci s velkými objemy dat.

Loopback

Zpětná smyčka je proces komunikace se síťovým serverem, který naslouchá na localhostu (adresa zpětné smyčky).

V zájmu zachování zabezpečení a izolace sítě jsou připojení zpětné smyčky pro IPC u balíčkových aplikací ve výchozím nastavení blokována. Připojení typu loopback mezi důvěryhodnými zabalenými aplikacemi můžete povolit pomocí oprávnění a vlastností manifestu.

  • Všechny aplikace v balíčku, které používají připojení zpětné smyčky, musí v manifestech balíčků aplikací deklarovat schopnost privateNetworkClientServer.
  • Dvě balíčkové aplikace mohou komunikovat přes loopback deklarováním LoopbackAccessRules v manifestech svých balíčků.
    • Každá aplikace musí mít tu druhou uvedenou ve svých LoopbackAccessRules. Klient deklaruje pravidlo "out" pro server a server deklaruje pravidla "in" pro své podporované klienty.

Note

Název rodiny balíčků potřebný k identifikaci aplikace v těchto pravidlech najdete prostřednictvím editoru manifestu balíčku v Visual Studio během vývoje, prostřednictvím Partnerského centra pro aplikace publikované prostřednictvím Microsoft Store nebo pomocí příkazu Get-AppxPackage PowerShellu pro aplikace, které jsou již nainstalované.

Rozbalené aplikace a služby nemají identitu balíčku, takže je nejde deklarovat ve smyčce LoopbackAccessRules. Balíčkovanou aplikaci můžete nakonfigurovat tak, aby navázala připojení přes loopback k nebalíčkovaným aplikacím a službám pomocí nástroje CheckNetIsolation.exe, to je však možné pouze ve scénářích bočního načítání nebo ladění, kdy máte lokální přístup k počítači a oprávnění správce.

  • Pokud se aplikace v balíčku připojuje k aplikaci nebo službě bez balíčku, spusťte příkaz CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME>, aby se pro aplikaci v balíčku přidala výjimka pro zpětnou adresu.
  • Pokud se nebalená aplikace nebo služba připojuje k balené aplikaci, spusťte příkaz CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME>, aby balená aplikace mohla přijímat příchozí připojení zpětné smyčky.
    • CheckNetIsolation.exe musí běžet nepřetržitě, zatímco balíčkovaná aplikace naslouchá příchozím připojením.

Note

Název rodiny balíčků vyžadovaný příznakem -nCheckNetIsolation.exe najdete v editoru manifestu balíčku v Visual Studio během vývoje, prostřednictvím Partnerského centra pro aplikace publikované prostřednictvím Microsoft Store nebo pomocí příkazu Get-AppxPackage PowerShellu pro aplikace, které jsou už nainstalované.

Volba mechanismu IPC

Následující tabulka shrnuje mechanismy IPC a jejich nejlepší případy použití:

Mechanismus Nejvhodnější pro Requirements
Služby aplikací Výměna malého objemu dat pomocí vaků vlastností Zabalená aplikace s identitou balíčku
model COM Opakovaně použitelné komponenty, automatizační vrstvy Žádný (Win32) nebo manifest balíčku (Packaged COM)
Pojmenované kanály Obousměrná komunikace založená na streamu Žádné pro plně důvěryhodné aplikace
Sdílená paměť Velké objemy dat, vysoký výkon Není k dispozici pro plně důvěryhodné aplikace
protokol RPC Distribuované klientské/serverové programy ACL musí umožňovat přístup
Registry Kompatibilita starších verzí kódu Nedoporučuje se pro nový kód
Loopback Síťové protokoly (TCP/UDP) privateNetworkClientServer schopnost pro balíčkované aplikace

Související obsah

  • Last updated on