[OS] IPC 시스템의 사례(Examples of IPC Systems)

 

IPC 시스템의 사례(Examples of IPC Systems)

---

 

[OS] 프로세스 간 통신(Interprocess Communication, IPC)

이전에 IPC의 개념에 대해 살펴보았습니다. 이번에는 네 가지 다른 IPC 시스템의 사례에 대해 살펴보겠습니다. 

1. POSIX 공유 메모리(POSIX Shared Memory)
2. Mach 메시지 전달(Mach Message Passing)
3. Windows
4. 파이프(Pipes)

 

 

1. POSIX 공유 메모리(POSIX Shared Memory)

---

공유 메모리 메시지와 전달을 포함하여 POSIX 시스템을 위한 다수의 IPC 기법이 사용 가능합니다. 여기서 공유 메모리를 위한 POSIX API를 살펴보겠습니다.

 POSIX 공유 메모리는 메모리-사상 파일을 사용하여 구현됩니다. 메모리-사상 파일은 공유 메모리의 특정 영역을 파일과 연관시킵니다. 프로세스는 먼저 아래와 같이 shm_open() 시스템 콜을 사용하여 공유 메모리 객체를 생성해야 합니다.

fd = shm_open(name, O_CREATE | O_RDWR, 0666);

첫 번째 인자는 공유 메모리 객체의 이름을 지정합니다. 공유 메모리에 접근하고자 하는 프로세스는 이 이름을 통하여 객체를 언급합니다. 이어서 두 번째 인자는 객체가 존재하지 않으면 생성되고(O_CREATE) 객체는 읽기와 쓰기가 가능한 상태로 열린다는 것을 나타냅니다(O_RDWR). 마지막 인자는 공유 메모리 객체에 파일-접근 허가권을 부여합니다. shm_open()이 성공하면 공유 메모리 객체를 나타내는 정수형 파일 설명자를 반환합니다.

 객체가 설정되면 ftruncate() 함수를 사용하여 객체의 크기를 바이트 단위로 설정합니다. 다음과 같은 호출은 객체의 크기를 4096바이트로 설정합니다.

ftruncate(fd, 4096);

 마지막으로 mmap() 함수가 공유 메모리 객체를 포함하는 메모리-사상 파일을 구축합니다.mmap() 함수는 공유 메모리 객체에 접근할 때 사용될 메모리-사상 파일의 포인터를 반환합니다.

 아래 두 코드의 프로그램은 공유 메모리를 구현하기 위하여 생산자-소비자 모델을 사용합니다. 

코드 1) POSIX공유 메모리 API를 설명하는 생상자 프로세스

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/shm.h>
#include <sys/stat.h>

#include <sys/mman.h>

int main()
{
    /* the size (in bytes) of shared memory object */
    const int SIZE = 4096;
    /* name of the shared memory object */
    const char *name = "OS";
    /* strings written to shared memory */
    const char *message 0 = "Hello";
    const char *message 1 = "World!";
    
    /* shared memory file descriptor */
    int fd;
    /* pointer to shared memory obect */
    char *ptr;
    
    /* create the shared memory object */
    fd = shm open(name,O CREAT | O RDWR,0666);
    
    /* configure the size of the shared memory object */
    ftruncate(fd, SIZE);
    
    /* memory map the shared memory object */
    ptr = (char *)
    mmap(0, SIZE, PROT READ | PROT WRITE, MAP SHARED, fd, 0);
    
    /* write to the shared memory object */
    sprintf(ptr,"%s",message 0);
    ptr += strlen(message 0);
    sprintf(ptr,"%s",message 1);
    ptr += strlen(message 1);
    
    return 0;
}

 

코드 2) POSIX 공유 메모리 API를 설명하는 소비자 프로세스

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/shm.h>
#include <sys/stat.h>

#include <sys/mman.h>
int main()
{
    /* the size (in bytes) of shared memory object */
    const int SIZE = 4096;
    /* name of the shared memory object */
    const char *name = "OS";
    /* shared memory file descriptor */
    int fd;
    /* pointer to shared memory obect */
    char *ptr;
    
    /* open the shared memory object */
    fd = shm open(name, O RDONLY, 0666);
    
    /* memory map the shared memory object */
    ptr = (char *)
    mmap(0, SIZE, PROT READ | PROT WRITE, MAP SHARED, fd, 0);
    
    /* read from the shared memory object */
    printf("%s",(char *)ptr);
    
    /* remove the shared memory object */
    shm unlink(name);
    
    return 0;
}

 

