Komunikacja międzyprocesowa (IPC)

W tym temacie opisano różne sposoby przeprowadzania komunikacji międzyprocesowej (IPC) między aplikacjami platformy uniwersalnej systemu Windows (UWP) i aplikacjami Win32.

Usługi aplikacji

Usługi App Services umożliwiają aplikacjom udostępnianie usług, które akceptują i zwracają zbiory właściwości pierwotnych (ValueSet) w tle. Bogate obiekty można przekazać, jeśli są serializowane.

Usługi aplikacyjne mogą działać poza procesem jako zadanie w tle lub w procesie w aplikacji pracującej na pierwszym planie.

Najlepiej korzystać z usług App Services do udostępniania małych ilości danych, gdzie opóźnienie niemal w czasie rzeczywistym nie jest wymagane.

COM

com to rozproszony system obiektowy umożliwiający tworzenie binarnych składników oprogramowania, które mogą wchodzić w interakcje i komunikować się. Jako deweloper używasz modelu COM do tworzenia składników oprogramowania wielokrotnego użytku i warstw automatyzacji dla aplikacji. Komponenty COM mogą działać w procesie lub poza procesem i mogą komunikować się za pośrednictwem modelu klienta i serwera . Od dawna serwery COM poza procesem są używane jako środek do komunikacji między obiektami.

Spakowane aplikacje z funkcją runFullTrust mogą rejestrować serwery COM out-of-process dla IPC za pośrednictwem manifestu pakietu . Jest to nazywane spakowaneCOM.

System plików

SzerokiDostępDoSystemuPlików

Spakowane aplikacje mogą wykonywać operacje IPC przy użyciu szerokiego systemu plików, deklarując broadFileSystemAccess ograniczone możliwości. Ta funkcja udziela interfejsów API Windows.Storage i xxxFromApp interfejsów API Win32 do szerokiego systemu plików.

Domyślnie protokół IPC za pośrednictwem systemu plików dla spakowanych aplikacji jest ograniczony do innych mechanizmów opisanych w tej sekcji.

PublisherCacheFolder (Folder pamięci podręcznej wydawcy)

PublisherCacheFolder umożliwia spakowanym aplikacjom deklarowanie folderów w manifeście, które mogą być udostępniane innym pakietom przez tego samego wydawcę.

Folder udostępnionego przechowywania ma następujące wymagania i ograniczenia:

• Dane w folderze magazynu udostępnionego nie są kopiowane zapasowo ani synchronizowane.
• Użytkownik może wyczyścić zawartość folderu przechowywania udostępnionego.
• Nie można używać wspólnego folderu do wymiany danych między aplikacjami z różnych wydawców.
• Nie można użyć udostępnionego folderu magazynu do udostępniania danych między różnymi użytkownikami.
• Folder wspólnego przechowywania nie obsługuje zarządzania wersjami.

Jeśli publikujesz wiele aplikacji i szukasz prostego mechanizmu udostępniania danych między nimi, folder PublisherCacheFolder jest prostą opcją opartą na systemie plików.

Menedżer magazynowania współdzielonego dostępu

SharedAccessStorageManager jest używana w połączeniu z usługami App Services, aktywacjami protokołów (na przykład LaunchUriForResultsAsync) itp., aby udostępniać pliki StorageFiles za pośrednictwem tokenów.

FullTrustProcessLauncher (Uruchamianie procesów FullTrust)

Dzięki funkcjonalności runFullTrust spakowane aplikacje mogą uruchamiać procesy pełnego zaufania w ramach tego samego pakietu.

W przypadku scenariuszy, w których ograniczenia pakietów są obciążeniem lub brakuje opcji IPC, aplikacja może użyć procesu o pełnym zaufaniu jako serwera proxy do komunikacji z systemem, a następnie współpracy IPC z procesem o pełnym zaufaniu za pośrednictwem usług App Services lub innego dobrze obsługiwanego mechanizmu IPC.

LaunchUriForResultsAsync

LaunchUriForResultsAsync służy do prostego (ValueSet) wymiany danych z innymi spakowanymi aplikacjami, które implementują kontrakt aktywacji ProtocolForResults. W przeciwieństwie do usług App Services, które zwykle działają w tle, aplikacja docelowa jest uruchamiana na pierwszym planie.

Pliki można udostępniać, przekazując SharedStorageAccessManager tokeny do aplikacji za pośrednictwem elementu ValueSet.

Pętla zwrotna

Loopback to proces komunikowania się z serwerem sieciowym, który nasłuchuje na hoście lokalnym (adres loopback).

Aby zachować bezpieczeństwo i izolację sieci, połączenia sprzężenia zwrotnego dla IPC są domyślnie blokowane w przypadku aplikacji pakietowych. Można włączyć połączenia sprzężenia zwrotnego pomiędzy zaufanymi aplikacjami spakowanymi przy użyciu możliwości i właściwości manifestu .

