InterProcess Communications (IPC)

InterProcess Communications (IPC)

 

번역 : Codemuri

 

Microsoft Windows OS 는 애플리케이션간에 커뮤니케이션과 데이터 공유를 위한 여러 매커니즘을 제공한다. 이러한 매커니즘을 묶어, Interprocess Communications (IPC)라고 부른다. 일부는 프로세스간의 작업 분배를 수월하게 해주며, 또 일부는 네트워크 상에 있는 컴퓨터들 사이의 작업 분배를 수월하게 해준다.

 

일반적으로, 애플리케이션은 클라이언트와 서버로 분류하여 IPC를 사용할 수 있다. 클라이언트는 어떤 다른 애플리케이션이나 프로세스에 서비스를 요청하는 애플리케이션 또는 프로세스이다. 서버는 클라이언트의 요청에 응답하는 애플리케이션 또는 프로세스이다. 많은 애플리케이션은 상황에 따라 클라이언트와 서버 둘다로 동작한다. 예를 들면, 워드 프로세스 애플리케이션은 서버로서 동작하는 스프레드 쉬트 애플리케이션에게 양산 비용의 요약 테이블을 요청하기 위해 클라이언트로서 동작할 수도 있다. 또, 스프레드 쉬트 애플리케이션은 자동화된 자재 제어(inventory control) 애플리케이션에게 최근의 자재 수준(inventory level)을 요청하기 위해 클라이언트로 동작할 수도 있다.

 

IPC가 만약 애플리케이션에 유용하다고 결정한 후에는, 어떤 IPC 수단을 사용할 것인지를 결정해야 한다. 하나의 애플리케이션이 여러 개의 IPC 매커니즘을 사용할 지도 모른다. 이 물음에 대한 답변은 애플리케이션이 애플리케이션이 하나를 사용할지 또는 그 이상의 IPC 매커니즘을 사용할지를 결정짓는다.

 

l  애플리케이션은 네트워크상에 있는 다른 컴퓨터에서 실행하고 있는 애플리케이션과 통신할수 있어야 하는가, 또는 로컬 컴퓨터에 있는 애플리케이션과 통신하는 것 만으로 충분한가?

l  애플리케이션은 다른 OS (16 비트 윈도우 또는 UNIX와 같은)에서 실행될 수도 있는 다른 컴퓨터상의 애플리케이션과 통신할 수 있어야 하는가?

l  애플리케이션의 사용자가 통신할 다른 애플리케이션을 선택할 수 있어야 하는가, 또는 애플리케이션은 통신할 파트너를 암시적으로 찾을 수 있는가?

l  애플리케이션은 다른 애플리케이션에게 cut-and-paste 연산을 허용하는 것과 같은, 일반적인 방법으로 다른 애플리케이션과 통신해야만 하는가? 또는 통신 요구사항(communications requirements)이 특정 애플리케이션과 제한된 범위의 상호작용으로 한정되어야 하는가?

l  성능이 애플리케이션에 있어 치명적인 요소인가? 모든 IPC 매커니즘은 약간의 오버헤드를 포함하고 있다.

l  애플리케이션은 GUI 애플리케이션인가, 또는 콘솔 애플리케이션인가? 일부 IPC 매커니즘은 GUI 애플리케이션에서만 동작한다.

 

윈도우에서는 아래의 IPC 매커니즘을 지원한다.

 

l  클립보드 (Clipboard)

l  COM

l  Data Copy

l  DDE

l  File mapping

l  Mailslots

l  Pipes

l  RPC

l  Windows Sockets

 

클립보드를 IPC로 사용하기

 

클립보드는 애플리케이션간에 데이터를 공유하기 위한 중심 저장소로 동작한다. 사용자가 한 애플리케이션에서 cut 또는 copy 연산을 실행할 때, 애플리케이션은 선택된 데이터를 하나 또는 그이상의 표준적인 데이터(Standard) 또는 애플리케이션이 정의한 포맷으로 클립보드에 넣는다. 그러면 다른 애플리케이션은 클립보드에서 애플리케이션이 이해할 수 있는 형태의 포맷을 선택하여 데이터를 가져올 수 있다. 클립보드는 애플리케이션이 그 데이터 포맷에 대해 동의만을 필요로 하는 매우 느슨하게 묶여진 교환 방법이다. (역자 주 : 이 문맥은 아마 클립보드에 다양한 형태의 포맷으로 데이터를 저장해 놓으면, 그 데이터를 클립보드에서 가져가는 애플리케이션이 이해할 수 있는 데이터만을 가져간다는 것을 의미하는 것 같다. 예로, 만약 워드에서 텍스트를 선택하여 복사를 하여 메모장에 복사하면 단지 텍스트만을 가져가고, 다른 워드 프로세스에 복사를 하면 텍스트 뿐만 아니라 폰트와 색상도 함께 복사해 갈 수 있는 경우와 같다. 또, 그림판과 같은 경우에는 텍스트를 이미지로 바꿀 수 없으므로 복사를 수행하지 않는다. – 텍스트 박스에서 편집중은 제외). 애플리케이션은 같은 컴퓨터상에 존재하거나 네트워크상에 있는 다른 컴퓨터에 존재할 수 있다.

 