생산자는 공유 메모리 객체를 구축하고 공유 메모리에 데이터를 쓰고, 소비자는 공유 메모리에서 데이터를 읽습니다. 위 코드 1에서 보인 생산자는 OS라고 명명된 공유 메모리 객체를 생성하고 문자열 "Hello World"를 공유 메모리에 씁니다. 프로그램은 지정된 크기의 공유 메모리 객체를 메모리에 사상하고 객체에 쓰기 권한을 부여합니다. MAP_SHARED 플래그는 공유 메모리 객체에 변경이 발생하면 객체를 공유하는 모든 프로세스가 최신의 값을 접근하게 된다는 것을 지정합니다. 공유 메모리 객체에 쓰기 작업을 할 때 sprintf() 함수를 호출하고 출력 형식이 완성된 문자열은 ptr이 가리키는 공유 메모리 객체에 쓰인다는 것을 주의해야 합니다. 쓰기 작업이 성공하면 쓰인 바이트 수만큼 포인터를 반드시 증가시켜야 합니다.

 코드 2의 소비자 프로세스는 공유 메모리의 내용을 읽고 출력합니다. 또한 소비자는 shm_unlink() 함수를 호출하여 접근이 끝난 공유 메모리를 제거합니다.

 

 

2. Mach 메시지 전달(Mach Message Passing)

---

