Communicatie tussen processen (IPC)

In dit onderwerp worden verschillende manieren uitgelegd om interprocescommunicatie (IPC) uit te voeren tussen Windows App SDK desktop-apps en andere Win32-toepassingen. Omdat Windows App SDK desktop-apps worden uitgevoerd als volledig vertrouwde Win32-processen, hebben ze directe toegang tot alle IPC-mechanismen op besturingssysteemniveau. Sommige mechanismen hebben aanvullende vereisten wanneer apps zijn verpakt met MSIX, zoals vermeld in de onderstaande secties.

App-diensten

Met App Services kunnen toepassingen services beschikbaar maken die eigenschappentassen van primitieven (ValueSet) op de achtergrond accepteren en retourneren. Complexe objecten kunnen worden doorgegeven als ze geserialiseerd zijn.

App-services kunnen ofwel buiten het proces worden uitgevoerd als achtergrondtaak, of binnen het proces in de toepassing op de voorgrond.

App-services kunnen het beste worden gebruikt voor het delen van kleine hoeveelheden gegevens, waarbij bijna realtime latentie niet is vereist.

COM

COM is een gedistribueerd objectgeoriënteerd systeem voor het maken van binaire softwareonderdelen die kunnen interageren en communiceren. Als ontwikkelaar gebruikt u COM om herbruikbare softwareonderdelen en automatiseringslagen voor een toepassing te maken. COM-onderdelen kunnen worden verwerkt of niet verwerkt en ze kunnen communiceren via een client- en servermodel . Out-of-process COM-servers worden al lange tijd gebruikt als middel voor communicatie tussen objecten.

Verpakte toepassingen met de runFullTrust mogelijkheid kunnen COM-servers voor IPC buiten het proces registreren via het pakketmanifest. Dit staat bekend als Packaged COM.

Windows App SDK desktop-apps worden uitgevoerd als processen voor volledig vertrouwen, zodat ze com-servers ook rechtstreeks kunnen registreren en gebruiken via het Windows Registry, net als traditionele Win32-toepassingen.

Filesystem

BroadFileSystemAccess

Verpakte toepassingen kunnen IPC uitvoeren met behulp van het brede bestandssysteem door de broadFileSystemAccess beperkte mogelijkheid te declareren. Deze mogelijkheid geeft Windows.Storage-API's en Win32 FromApp-API's toegang tot het volledige bestandssysteem.

Standaard is IPC via het bestandssysteem voor verpakte toepassingen beperkt tot de andere mechanismen die in deze sectie worden beschreven.

PublisherCacheFolder

Met PublisherCacheFolder kunnen verpakte toepassingen mappen declareren in hun manifest die kunnen worden gedeeld met andere pakketten door dezelfde uitgever.

De map met gedeelde opslag heeft de volgende vereisten en beperkingen:

• Er wordt geen back-up gemaakt van de gegevens in de gedeelde opslagmap en deze worden niet gesynchroniseerd tussen apparaten.
• De gebruiker kan de inhoud van de gedeelde opslagmap wissen.
• U kunt de gedeelde opslagmap niet gebruiken om gegevens te delen tussen toepassingen van verschillende uitgevers.
• U kunt de gedeelde opslagmap niet gebruiken om gegevens te delen tussen verschillende gebruikers.
• De gedeelde opslagmap heeft geen versiebeheer.

Als u meerdere toepassingen publiceert en u op zoek bent naar een eenvoudig mechanisme om gegevens tussen deze toepassingen te delen, is publisherCacheFolder een eenvoudige optie op basis van een bestandssysteem.

Pijpen

Pijpen maken eenvoudige communicatie mogelijk tussen een pijpserver en een of meer pijpclients.

Anonieme pijpen en benoemde pijpen worden ondersteund met de volgende beperkingen:

• Benoemde pijpen in verpakte toepassingen worden standaard alleen ondersteund tussen processen binnen hetzelfde pakket, tenzij een proces volledig vertrouwen heeft.
• Benoemde pijpen kunnen worden gedeeld tussen pakketten volgens de richtlijnen voor het delen van benoemde objecten.
• Named pipes in verpakte apps moeten LOCAL\ in de naam van de pipe bevatten (bijvoorbeeld \\.\pipe\LOCAL\<pipename>). Het LOCAL\-segment beperkt de pipe tot de aanmeldingssessie van de aanroeper en is vereist voor apps die als MSIX zijn verpakt. Wanneer u .NET-API's zoals NamedPipeServerStream gebruikt, geeft u alleen het gedeelte LOCAL\<pipename> door — het voorvoegsel \\.\pipe\ wordt intern afgehandeld.

Windows App SDK-desktopapps worden uitgevoerd als processen met volledig vertrouwen, zodat ze named pipes kunnen maken en gebruiken zonder de beperking dat ze zich in hetzelfde pakket moeten bevinden. Als u echter communiceert met een andere verpakte app die niet volledig vertrouwd is, zijn de bovenstaande beperkingen nog steeds van toepassing.

