다음을 통해 공유

프로세스 간 통신(IPC)

  • 아티클

이 항목에서는 UWP(유니버설 Windows 플랫폼) 애플리케이션과 Win32 애플리케이션 간에 IPC(프로세스 간 통신)를 수행하는 다양한 방법에 대해 설명합니다.

App Services

앱 서비스를 사용하면 애플리케이션에서 기본 형식의 속성 백(ValueSet)을 백그라운드에서 수락하고 반환하는 서비스를 노출할 수 있습니다. 서식 있는 개체는 직렬화되면 전달할 수 있습니다.

앱 서비스는 Out-of-Process에서 백그라운드 작업으로 또는 포그라운드 애플리케이션 내에서 In-Process로 실행할 수 있습니다.

App 서비스는 거의 실시간 대기 시간이 필요 없는 소량의 데이터를 공유하는 데 가장 적합합니다.

COM:

COM은 상호 작용 및 통신이 가능한 이진 소프트웨어 구성 요소를 만드는 데 사용되는 분산 개체 지향 시스템입니다. 개발자는 COM을 사용하여 애플리케이션을 위한 재사용 가능한 소프트웨어 구성 요소 및 자동화 계층을 만듭니다. COM 구성 요소는 In-Process 또는 Out-of-Process이며, 클라이언트 및 서버 모델을 통해 통신할 수 있습니다. Out-of-Process COM 서버는 오래전부터 개체 간 통신 수단으로 사용되었습니다.

runFullTrust 기능이 있는 패키지된 애플리케이션은 패키지 매니페스트를 통해 Out-of-Process COM 서버를 IPC에 등록할 수 있습니다. 이를 패키지된 COM이라고 합니다.

파일 시스템

BroadFileSystemAccess

패키지된 애플리케이션은 broadFileSystemAccess 제한된 기능을 선언함으로써 광범위한 파일 시스템을 사용하여 IPC를 수행할 수 있습니다. 이 기능은 Windows.Storage API 및 xxxFromApp Win32 API에 광범위한 파일 시스템 액세스 권한을 부여합니다.

기본적으로 파일 시스템을 통해 패키지된 애플리케이션에 사용되는 IPC는 이 섹션에 설명된 다른 메커니즘으로 제한됩니다.

PublisherCacheFolder

PublisherCacheFolder를 사용하면 패키지된 애플리케이션은 매니페스트에 동일한 게시자가 다른 패키지와 공유할 수 있는 폴더를 선언할 수 있습니다.

공유 스토리지 폴더에는 다음과 같은 요구 사항 및 제한 사항이 있습니다.

  • 공유 스토리지 폴더의 데이터는 백업되거나 로밍되지 않습니다.
  • 사용자가 공유 스토리지 폴더의 내용을 지울 수 있습니다.
  • 공유 스토리지 폴더를 사용하여 다른 게시자의 애플리케이션 간에 데이터를 공유할 수 없습니다.
  • 공유 스토리지 폴더를 사용하여 서로 다른 사용자 간에 데이터를 공유할 수 없습니다.
  • 공유 스토리지 폴더에는 버전 관리가 없습니다.

여러 애플리케이션을 게시하고 애플리케이션 간에 데이터를 공유하는 간단한 메커니즘을 찾고 있는 경우 간단한 파일 시스템 기반 옵션인 PublisherCacheFolder가 제격입니다.

SharedAccessStorageManager

SharedAccessStorageManager는 앱 서비스, 프로토콜 활성화(예: LaunchUriForResultsAsync) 등과 함께 토큰을 통해 StorageFiles을 공유하는 데 사용됩니다.

FullTrustProcessLauncher

runFullTrust 기능이 있는 패키지된 애플리케이션은 동일한 패키지 내에서 완전 신뢰 프로세스를 시작할 수 있습니다.