• Wszystkie spakowane aplikacje biorące udział w połączeniach sprzężenia zwrotnego muszą zadeklarować umiejętność privateNetworkClientServer w swoich manifestach pakietów .
• Dwie spakowane aplikacje mogą komunikować się za pośrednictwem pętli zwrotnej, deklarując LoopbackAccessRules w manifestach pakietów.
  • Każda aplikacja musi wyświetlić drugą w LoopbackAccessRules. Klient deklaruje regułę "out" dla serwera, a serwer deklaruje reguły "in" dla obsługiwanych klientów.

Rozpakowane aplikacje i usługi nie mają tożsamości pakietu, więc nie można ich zadeklarować w LoopbackAccessRules. Można skonfigurować spakowaną aplikację, aby łączyła się poprzez pętlę zwrotną z rozpakowanymi aplikacjami i usługami poprzez CheckNetIsolation.exe, jednak jest to możliwe tylko w scenariuszach sideloading lub debugowania, w których masz lokalny dostęp do maszyny oraz uprawnienia administratora.

• Wszystkie spakowane aplikacje uczestniczące w połączeniach sprzężenia zwrotnego muszą zadeklarować możliwość privateNetworkClientServer w manifestach pakietów .
• Jeśli spakowana aplikacja łączy się z rozpakowaną aplikacją lub usługą, uruchom CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME>, aby dodać wykluczenie sprzężenia zwrotnego dla spakowanej aplikacji.
• Jeśli rozpakowana aplikacja lub usługa łączy się ze spakowaną aplikacją, uruchom CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME>, aby umożliwić spakowanej aplikacji odbieranie przychodzących połączeń w pętli zwrotnej.
  • CheckNetIsolation.exe musi działać w sposób ciągły, gdy spakowana aplikacja nasłuchuje połączeń.
  • Flaga -is została wprowadzona w systemie Windows 10 w wersji 1607 (10.0; Kompilacja 14393).

CheckNetIsolation.exe są również przydatne do rozwiązywania problemów z izolacją sieci.

Potoki

potoki umożliwiają prostą komunikację między serwerem potoku a co najmniej jednym klientem potoku.

potoki anonimowe i nazwane potoki są obsługiwane z następującymi ograniczeniami:

• Domyślnie nazwane potoki w spakowanych aplikacjach są obsługiwane tylko między procesami w ramach tego samego pakietu, chyba że proces jest pełen zaufania.
• Nazywane potoki mogą być udostępniane między pakietami zgodnie z wytycznymi dotyczącymi udostępniania nazwanych obiektów .
• Nazwane potoki (w spakowanych i rozpakowanych aplikacjach) muszą używać składni \\.\pipe\LOCAL\ nazwy potoku.

Rejestr

Użycie rejestru dla IPC jest zazwyczaj odradzane, ale zapewniona jest jego obsługa w przypadku istniejącego kodu. Spakowane aplikacje mogą uzyskiwać dostęp tylko do kluczy rejestru, do których mają uprawnienia dostępu.

Często pakowane aplikacje desktopowe (zobacz Tworzenie pakietu MSIX zkodu) korzystają z wirtualizacji rejestru, tak aby operacje zapisu w rejestrze globalnym były ograniczone do prywatnej przestrzeni wewnątrz pakietu MSIX. Umożliwia to zgodność kodu źródłowego przy jednoczesnym zminimalizowaniu wpływu rejestru globalnego i może służyć do obsługi protokołu IPC między procesami w tym samym pakiecie. Jeśli musisz użyć rejestru, ten model jest preferowany w porównaniu do manipulowania rejestrem globalnym.

RPC

RPC można użyć do połączenia spakowanej aplikacji z punktem końcowym RPC Win32, pod warunkiem, że spakowane aplikacje mają poprawne możliwości dopasowania list ACL w punkcie końcowym RPC.

Funkcje niestandardowe umożliwiają maszynom operacyjnym i wirtualnym maszynom wirtualnym definiowanie dowolnych możliwości, listy ACL punktów końcowych RPC z nimi, a następnie przyznać te możliwości autoryzowanym aplikacjom klienckim. Aby uzyskać pełną przykładową aplikację, zobacz przykład CustomCapability.

Punkty końcowe RPC mogą być również ACL-owane do konkretnych zapakowanych aplikacji, aby ograniczyć dostęp do punktu końcowego tylko do tych aplikacji bez konieczności obciążenia związanego z zarządzaniem niestandardowymi funkcjami. Możesz użyć interfejsu API DeriveAppContainerSidFromAppContainerName, aby wyprowadzić identyfikator SID z nazwy rodziny pakietów, a następnie ustawić ACL dla punktu końcowego RPC z tym identyfikatorem SID, jak pokazano w przykładzie CustomCapability.

Pamięć współdzielona

mapowanie plików może służyć do udostępniania pliku lub pamięci między co najmniej dwoma procesami z następującymi ograniczeniami:

• Domyślnie mapowania plików w spakowanych aplikacjach są obsługiwane tylko między procesami w ramach tego samego pakietu, chyba że proces ma pełne zaufanie.
• Mapowania plików można udostępniać w pakietach zgodnie z wytycznymi dotyczącymi udostępniania nazwanych obiektów.

Pamięć udostępniona jest zalecana do wydajnego udostępniania i manipulowania dużymi ilościami danych.