다음 메시지 전달의 예로 Mach 운영체제를 고려해 봅시다. Mach는 특히 분산 시스템용으로 설계되었지만 macOS 및 iOS 운영체제에 포함된 사실이 입증하듯이 데스크톱 및 모바일 시스템에도 적합합니다.

 Mach 커널은 프로세스와 유사하지만 제어 스레드가 많고 관련 자원이 적은 다중 태스크의 생성 및 제거를 지원합니다. 모든 태스크 간 통신을 포함하여 Mach에서 대부분의 통신은 메시지로 수행됩니다. Mach에서 포트(port)라고 하는 메일박스로 메시지를 주고받습니다. 포트는 크기가 정해져 있고 단방향입니다. 양방향 통신인 경우 메시지가 한 포트로 전송되고 응답이 별도의 응답 포트로 전송됩니다. 각 포트에는 여러 송신자가 있을 수 있지만 수신자는 오직 하나만 존재합니다. Mach는 포트를 사용하여 태스크, 스레드, 메모리 및 프로세서와 같은 자원을 나타내며, 메시지 전달은 이러한 시스템 자원 및 서비스와 상호 작용하기 위한 객체 지향 접근 방식을 제공합니다. 동일한 호스트 또는 분산 시스템의 별도 호스트의 두 포트 사이에서 메시지 전달이 발생할 수 있습니다.

 각 포트에는 그 포트와 상호 작용하는 데 필요한 자격을 식별하는 포트 권한 집합이 연관됩니다. 예를 들어, 태스크가 포트에서 메시지를 수신하려면 해당 포트에 대해 MACH_PORT_RIGHT_RECEIVE 자격이 있어야 합니다. 포트를 생성한 태스크가 해당 포트의 소유자이며, 소유자는 해당 포트에서 메시지를 수신할 수 있는 유일한 태스크입니다. 포트의 소유자는 포트의 자격을 조작할 수도 있습니다. 이러한 조작은 일반적으로 응답 포트를 설정할 때 수행됩니다. 예를 들어, 태스크 T1이 포트 P1을 소유하고 태스크 P2가 소유한 포트 P2에 메시지를 전송한다고 가정합시다. T1이 T2로부터 응답을 받으려면 T2에 포트 P1에 대한 MACH_PORT_RIGHT_SEND 권한을 부여해야 합니다. 포트 권한의 소유권은 태스크에게 주어집니다. 즉, 동일한 태스크에 속하는 두 개의 스레드는 각 스레드와 관련된 스레드-별 포트를 통해 메[시지를 교환하여 쉽게 통신할 수 있습니다.

 태스크가 생성되면 Task Self 포트와 Notify 포트라는 두 개의 특별한 포트도 생성됩니다. 커널은 Task Self 포트에 대한 수신 권한을 가지고 있어 태스크가 커널에 메시지를 보낼 수 있습니다. 커널은 이벤트 발생 알림을 작업의 Notify 포트(물론 태스크가 수신 권한을 가지고 있음)로 보낼 수 있습니다.

 mach_port_allocate() 함수 호출은 새 포트를 작성하고 메시지 큐를 위한 공간을 할당합니다. 또한 포트에 대한 권한을 식별합니다. 각 포트 권한은 해당 포트의 이름을 나타내며 포트의 권한을 통해서만 액세스 할 수 있습니다. 포트 이름은 단순한 정수 값이며 UNIX 파일 디스크립터와 매우 유사하게 작동합니다. 다음 예제는 이 API를 사용하여 포트를 생성하는 방법을 보여줍니다.

mach port t port; // 포트 권한의 이름
mach port allocate(
     mach task self(), // a task referring to itself
     MACH PORT RIGHT RECEIVE, // the right for this port
     &port); // the name of the port right

 

 각 태스크는 또한 부트스트랩 포트에 액세스 할 수 있어서 태스크가 생성한 포트를 시스템 전체의 부트스트랩 서버에 등록할 수 있습니다. 포트가 부트스트랩 서버에 등록되면 다른 태스크가 이 레지스트리에서 포트를 검색하여 포트로 메시지를 보낼 수 있는 권한을 얻을 수 있습니다.

 각 포트와 관련된 큐는 크기가 제한되어 있으며 처음에는 비어 있습니다. 메시지가 포트로 전송되면 큐에 복사됩니다. 모든 메시지는 안정적으로 전달되며 동일한 우선순위를 가집니다. Mach는 동일한 송신자의 여러 메시지가 선입선출(FIFO) 순서로 큐에 삽입하지만 절대적 순서를 보장하지는 않습니다. 예를 들어, 두 명의 송신자가 보낸 메시지는 임의의 순서로 큐에 저장됩니다.

 Mach 메시지에는 다음 두 필드를 포함합니다.

• 고정 크기의 메시지 헤더. 헤더는 메시지 크기, 소스 및 대상 포트를 포함한 메시지에 관한 메타 데이터를 포함한다. 일반적으로 송신 스레드는 응답을 예상하므로 소스의 포트 이름이 수신 태스크로 전달되어 응답을 보내는 데 "반환 주소"로 사용할 수 있다.
• 데이터를 포함하는 가변 크기 본체

 메시지는 단순하거나 복잡할 수 있습니다. 간단한 메시지는 커널에 의해 해석되지 않는 구조화되지 않은 보통의 사용자 데이터를 포함합니다. 복잡한 메시지는 "out-of-line" 데이터를 포함하는 메모리 위치에 대한 포인터를 포함하거나 다른 태스크에 포트 권한을 전송하는 데 사용될 수 있습니다. Out-of-line 데이터 포인터는 메시지가 많은 양의 데이터를 전달해야 할 때 특히 유용합니다. 간단한 메시지는 메시지의 데이터를 복사하고 패키징해야 합니다. Out-of-line 데이터 전송에는 데이터가 저장된 메모리 위치를 가리키는 포인터만 필요합니다.

 mach_msg() 함수는 메시지를 보내고 받는 표준 API입니다. 함수는 매개변수 중 하나가 MACH_SEND_MSG 또는 MACH_RCV_MSG값을 가지며 송신 또는 수신 연산자인지를 나타냅니다. 이제 클라이언트 태스크가 서버 태스크에 간단한 메시지를 보낼 때 사용되는 방법을 설명하겠습니다. 클라이언트 및 서버 태스크와 각각 연관된 두 개의 포트(client와 server)가 있다고 가정합시다. 아래 코드는 클라이언트 태스크가 헤더를 구성하고 서버로 메시지를 보내는 것뿐만 아니라 클라이언트가 보낸 메시지를 받는 서버 태스크를 보여줍니다.

Mach에서 메시지 전달을 설명하는 예제 프로그램

#include<mach/mach.h>

struct message {
    mach msg header t header; int data;
};

mach port t client;
mach port t server;

/* 클라이언트 코드 */
struct message message;

// 헤더를 구축
message.header.msgh size = sizeof(message);
message.header.msgh remote port = server;
message.header.msgh local port = client;

// 메시지를 송신한다.
mach msg(&message.header, // 메시지 헤더
         MACH_SEND_MSG, // 메시지 송신
         sizeof(message), // 송신된 메시지 크기
         0, // 수신 메시지의 최대 크기 - 필요없음
         MACH_PORT_NULL, // 수신 포트의 이름 포트 없음 필요없음
         MACH_MSG_TIMEOUT_NONE, // 타임아웃 설정 없음
         MACH_PORT_NULL // 포트 없음
);


/* 서버 코드 */

struct message message;

// 메시지를 수신한다.
mach msg(&message.header, // 메시지 헤더
         MACH_RCV_MSG, // 메시지 수신
         0, // 송신된 메시지 크기
         sizeof(message), // 수신 메시지의 최대 크기
         server,    // 수신 포트의 이름
         MACH_MSG_TIMEOUT_NONE, // 타임 아웃 설정 없음
         MACH_PORT_NULL // 포트 없음
);

 

 mach_mag() 함수 호출은 메시지 전달을 수행하기 위해 사용자 프로그램에 의해 호출됩니다. 그런 다음 mach_msg()는 mah_msg_trap() 함수를 호출합니다. 이는 mah 커널에 대한 시스템 콜입니다. 커널 내에서 mach_msg_trap()은 mach_msg_overwrite_trap() 함수를 호출하여 메시지의 실제 전달을 처리합니다.

 송수신 작업 자체는 융통성이 있습니다. 예를 들어, 메시지가 포트로 전송되었을 때, 큐가 가득 찼을 수도 있습니다. 큐가 가득 차지 않으면 메시지가 큐에 복사되고 전송 작업이 계속됩니다. 포트의 큐가 가득 찬 경우 송신자는 mach_msg()의 매개변수를 통해 다음 중 하나를 선택할 수 있습니다.

1. 큐에 공간이 생길 때까지 무기한 기다린다.
2. 최대 n 밀리초 동안 기다린다.
3. 기다리지 말고 즉시 복귀한다.
4. 메시지를 일시적으로 캐시 한다. 메시지가 전송되는 큐가 가득 차더라도 운영체제에 전달하여 보존한다. 메시지를 큐에 넣을 수 있을 때, 통지 메시지가 송신자에게 전송된다. 큐가 가득 찼을 경우 송신 스레드마다 하나의 메시지만 커널에 보관할 수 있다.

마지막 4번 옵션은 서버 태스크를 위한 것입니다. 요청을 완료한 후 서버 태스크는 서비스를 요청한 태스크에 일회성 응답을 보내야 합니다. 그러나 클라이언트의 응답 포트가 가득 찬 경우에도 다른 서비스 요청을 계속 서비스해야 합니다.

 메시지 시스템의 주요 문제점은 일반적으로 송신자의 포트에서 수신자의 포트로 메시지를 복사해야 하므로 발생하는 성능 저하입니다. Mach 메시지 시스템은 가상 메모리 관리 기술을 사용하여 복사 연산을 피하려고 합니다. 기본적으로 Mach는 송신자의 메시지가 포함된 주소 공간을 수신자의 주소 공간에 매핑합니다. 따라서 송신자와 수신자 모두 동일한 메모리에 액세스 하므로 메시지 자체는 실제로 복사되지 않습니다. 이 메시지 관리 기술은 성능을 크게 향상시키지만 같은 시스템 내 메시지에만 작동합니다.

 

3. Windows

---

Windows 운영체제는 모듈화를 이용하여 기능을 향상시키고 새로운 기능을 구현하는 시간을 감소시킨 최신 설계의 예입니다. Windows는 다중 운영 환경 또는 서브시스템을 지원하며, 응용 프로그램은 메시지 전달 기법을 통해 이들과 통신합니다. 따라서 응용 프로그램은 서브 시스템 서버의 클라이언트로 간주할 수 있습니다.

 Windows의 메시지 전달 설비는 고급 로컬 프로시저 호출 설비(advanced local procedure call facility, ALPC)라 불립니다. ALPC는 동일 기계상에 있는 두 프로세스 간의 통신에 사용합니다. 이것은 널리 사용되는 표준 원격 프로시저 호출(RPC) 기법과 같으나, Windows에 맞게 특별히 최적화되었습니다. Mach와 유사하게, Windows는 두 프로세스 간에 연결을 구축하고 유지하기 위해 포트 객체를 사용합니다. Windows는 연결 포트(connection port)와 두 가지 유형의 포트를 사용합니다.

 서버 프로세스는 모든 프로세스가 접근할 수 있는 연결 포트 객체를 공표합니다. 클라이언트가 서브시스템으로부터 서비스를 원할 경우, 서버의 연결 포트 객체에 대한 핸들을 열고 연결 요청을 보냅니다. 그러면 서버는 채널을 생성하고 핸들을 클라이언트에게 반환합니다. 채널은 한 쌍의 사적인 통신 포트로 구성되는데, 하나는 클라이언트에서 서버로 메시지를 보내기 위한 포트이고 다른 하나는 서버에서 클라이언트로 메시지를 보내기 위한 포트입니다. 추가적으로 통신 채널은 클라이언트와 서버가 응답 메시지를 기다리고 있는 동안에도 다른 요청을 받아들일 수 있도록 콜백 기법을 제공합니다.

 ALPC 채널이 생성되면 다음 3가지 중 하나의 메시지 전달 기법의 하나가 선택됩니다.

1. 256바이트까지의 작은 메시지의 경우, 포트의 메시지 큐가 중간 저장소로 사용되고, 메시지는 프로세스에서 프로세스로 복사된다.
2. 대용량 메시지는 반드시 섹션 객체(section object)를 통하여 전달되어야 한다. 섹션 객체란 채널과 연관된 공유 메모리의 영역을 말한다.
3. 데이터의 양이 너무 많아서 섹션 객체에 저장될 수 없는 경우, 서버 프로세스가 클라이언트의 주소 공간을 직접 읽거나 쓸 수 있는 API를 사용할 수 있다.

 클라이언트는 채널을 설정할 때 대용량 메시지 전송이 필요한지 결정해야만 합니다. 클라이언트가 대용량 메시지를 보내야 한다고 결정하면 섹션 객체의 생성을 요청합니다. 마찬가지로, 서버의 응답 메시지가 대용량이라고 예상되면 서버가 섹션 객체를 생성합니다. 섹션 객체를 사용하려면 섹션 객체를 가리키는 포인터와 크기에 관한 정보를 담고 있는 작은 메시지가 전송됩니다. 이 방법은 위에서 나열한 첫 번째 방법보다 복잡하지만 데이터 복사가 발생하지 않습니다. Windows의 고급 지역 프로시저 호출의 구조가 아래 이미지에 나와 있습니다.

Windows의 고급 로컬 프로시저 호출

 Windows의 고급 로컬 프로시저 호출 설비는 Windows API의 부분이 아니기 때문에 응용 프로그래머는 사용할 수 없다는 사실에 주의해야 합니다. Windows API를 사용하는 응용은 표준 원격 프로시저 호출을 부릅니다. 같은 시스템상에 존재하는 프로세스의 RPC가 호출되면 이 RPC는 간접적으로 고급 로컬 프로시저 호출을 통하여 처리됩니다. 또한 많은 커널 서비스들은 클라이언트 프로세스와 통신하기 위하여 ALPC를 사용합니다.

 

 

4. 파이프(Pipes)

---

파이프는 두 프로세스가 통신할 수 있게 하는 전달자로서 동작합니다. 파이프는 초기 UNIX 시스템에서 제공하는 IPC 기법의 하나였습니다. 파이프는 통상 프로세스 간에 통신하는 더 간단한 방법의 하나이지만 통신할 때 여러 제약을 합니다. 파이프를 구현하기 위해서는 다음 4가지 문제를 고려해야 합니다.

1. 파이프가 단방향 통신 또는 양방향 통신을 허용하는가?
2. 양방향 통신이 허용된다면 반이중(half duplex) 방식인가, 전이중(full duplex) 방식인가? 반이중 박식은 한순간에 한 방향 전송만 가능하고 전이중 방식은 동시에 양방향 데이터 전송이 가능하다.
3. 통신하는 두 프로세스 간에 부모-자식과 같은 특정 관계가 존재해야만 하는가?
4. 파이프는 네트워크를 통하여 통신이 가능한가, 아니면 동일한 기계 안에 존재하는 두 프로세스끼리만 통신할 수 있는가?

아래에서 UNIX와 Windows 시스템에서 사용되는 일반 파이프와 지명 파이프의 두 가지 유형의 파이프에 대해 살펴보겠습니다.

(1) 일반 파이프(Ordinary Pipes)

일반 파이프는 생산자-소비자 형태로 두 프로세스 간의 통신을 허용합니다. 생산자는 파이프의 한 종단(쓰기 종단)에 쓰고, 소비자는 다른 종단(읽기 종단)에서 읽습니다. 결과적으로 일반 파이프는 한쪽으로만 데이터를 전송할 수 있으며 오직 단방향 통신만을 가능하게 합니다. 만일 양방향 통신이 필요하다면 각각 다른 방향으로 데이터를 전송할 수 있는 두 개의 파이프를 사용해야 합니다. 다음으로 UNIX와 Windows 시스템에서 일반 파이프를 구축하는 예를 설명합니다. 두 개의 프로그램 예제에서 한 프로세스는 Greetings라는 메시지를 파이프에 쓰고, 다른 프로세스는 이 메시지를 파이프로부터 읽습니다. 

 UNIX 시스템에서 일반 파이프는 다음 함수를 사용하여 구축됩니다.

pipe(int fd[])

이 함수는 fd[] 파일 설명자를 통해 접근되는 파이프를 생성합니다. fd[0]는 파이프의 읽기 종단이고 fd[1]은 파이프의 쓰기 종단으로 동작합니다. UNIX는 파이프를 파일의 특수한 유형으로 취급합니다. 따라서 파이프는 일반적인 read()와 write() 시스템 콜을 사용하여 접근될 수 있습니다. 

 일반 파이프는 파이프를 생성한 프로세스 이외에는 접근할 수 없습니다. 따라서 통산 부모 프로세스가 파이프를 생성하고 fork()로 생성한 자식 프로세스와 통신하기 위해 사용합니다. 파이프는 파일의 특수한 유형이기 때문에 자식 프로세스는 부모로부터 파이프를 상속받습니다. 아래 이미지는 fd 배열의 파일 디스크립터와 부모 및 자식 프로세스의 관계를 보여줍니다. 

일반 파이프를 위한 파일 디스크립터

위 이미지에서 보듯이 부모가 파이프의 쓰기 종단(fd[1])에 데이터를 쓰면 파이프의 읽기 종단(fd[0])에서 자식이 읽을 수 있습니다.

UNIX의 일반 파이프

#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#define BUFFER SIZE 25
#define READ END 0
#define WRITE END 1

int main(void)
{
    char write msg[BUFFER SIZE] = "Greetings";
    char read msg[BUFFER SIZE];
    int fd[2];
    pid t pid;
    
    /* create the pipe */
    if (pipe(fd) == -1) {
        fprintf(stderr,"Pipe failed");
        return 1;
    }
    
    /* fork a child process */
    pid = fork();
    
    if (pid < 0) { /* error occurred */
        fprintf(stderr, "Fork Failed");
        return 1;
    }
    
    if (pid > 0) { /* parent process */
        /* close the unused end of the pipe */
        close(fd[READ END]);
        
        /* write to the pipe */
        write(fd[WRITE END], write msg, strlen(write msg)+1);
        
        /* close the write end of the pipe */
        close(fd[WRITE END]);
    }
    else { /* child process */
        /* close the unused end of the pipe */
        close(fd[WRITE END]);
        
        /* read from the pipe */
        read(fd[READ END], read msg, BUFFER SIZE);
        printf("read %s",read msg);
        
        /* close the read end of the pipe */
        close(fd[READ END]);
    }
    
    return 0;
}

 

위 코드에서 보인 UNIX 프로그램에서 부모 프로세스는 파이프를 생성하고 자식 프로세스를 생성하기 위하여 fork()를 호출합니다. fork() 후에 일어나는 작업은 파이프를 통해 데이터가 어떻게 흘러가느냐에 따라 달라집니다. 이 예제에서는 부모 프로세스가 파이프에 쓰고, 자식 프로세스가 파이프로부터 읽습니다. 부모와 자식 프로세스 모두 처음에 자신들이 사용하지 않는 파이프의 종단을 닫는 것을 주의해야 합니다. 위 코드에 보인 프로그램은 이러한 작업을 하지는 않지만 writer가 파이프의 종단을 닫았을 때, 파이프로부터 읽는 프로세스가 end-of-file (reade()가 0을 반환)을 탐지하는 것을 보장하기 때문에 이 작업은 매우 중요한 절차입니다.

 Windows 시스템의 일반 파이프는 익명 파이프(anonynous pipe)라고 불리며 UNIX의 대응되는 파이프와 유사하게 동작합니다. 이 파이프는 단방향이고 통신하는 두 프로세스는 부모-자식 관계여야 합니다. 게다가 파이프의 읽기와 쓰기는 보통의 Read-File()과 WriteFile()을 사용하여 이루어집니다. 파이프를 생성하기 위한 Windows API는 CreatePipe() 함수로서 5개의 매개변수를 전달받습니다. 매개변수는 (1) 읽기, (2) 쓰기, (3) 자식 프로세스가 파이프의 핸들을 상속받는다는 것을 명시하기 위해 사용되는 STARTUPINFO 구조체의 인스턴스를 위한 각각의 핸들을 전달받습니다. 그리고 (4) 바이트 단위의 파이프의 크기가 지정될 수 있습니다.

Windows 익명 파이프-부모 프로세스

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#define BUFFER SIZE 25

int main(VOID){
    HANDLE ReadHandle, WriteHandle;
    STARTUPINFO si;
    PROCESS INFORMATION pi;
    char message[BUFFER SIZE] = "Greetings";
    DWORD written;
    
    /* set up security attributes allowing pipes to be inherited */
    SECURITY ATTRIBUTES sa = {sizeof(SECURITY ATTRIBUTES),NULL,TRUE};
    /* allocate memory */
    ZeroMemory(&pi, sizeof(pi));
    
    /* create the pipe */
    if (!CreatePipe(&ReadHandle, &WriteHandle, &sa, 0)) {
        fprintf(stderr, "Create Pipe Failed");
        return 1;
    }
    
    /* establish the START INFO structure for the child process */
    GetStartupInfo(&si);
    si.hStdOutput = GetStdHandle(STD OUTPUT HANDLE);
    
    /* redirect standard input to the read end of the pipe */
    si.hStdInput = ReadHandle;
    si.dwFlags = STARTF USESTDHANDLES;
    
    /* don’t allow the child to inherit the write end of pipe */
    SetHandleInformation(WriteHandle, HANDLE FLAG INHERIT, 0);
    
    /* create the child process */
    CreateProcess(NULL, "child.exe", NULL, NULL,
                  TRUE, /* inherit handles */
                  0, NULL, NULL, &si, &pi);
    
    /* close the unused end of the pipe */
    CloseHandle(ReadHandle);
    
    /* the parent writes to the pipe */
    if (!WriteFile(WriteHandle, message,BUFFER SIZE,&written,NULL))
        fprintf(stderr, "Error writing to pipe.");
    
    /* close the write end of the pipe */
    CloseHandle(WriteHandle);
    
    /* wait for the child to exit */
    WaitForSingleObject(pi.hProcess, INFINITE);
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
    return 0;
}

위 코드는 자식 프로세스와 통신하기 위하여 익명 파이프를 생성하는 부모 프로세스를 설명하고 있습니다. 자식 프로세스가 부모 프로세스가 생성한 파이프를 자동으로 상속받는 UNIX 시스템과는 다르게 Windows에서는 프로그래머가 어떤 속성을 상속받는지를 명시해야 합니다. 우선 핸들을 상속받을 수 있도록 SECURITY_ATTRIBUTES 구조를 초기화하고 다음에 자식 프로세스의 표준 입력 또는 표준 출력 핸들을 파이프의 읽기 또는 쓰기 핸들로 재지정해야 합니다. 자식 프로세스가 파이프로부터 읽도록 만들어야 하기 때문에 부모 프로세스는 자식의 표준 입력을 파이프의 읽기 핸들로 재지정해야만 합니다. 더욱이 파이프는 반이중 방식이므로 자식이 파이프의 쓰기 종단을 상속받는 것을 금지시켜야 합니다. 파이프에 쓰기 전에 부모는 먼저 파이프의 사용하지 않을 읽기 종단을 닫습니다. 파이프로부터 읽는 자식 프로세스는 아래의 코드에 나와 있습니다. 파이프로부터 읽기 전에 이 프로그램은 GetStdHandle() 함수를 호출하여 파이프의 읽기 핸들을 획득합니다.

Windows 익명 파이프-자식 프로세스

#include <stdio.h>
#include <windows.h>
#define BUFFER SIZE 25

int main(VOID)
{
    HANDLE Readhandle;
    CHAR buffer[BUFFER SIZE]; DWORD read;
    
    /* get the read handle of the pipe */
    ReadHandle = GetStdHandle(STD INPUT HANDLE);
    
    /* the child reads from the pipe */
    if (ReadFile(ReadHandle, buffer, BUFFER SIZE, &read, NULL))
        printf("child read %s",buffer);
    else
        fprintf(stderr, "Error reading from pipe");
    
    return 0;
}

 UNIX와 Windows 시스템 모두에서 통신하는 두 프로세스는 부모-자식 관계를 가져야 한다는 것을 명심하여야 합니다. 이 유형의 파이프는 동일한 기계상의 두 프로세스끼리만 통신이 가능하다는 것을 의미합니다.

(2) 지명 파이프(Named Pipes)

일반 파이프는 한 쌍의 프로세스가 통신할 수 있는 간단한 기법을 제공합니다. 그러나 일반 파이프는 오로지 프로세스들이 서로 통신하는 동안에만 존재합니다. UNIX와 Windows시스템 모두에서 프로세스들이 통신을 마치고 종료하면 일반 파이프는 없어지게 됩니다.

 지명 파이프(named pipes)는 좀 더 강력한 통신 도구를 제공합니다. 통신은 양방향으로 가능하며 부모-자식 관계도 필요로 하지 않습니다. 지명 파이프가 구축되면 여러 프로세스들이 이를 사용하여 통신할 수 있습니다. 실제 통상의 시나리오에서 지명 파이프는 다수의 writer를 가집니다. 추가로 통신 프로세스가 종료하더라도 지명 파이프는 계속 존재하게 됩니다. UNIX와 Windows 시스템은 구현상에 차이점은 있지만 모두 지명 파이프를 지원합니다. 다음으로 각 시스템의 지명 파이프를 살펴보겠습니다.

 지명 파이프를 UNIX에서는 FIFO라고 부릅니다. 생성되면 지명 파이프는 파일 시스템의 보통 파일처럼 존재합니다. FIFO는 mkfifo() 시스템 콜을 이용하여 생성되고 일반적인 open(), read(), write(), 및 close() 시스템 콜로 조작됩니다. 명시적으로 파일 시스템에서 삭제될 때까지 존재하게 됩니다. FIFO가 양방향 통신을 허용하기는 하지만 반이중 전송만이 가능합니다. 데이터가 양방향으로 전송될 필요가 있다면, 보통 2개의 FIFO가 사용됩니다. 부가적으로 통신하는 두 프로세스는 동일한 기계 내에 존재해야 합니다. 서로 다른 기계에 존재하는 프로세스 사이에 통신이 필요하다면 소켓을 사용해야 합니다.

 Windows 시스템의 지명 파이프는 UNIX의 상응 파이프보다 훨씬 풍부한 통신 기법을 제공합니다. 전이중 통신을 허용하며, 통신하는 두 프로세스는 같은 기계 또는 다른 기계상에 존재할 수 있습니다. 추가로 UNIX FIFO가 바이트-단위 통신만을 허용하는 것과 비교해 Windows 시스템 파이프는 바이트-단위 또는 메시지-단위 데이터의 전송을 허용합니다. 지명 파이프는 CreateNamePipe() 함수를 사용하여 생성되고 클라이언트는 ConnectNamedPipe() 함수를 사용하여 지명 파이프에 연결할 수 있습니다. 지명 파이프를 통한 통신은 ReadFile()과 WriteFile() 함수를 사용하여 실행됩니다.