패키지 제한이 부담스럽거나 IPC 옵션이 부족한 경우 애플리케이션에서 완전 신뢰 프로세스를 프록시로 사용하여 시스템과 상호 작용한 다음, 앱 서비스 또는 잘 지원되는 기타 IPC 메커니즘을 통해 완전 신뢰 프로세스 자체와 함께 IPC를 사용할 수 있습니다.

LaunchUriForResultsAsync

LaunchUriForResultsAsync는 ProtocolForResults 활성화 계약을 구현하는 다른 패키지된 애플리케이션과의 단순(ValueSet) 데이터 교환에 사용됩니다. 일반적으로 백그라운드에서 실행되는 앱 서비스와 달리, 대상 애플리케이션은 포그라운드에서 시작됩니다.

ValueSet를 통해 SharedStorageAccessManager 토큰을 애플리케이션에 전달하여 파일을 공유할 수 있습니다.

루프백

루프백은 localhost(루프백 주소)에서 수신 대기하는 네트워크 서버와 통신하는 프로세스입니다.

보안 및 네트워크 격리를 유지하기 위해, 패키지된 애플리케이션은 IPC에 대한 루프백 연결이 기본적으로 차단됩니다. 기능 및 매니페스트 속성을 사용하여 신뢰할 수 있는 패키지된 애플리케이션 중에 루프백 연결을 사용하도록 설정할 수 있습니다.

  • 루프백 연결에 참여하는 모든 패키지된 애플리케이션은 패키지 매니페스트에서 privateNetworkClientServer 기능을 선언해야 합니다.
  • 2개의 패키지된 애플리케이션은 패키지 매니페스트 내에서 LoopbackAccessRules를 선언하여 루프백을 통해 통신할 수 있습니다.
    • 각 애플리케이션은 LoopbackAccessRules에 다른 애플리케이션을 나열해야 합니다. 클라이언트는 서버에 대해 "out" 규칙을 선언하고, 서버는 지원되는 클라이언트에 대해 "in" 규칙을 선언합니다.

참고 항목

이러한 규칙에서 애플리케이션을 식별하는 데 필요한 패키지 패밀리 이름은 개발 중에 Visual Studio에서 패키지 매니페스트 편집기를 통해, Microsoft Store를 통해 게시된 애플리케이션의 파트너 센터를 통해 또는 이미 설치된 애플리케이션에 대한 Get-AppxPackage PowerShell 명령을 통해 찾을 수 있습니다.

패키지되지 않은 애플리케이션과 서비스는 패키지 ID가 없으므로 LoopbackAccessRules에서 선언할 수 없습니다. 패키지된 애플리케이션이 패키지되지 않은 애플리케이션 및 서비스와 루프백을 통해 연결하도록 CheckNetIsolation.exe에서 구성할 수 있지만, 이는 머신에 대한 로컬 액세스 권한이 있고 관리자 권한이 있는 테스트용 로드 또는 디버깅 시나리오에서만 가능합니다.

  • 루프백 연결에 참여하는 모든 패키지된 애플리케이션은 패키지 매니페스트에서 privateNetworkClientServer 기능을 선언해야 합니다.
  • 패키지된 애플리케이션이 패키지되지 않은 애플리케이션 또는 서비스에 연결하는 경우 CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME>을 실행하여 패키지된 애플리케이션에 대한 루프백 예외를 추가합니다.
  • 패키지되지 않은 애플리케이션 또는 서비스가 패키지된 애플리케이션에 연결하는 경우 CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME>을 실행하여 패키지된 애플리케이션이 인바운드 루프백 연결을 받을 수 있도록 합니다.
    • CheckNetIsolation.exe는 패키지된 애플리케이션이 연결을 수신 대기하는 동안 지속적으로 실행되어야 합니다.
    • -is 플래그는 Windows 10 버전 1607(10.0, 빌드 14393)에서 도입되었습니다.

참고 항목