Key Point : 모든 애플리케이션은 클립보드에 다른 애플리케이션이 이해할 수 있는 형태의 데이터 포맷을 지원해야 한다. 예를 들면, 텍스트 에디터 또는 워드 프로세서는 최소한 순수한 텍스트 형태로 클립보드 데이터를 복사하거나 붙여 넣을 수 있어야 한다.

 

COM을 IPC로 사용하기

 

OLE를 사용하는 애플리케이션은 복합 문서(compound document)를 다룬다. – 즉, 문서는 많은 다른 애플리케이션으로부터 얻은 데이터로 구성된다. OLE는 데이터 편집을 위해 다른 애플리케이션을 호출하는 것을 쉽게 해 주는 서비스를 제공한다. 예를 들면, OLE를 사용하는 워드 프로세서는 스프레드쉬트로부터 얻은 그래프를 포함할 수 있다. 사용자는 편집을 위해 내장된 차트를 선택함으로써 워드프로세서 내에서 스프레드 쉬트를 자동적으로 시작할 수 있다. OLE는 스프레드 쉬트를 시작하고 그래프를 편집하는 것을 다룬다. 사용자가 스프레드 쉬트를 종료할 때, 그래프는 원본 워드 프로세서 문서내에서 업데이트 될 것이다. 스프레드 쉬트는 워드 프로세서의 확장인 것 처럼 보인다.

 

OLE의 기초는 Component Object Model(COM)이다. COM을 사용하는 소프트웨어 컴포넌트는 아주 다양한 다른 컴포넌트들과 통신할 수 있다, 심지어 아직 작성되지 않은 컴포넌트들과도. 컴포넌트는 객체와 클라이언트로서 상호작용한다. 분산 COM (DCOM)은 네트워크를 넘어서 동작하기 위해 COM 프로그래밍 모델을 확장한다.

 

Key Point : OLE는 복합 문서를 지원하고 선택될 때, 자동적으로 데이터 편집을 위해 다른 애플리케이션이 시작되는 내장된 또는 연결된 데이터를 포함하는 것을 가능하게 한다. 이것은 애플리케이션이 OLE를 사용하는 모든 애플리케이션에게 확장될 수 있도록 한다. COM 객체는 인터페이스로 알려진 하나 또는 여러 개의 함수를 통해서 객체의 데이터에 대한 접근을 제공한다.

 

Data Copy 를 IPC로 사용하기

 

데이터 복사는 WM_COPYDATA 메시지를 사용하여 다른 애플리케이션에게 정보를 보내도록 한다. 이 방법은 보내는 애플리케이션과 받는 애플리케이션간의 협력을 필요로 한다. 받는 애플리케이션은 정보의 포맷을 알아야만 하고 송신자를 식별할 수 있어야 한다. 보내는 애플리케이션은 어떤 포인터에 의해 참조되는 메모리를 수정할 수 없다.

 

Key Point : 데이터 복사는 윈도우 메시지를 사용하여 다른 애플리케이션에게 정보를 빠르게 전송하는데 사용할 수 있다.

 

DDE를 IPC로 사용하기

 

DDE(Dynamic Data Exchange)는 애플리케이션이 다양한 형태의 포맷으로 데이터를 교환하도록 하는 프로토콜이다. 애플리케이션은 one-time 데이터 교환을 위해서나 또는 하나의 데이터를 새로운 데이터가 이용할 수 있게 될 때 다른 데이터로 업데이트하는 것과 같은 지속적인 데이터 교환을 위해서 DDE를 사용할 수 있다.

 

DDE에 사용되는 데이터 포맷은 클립보드에 사용되는 것과 같다. DDE는 클립보드 매커니즘의 확장의 하나로 볼 수 있다. 클립보드는 거의 항상 붙여넣기 명령을 메뉴로부터 선택하는 것과 같은 사용자 명령에 대한 one-time 응답을 위해서 사용된다. DDE도 보통 사용자 명령에 의해 초기화 되지만, 종종 사용자 상호작용 없이 지속적으로 동작한다. 좀더 강하게 묶여진 통신 요구사항을 가진 애플리케이션간에 특별한 목적의 IPC를 위해 사용자 정의형 DDE 데이터 포맷을 정의할 수 있다.

 