Voorbeeld van benoemde pijp (C#)

In het volgende voorbeeld wordt een volledige named pipe-server en een client gedemonstreerd in de vorm van twee consoletoepassingen. Omdat desktop-apps van de Windows App SDK processen met volledig vertrouwen zijn, werkt IPC via named pipes zonder speciale bevoegdheden of manifestvermeldingen.

Als u dit voorbeeld wilt proberen, maakt u twee console-app-projecten (gericht net8.0-windows met ImplicitUsings ingeschakeld) en voert u eerst de server uit, vervolgens de client in een afzonderlijke terminal.

Pipe-server : maakt een benoemde pijp en echot berichten terug naar de client:

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

Pipe-client : maakt verbinding met de server en verzendt gebruikersinvoer:

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

Wanneer u beide toepassingen uitvoert, verzendt de client berichten die de server terugstuurt, waarmee interprocescommunicatie tussen twee volledig vertrouwde desktopprocessen wordt bevestigd zonder dat speciale configuratie vereist is.

Registry

Het registergebruik voor IPC wordt over het algemeen afgeraden, maar wordt ondersteund voor bestaande code. Verpakte toepassingen hebben alleen toegang tot registersleutels waartoe ze toegang hebben.

Verpakte bureaublad-apps (zie Een MSIX-pakket bouwen vanuit uw code) maken gebruik van registervirtualisatie , zodat globale schrijfbewerkingen van registers zijn opgenomen in een privé-hive in het MSIX-pakket. Hierdoor is broncodecompatibiliteit mogelijk terwijl de impact van het globale register wordt geminimaliseerd en kan worden gebruikt voor IPC tussen processen in hetzelfde pakket. Als u het register moet gebruiken, heeft dit model de voorkeur ten opzichte van het bewerken van het globale register.

RPC

RPC kan worden gebruikt om een verpakte toepassing te verbinden met een Win32 RPC-eindpunt, mits de verpakte toepassing de juiste mogelijkheden heeft om de ACL's op het RPC-eindpunt te vinden.

Met aangepaste mogelijkheden kunnen OEM's en IHV's willekeurige mogelijkheden definiëren, hun RPC-eindpunten hiermee beveiligen met ACL's en vervolgens die mogelijkheden toekennen aan geautoriseerde clienttoepassingen. Zie het voorbeeld CustomCapability voor een volledige voorbeeldtoepassing.

RPC-eindpunten kunnen ook worden gekoppeld aan specifieke verpakte toepassingen om de toegang tot het eindpunt te beperken tot alleen die toepassingen zonder dat hiervoor de beheeroverhead van aangepaste mogelijkheden nodig is. U kunt de DeriveAppContainerSidFromAppContainerName-API gebruiken om een SID af te leiden uit een pakketfamilienaam en vervolgens een ACL op het RPC-eindpunt toe te passen met de SID, zoals weergegeven in het voorbeeld CustomCapability.

Gedeeld geheugen

Bestandskoppeling kan worden gebruikt om een bestand of geheugen te delen tussen twee of meer processen, met de volgende beperkingen:

• Bestandskoppelingen in verpakte toepassingen worden standaard alleen ondersteund tussen processen binnen hetzelfde pakket, tenzij een proces volledig vertrouwd is.
• Bestandstoewijzingen kunnen over pakketten heen worden gedeeld volgens de richtlijnen voor het delen van benoemde objecten.

Windows App SDK-desktop-apps worden uitgevoerd als processen met volledig vertrouwen, zodat ze bestandstoewijzingen van gedeeld geheugen kunnen maken en gebruiken zonder beperkingen. Wanneer u communiceert met een andere verpakte app die niet volledig vertrouwen heeft, gebruikt u de ACL-benadering die wordt beschreven in het delen van benoemde objecten.

Gedeeld geheugen wordt aanbevolen voor het efficiënt delen en bewerken van grote hoeveelheden gegevens.

Loopback

Loopback is het proces waarbij wordt gecommuniceerd met een netwerkserver die op localhost luistert (het loopback-adres).

Om de beveiliging en netwerkisolatie te behouden, worden loopback-verbindingen voor IPC standaard geblokkeerd voor verpakte toepassingen. U kunt loopback-verbindingen tussen vertrouwde verpakte toepassingen inschakelen met behulp van mogelijkheden en manifesteigenschappen.

• Alle verpakte toepassingen die deelnemen aan loopback-verbindingen moeten de privateNetworkClientServer mogelijkheid in hun pakketmanifesten declareren.
• Twee verpakte toepassingen kunnen communiceren via loopback door LoopbackAccessRules in hun pakketmanifesten te declareren.
  • Elke toepassing moet de andere in de LoopbackAccessRules vermelden. De client declareert een 'out'-regel voor de server en de server declareert 'in'-regels voor de ondersteunde clients.

Uitgepakte toepassingen en services hebben geen pakketidentiteit, zodat ze niet kunnen worden gedeclareerd in LoopbackAccessRules. U kunt een verpakte toepassing configureren om via loopback verbinding te maken met uitgepakte toepassingen en services via CheckNetIsolation.exe, maar dit is alleen mogelijk voor sideload- of foutopsporingsscenario's waarbij u lokale toegang tot de computer hebt en u beheerdersbevoegdheden hebt.

• Als een verpakte toepassing verbinding maakt met een uitgepakte toepassing of service, voert u de opdracht uit CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> om een loopback-uitzondering toe te voegen voor de verpakte toepassing.
• Als een uitgepakte toepassing of service verbinding maakt met een verpakte toepassing, voert u deze opdracht uit CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> om de verpakte toepassing in staat te stellen binnenkomende loopbackverbindingen te ontvangen.
  • CheckNetIsolation.exe moet continu worden uitgevoerd terwijl de verpakte toepassing luistert naar verbindingen.

Een IPC-mechanisme kiezen

De volgende tabel bevat een overzicht van de IPC-mechanismen en de beste gebruiksvoorbeelden:

Verwante onderwerpen

• Benoemde objecten delen
• Overzicht van Windows App SDK
• Overzicht van MSIX-pakketten