CheckNetIsolation.exe의 -n 플래그에 필요한 패키지 패밀리 이름은 개발 중에 Visual Studio에서 패키지 매니페스트 편집기를 통해, Microsoft Store를 통해 게시된 애플리케이션의 파트너 센터를 통해 또는 이미 설치된 애플리케이션에 대한 Get-AppxPackage PowerShell 명령을 통해 찾을 수 있습니다.

CheckNetIsolation.exe는 네트워크 격리 문제를 디버깅하는 데에도 유용합니다.

파이프

파이프를 사용하면 파이프 서버와 하나 이상의 파이프 클라이언트 간에 간단한 통신을 수행할 수 있습니다.

익명 파이프 및 명명된 파이프가 지원되며 다음과 같은 제약이 있습니다.

  • 기본적으로 패키지된 애플리케이션의 명명된 파이프는 완전 신뢰 프로세스가 아닌 한 동일한 패키지 내의 프로세스 간에만 지원됩니다.
  • 명명된 개체 공유에 대한 지침에 따라 패키지 간에 명명된 파이프를 공유할 수 있습니다.
  • 명명된 파이프(패키지된 및 패키지되지 않은 앱 내)는 파이프 이름에 해당하는 구문 \\.\pipe\LOCAL\을 사용해야 합니다.

등록

IPC에 레지스트리를 사용하는 것은 일반적으로 권장하지 않지만, 기존 코드를 위해 지원됩니다. 패키지된 애플리케이션은 액세스 권한이 있는 레지스트리 키에만 액세스할 수 있습니다.

일반적으로 패키지된 데스크톱 앱(코드에서 MSIX 패키지 빌드 참조)은 전역 레지스트리 쓰기가 MSIX 패키지 내 프라이빗 하이브에 포함되도록 레지스트리 가상화를 활용합니다. 이렇게 하면 전역 레지스트리에 미치는 영향을 최소화하면서 소스 코드 호환성을 유지할 수 있으며, 동일한 패키지의 프로세스 간 IPC에 사용할 수 있습니다. 레지스트리를 꼭 사용해야 하는 경우 전역 레지스트리를 조작하는 방법보다 이 모델이 더 좋습니다.

RPC

패키지된 애플리케이션에 RPC 엔드포인트의 ACL과 일치하는 올바른 기능이 있는 경우 RPC를 사용하여 패키지된 애플리케이션을 Win32 RPC 엔드포인트에 연결할 수 있습니다.

사용자 지정 기능을 사용하면 OEM 및 IHV가 임의의 기능을 정의하고, 이러한 기능을 사용하여 RPC 엔드포인트에 대한 ACL을 수행한 다음, 권한 있는 클라이언트 애플리케이션에 이러한 기능을 부여할 수 있습니다. 전체 샘플 애플리케이션은 CustomCapability를 참조하세요.

사용자 지정 기능의 관리 오버헤드를 요구하지 않고 RPC 엔드포인트를 특정 패키지된 애플리케이션으로 ACL하여 엔드포인트에 대한 액세스를 해당 애플리케이션으로 제한할 수도 있습니다. DeriveAppContainerSidFromAppContainerName API를 사용하여 패키지 패밀리 이름에서 SID를 파생한 다음, CustomCapability 샘플의 설명처럼 SID를 사용하여 RPC 엔드포인트에 대한 ACL을 수행할 수 있습니다.

공유 메모리

파일 매핑을 사용하여 2개 이상의 프로세스 간에 파일 또는 메모리를 공유할 수 있으며 다음과 같은 제약이 있습니다.

  • 기본적으로 패키지된 애플리케이션의 파일 매핑은 완전 신뢰 프로세스가 아닌 한 동일한 패키지 내의 프로세스 간에만 지원됩니다.
  • 명명된 개체 공유에 대한 지침에 따라 패키지 간에 파일 매핑을 공유할 수 있습니다.

공유 메모리는 대량의 데이터를 효율적으로 공유하고 조작하는 데 좋습니다.