DDE 교환은 같은 컴퓨터상에 실행하고 있는 애플리케이션 간이나 네트워크상에 있는 다른 컴퓨터들 간에 일어날 수 있다.

 

Key Point : DDE는 최신의 기술들만큼 효과적이지 않다. 그러나, 다른 다른 IPC 매커니즘이 적합하지 않거나 또는 DDE만을 지원하는 기존의 애플리케이션과 상호작용해야 하는 경우에는 DDE를 여전히 사용할 수 있다.

 

File Mapping을 IPC로 사용하기

 

파일 맵핑은 프로세스를 파일의 컨텐츠로서 다루도록 한다. 마치 그 프로세스의 주소 공간에 있는 메모리 블락인 것 처럼. 프로세스는 파일의 콘텐츠를 조사하거나 수정하기 위해 간단한 포인터 연산을 사용할 수 있다. 두개 또는 그이상의 프로세스가 같은 파일 매핑에 접근 할 때, 각 프로세스는 자신의 주소 공간의 메모리에 대한 포인터를 얻는다. 그리고 그 포인터는 파일의 내용을 읽거나 수정하기 위해서 사용할 수 있다. 프로세스는 멀티태스킹 환경에서 데이터 오염(data corruption)을 방지하기 위해서는 세마포어와 같은 동기화 객체를 반드시 사용해야 한다.

 

프로세스간에 이름지어진 공유 메모리 (named shared memory)를 제공하기 위해 특별한 파일 맵핑을 사용할 수 있다. 만약 파일 맵핑 객체를 생성할 때 system swapping file을 명시한다면, 그 파일 맵핑 객체는 공유 메모리 블락으로 다루어 진다. 다른 프로세스는 같은 파일-맵핑 객체를 열어서 같은 메모리 블락에 접근할 수 있다.

 

파일 맵핑은 매우 효과적이고 또한 인증되지 않은 데이터 오염을 방지하는데 도움을 줄 수 있는 OS에 의해 지원되는 보안 특성을 제공한다. 파일 맵핑은 로컬 컴퓨터상에 있는 프로세스간에만 사용될 수 있다. 네트워크상에서는 사용될 수 없다.

 

Key Point : 파일 맵핑은 같은 컴퓨터상에 있는 두개 또는 그 이상의 프로세스들이 데이터를 공유하기 위한 효과적인 방법중의 하나이다, 그러나 프로세스간에 동기화를 제공해야만 한다.

 

Mailslot을 IPC로 사용하기

 

Mailslot 은 단방향 통신을 제공한다. mailslot을 생성하는 모든 프로세스는 mailslot 서버이다. mailslot 클라이언트라 불리는 다른 프로세스는 메시지를 자신의 mailslot에 작성함으로써 메시지를 mailslot 서버에 보낸다. 들어오는 메시지는 항상 mailslot에 추가된다. mailslot은 mailslot 서버가 그 메시지를 읽을 때 까지 그 메시지를 저장한다. 하나의 프로세스는 mailslot 서버가 될 수도 있고, mailslot 클라이언트가 될 수도 있다, 그래서 양방향 통신은 다중 mailslot을 사용함으로써 가능하다.

 

mailslot 클라이언트는 로컬 컴퓨터상에 있는 mailslot에, 다른 컴퓨터에 있는 mailslot에, 또는 특정 네트워크 도메인에 있는 모든 컴퓨터상에 있는 같은 이름의 모든 mailslot에 메시지를 보낼 수 있다. 어떤 도메인에 있는 모든 mailslot에 대한 메시지 브로드 캐스트는 400 바이트 이상이 될 수 없다, 반면에 하나의 mailslot에 보내어 지는 메시지는 mailslot이 생성될 때 mailslot 서버에 의해 명시된 최대 메시지 크기에 의해서만 제한된다.

 

Key Point : Mailslot은 애플리케이션이 짧은 메시지를 보내거나 받기 위한 쉬운 방법을 제공한다. 한 네트워크 도메인에 있는 모든 컴퓨터에 메시지를 브로드캐스트하는 능력을 또한 제공한다.

 

Pipe를 IPC로 사용하기

 

