Communicatie tussen processen (IPC)

In dit onderwerp worden verschillende manieren uitgelegd om interprocescommunicatie (IPC) uit te voeren tussen UWP-toepassingen (Universal Windows Platform) en Win32-toepassingen.

App-diensten

Met App Services kunnen toepassingen services blootleggen die eigenschappentassen van primitieve gegevens (ValueSet) op de achtergrond accepteren en teruggeven. Rijke objecten kunnen worden doorgegeven als ze worden geserialiseerd.

App-services kunnen draaien buiten het proces als een achtergrondtaak, of in hetzelfde proces binnen de app 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 softwarecomponenten die kunnen communiceren en interageren. 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 zijn al lang gebruikt als een middel voor communicatie tussen objecten.

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

Bestandssysteem

BroadFileSystemAccess

Verpakte toepassingen kunnen IPC uitvoeren met behulp van het brede bestandssysteem door de beperkte functie broadFileSystemAccess te declareren. Deze mogelijkheid verleent Windows.Storage-API's en xxxFromApp Win32-API's toegang tot het brede 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:

• Gegevens in de gedeelde opslagmap worden niet geback-upt of gesynchroniseerd.
• 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.

SharedAccessStorageManager

SharedAccessStorageManager wordt gebruikt in combinatie met App-services, protocolactivering (bijvoorbeeld LaunchUriForResultsAsync), enzovoort, om StorageFiles te delen via tokens.

FullTrustProcessLauncher

Met de runFullTrust-mogelijkheid kunnen verpakte toepassingen processen voor volledig vertrouwen binnen hetzelfde pakket starten.

Voor scenario's waarbij pakketbeperkingen een last zijn, of IPC-opties ontbreken, kan een toepassing een volledig vertrouwensproces als proxy gebruiken om te communiceren met het systeem en vervolgens IPC met het volledige vertrouwensproces zelf via App-services of een ander goed ondersteund IPC-mechanisme.

LaunchUriForResultsAsync

LaunchUriForResultsAsync wordt gebruikt voor eenvoudige gegevensuitwisseling (ValueSet) met andere verpakte toepassingen die het ProtocolForResults-activeringscontract implementeren. In tegenstelling tot App Services, die doorgaans op de achtergrond worden uitgevoerd, wordt de doeltoepassing op de voorgrond gestart.

Bestanden kunnen worden gedeeld door SharedStorageAccessManager-tokens door te geven aan de toepassing via de ValueSet.

Loopback

Loopback is het proces van communicatie met een netwerkserver die luistert op localhost (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.

Opmerking

De familienaam van het pakket die is vereist om een toepassing in deze regels te identificeren, vindt u via de manifesteditor van het pakket in Visual Studio tijdens de ontwikkeling, via partnercentrum voor toepassingen die zijn gepubliceerd via de Microsoft Store of via de Opdracht Get-AppxPackage PowerShell voor toepassingen die al zijn geïnstalleerd.

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.

• Alle verpakte toepassingen die deelnemen aan loopback-verbindingen moeten de privateNetworkClientServer mogelijkheid in hun pakketmanifesten declareren.
• Als een verpakte toepassing verbinding maakt met een uitgepakte toepassing of service, voert u CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> uit 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 CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> uit 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.
  • De -is vlag is geïntroduceerd in Windows 10, versie 1607 (10.0; Build 14393).

Opmerking

De familienaam van het pakket die is vereist voor de -n vlag van CheckNetIsolation.exe kunt u vinden via de manifesteditor van het pakket in Visual Studio tijdens de ontwikkeling, via partnercentrum voor toepassingen die zijn gepubliceerd via de Microsoft Store of via de Opdracht Get-AppxPackage PowerShell voor toepassingen die al zijn geïnstalleerd.

CheckNetIsolation.exe is ook handig voor het opsporen van problemen met netwerkisolatie.

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 volledige vertrouwensrechten heeft.
• Benoemde pijpen kunnen worden gedeeld tussen pakketten volgens de richtlijnen voor het delen van benoemde objecten.
• Benoemde pijpen (in verpakte en uitgepakte apps) moeten de syntaxis gebruiken voor de pijpnaam.

Registersysteem

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.

Gewoonlijk maken verpakte bureaublad-apps (zie Een MSIX-pakket bouwen vanuit uw code) 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 capabilities kunnen OEM's en IHD's willekeurige capabilities definiëren, ACL toepassen op hun RPC-eindpunten, en die capabilities vervolgens verlenen 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 API DeriveAppContainerSidFromAppContainerName gebruiken om een SID af te leiden van een pakketfamilienaam, en vervolgens het RPC-eindpunt met de SID ACL'en zoals getoond in het voorbeeld CustomCapability.

Gedeeld geheugen

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

• In verpakte toepassingen worden bestandskoppelingen standaard alleen ondersteund tussen processen binnen hetzelfde pakket, tenzij het proces volledig vertrouwen heeft.
• Bestandstoewijzingen kunnen worden gedeeld tussen pakketten volgens de richtlijnen voor het delen van benoemde objecten .

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