양방향 토신을 위한 두가지 형태의 파이프가 있다. 익명 파이프(anonymous pipe)와 이름있는 파이프(Named pipe). 익명 파이프는 관련된 프로세스들이 서로에게 정보를 전송하게끔 한다. 일반적으로, 익명 파이프는 자식 프로세스의 표준 입출력을 재정하기 위해 사용된다, 그렇게 함으로써 자식 프로세스는 부모 프로세스와 데이터를 교환할 수 있다. 양방향으로 데이터를 교환하기 위해서는, 반드시 두개의 익명 파이프를 생성해야 한다. 부모 프로세스는 자신의 write 핸들을 사용하여 데이터를 파이프에 작성한다, 반면에 자식 프로세스는 자신의 read 핸들을 사용하여 파이프로부터 그 데이터를 읽는다. 비슷하게, 자식 프로세스는 데이터를 다른 파이프에 작성하고 부모 프로세스는 그 파이프로부터 데이터를 읽는다. 익명 파이프는 네트워크 상에나 연관되지 않은(unrelated) 프로세스 사이에 사용될 수 없다.

 

이름있는 파이프는 관련 없는 프로세스 사이에 그리고 다른 컴퓨터에 있는 프로세스 사이에 데이터를 전송하는 데 사용된다. 일반적으로, 이름있는 파이프 서버는 이름있는 파이프를 잘알려진 이름으로 또는 클라이언트와 통신하기로 되어 있는 이름을 가지고 생성한다. 그 파이프의 이름을 알고 있는 이름있는 파이프 클라이언트 프로세스는 이름있는 파이프 서버 프로세스가 명시한 접근 제한을 가지고 그 파이프를 열 수 있다. 서버와 클라이언트가 파이프로 연결된 후에, 그들은 파이프상에서 읽기와 쓰기 연산을 수행함으로써 데이터를 교환할 수 있다.

 

Key Point : 익명 파이프는 같은 컴퓨터에 있는 자식 프로세스와 표준 입출력을 재정하기 위한 효율적인 방법을 제고한다. 이름있는 파이프는 같은 컴퓨터상에 또는 다른 네트워크상에 존재하는 두개의 프로세스사이에 데이터를 전송하는 간단한 프로그래밍 인터페이스를 제공한다.

 

RPC를 IPC로 사용하기

 

RPC는 애플리케이션이 원격으로 함수를 호출하도록 한다. 그리하여, RPC는 IPC가 함수를 호출하는데 있어 가능한한 쉽게 만들어 준다. RPC는 단일 컴퓨터 또는 네워크상에 있는 다른 컴퓨터에 있는 프로세스사이에 동작한다.

 

윈도우에 의해 제공되는 RPC는 Open Software Foundation(OSF) Distributed Computing Environment(DCE)에 따른다. 이것은 RPC를 사용하는 애플리케이션은 DCE를 지원하는 다른 OS에서 실행하고 있는 애플리케이션과 통신할 수 있다는 것을 의미한다. RPC는 다른 하드웨어 아키텍처와 다른 4 바이트-순서로 된 환경 사이에 데이터 변환을 자동적으로 책임을 진다.

 

RPC 클라이언트와 서버는 강하게 결합되어 있지만 높은 성능을 여전히 유지한다. 시스템은 RPC를 사용함으로써 다른 OS 사이의 클라이언트/서버 관계를 용이하게 만들 수 있다.

 

Key Point : RPC는 다른 OS사이에 통신을 위한 자동 데이터 변환을 지원하는 함수-수준의 인터페이스의 하나이다. PRC를 사용함으로써, 고성능의, 강하게 결합된 분산 애플리케이션을 생성할 수 있다.

 

Windows Socket을 IPC로 사용하기

 

윈도우 소켓은 프로토콜-독립적인 인터페이스의 하나이다. It takes advantage of the communication capabilities of the underlying protocols. (???) 윈도우 소켓 2에서, 소켓 핸들은 선택적으로 표준 파일 입출력 함수를 가지고 파일 핸들처럼 사용될 수 있다.

 

윈도우 소켓은 Berkeley Software Distribution (BSD)에 의해 처음으로 보급된 소켓에 기초를 두고 있다. 윈도우 소켓을 사용하는 애플리케이션은 다른 시스템과 소켓 구현을 가지고 통신할 수 있다. 그러나, 모든 전송 서비스 공급자가 모든 가능한 옵션을 지원하지는 않는다.

 

Key Point : 윈도우 소켓은 현재의 그리고 새로운 네트워크 능력을 지원할 수 있는 프로토콜 독립적인 인터페이스이다.

 

참고 : http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx#base.using_rpc_for_ipc