WindowsNamedPipe

UserPreferences

http://www.windevnet.com/documents/s=7779/win0302d/0302d.htm

1. 개요
2. 파이프 생성에 있어서의 선택 사항
3. 오버랩드(OVERLAPPED) IO와 다중 스레드 모델
4. 입출력 관련 에러 처리
5. 객체 생성과 관련된 문제들
6. Sysinternals 툴들

1 개요

네임드 파이프는 윈도우즈에서 사용할 수 있는 IPC의 일종이다. 같은 머신 내의 프로세스간 통신에 이용할 수도 있고, 다른 머신의 프로세스간 통신에도 이용할 수 있다.

다른 머신과의 통신에 이용할 때, LAN 상이라면 소켓과 별로 차이가 나지 않으나, 인터넷을 통하게 되면 상당히 느려진다. (정확히 재어보지는 않았는데, 대강 10~100배 정도 느려지는 듯 하다.)

간단한 서버 간 통신 같은 것을 제작하는 경우, TCP나 UDP보다는 파이프를 이용하는 것이 좋다고 본다. 특히나 LAN 상에서의 통신이라면 더욱 추천하는 바이다.

2 파이프 생성에 있어서의 선택 사항

파이프 API 관련 MSDN을 보면 알겠지만, 생성할 때 상당히 많은 옵션을 줄 수 있다.

일단 양방향이냐, 단방향이냐는 별로 고려할 가치가 없다. 특수한 목적을 제외하고는 단방향을 선택할 이유가 없다고 생각한다. 그리고 블로킹 여부를 결정하는 PIPE_WAIT와 PIPE_NOWAIT의 경우, PIPE_NOWAIT가 이전의 호환성을 위해서만 아직 지원되는 것이므로, 미래를 위해서는 사용하지 않는 것이 좋다.

좀 생각해 볼만한 것 중에 첫번째가 파이프를 생성할 때 통신을 스트림 기반으로 할 것인지, 아니면 메시지 기반으로 할 것인지이다. 바이트 스트림 기반 통신의 경우 TCP와 마찬가지로, 양 끝단에서 직렬화가 필요하고, 데이터를 모두 받았다/아니다의 처리 등을 해줘야한다. 복잡한 대신, 데이터의 길이에는 제한이 없다. 메시지 기반의 경우, 정확히 반대다. 문자열 기반으로 생각하면 되기 때문에, 간단하지만, 서로 간에 정해진 길이 이상의 버퍼를 사용할 수 없다. 메시지 기반의 서버/클라이언트를 제작하는 경우, 두 모듈을 같은 곳에서 만든다면 파이프 버퍼의 크기는 별로 걱정할 필요가 없을 것이다. 버퍼의 크기를 정의한 상수를 둘이 공유하면 되기 때문이다. 다른 곳에서 제작할 때는... 흠.

두번째로 생각해볼만한 것은 한 순간에 하나의 클라이언트만 접속하도록 할 것이냐, 여러 클라이언트를 접속하게 할 것이냐이다. 대부분 하나의 클라이언트만을 사용한다. 처리 효율이 떨어지는 대신, 서버와 관련된 부분을 프로그래밍할 필요가 없으므로 간단하다.

그 다음 오버랩드 IO와 관련된 부분은 꽤 중요하므로 아래에 따로 다루겠다.

3 오버랩드(OVERLAPPED) IO와 다중 스레드 모델

PIPE_NOWAIT를 이용할 수 없으므로, 오버랩드 IO의 사용은 필수라고 생각한다. 통신할 때마다 프로그램이 블로킹된다는 것은 상당히 좋지 않다고 본다. 기본적으로 파이프 생성시에 FILE_FLAG_OVERLAPPED 플래그를 줘야한다. 그러면 파이프의 연결하기, 데이터 보내기, 받기가 비동기 방식으로 처리된다. 또한 오버랩드 IO를 이용한다고 해도 어차피 Wait`XXX 함수 시리즈로 IO가 끝나기를 기다려야하므로, 스레드를 따로 분리해 실질적인 IO를 처리하도록 해야한다.

파이프 모듈을 좀 더 쓸만하게 만들고자 한다면, 기본적인 IO 처리 외에도 추가적으로 처리해 줘야할 것이 있다.

첫번째는 파이프 연결이 끊어졌을 때, 재연결을 시도하는 기능이다. 클라이언트/서버 둘 다 있어야 할 기능이다. 물론 더 이상 파이프를 생성할 수 없는 상황인데, 계속 시도하면 안 되므로, 에러 카운트를 체크하는 기능도 있어야 한다.

두번째는 프로그램 종료시 등에 쓸 수 있도록 셧다운 이벤트를 추가하는 일이다. 스레드를 따로 생성해서 쓰기 때문에, 깔끔하게 종료하려면 셧다운 이벤트 같은 것이 있어야 한다. 셧다운시킨 파이프를 프로그램 내에서 더 이상 사용할 수 없도록 하는 것이 좋을 것이다.

4 입출력 관련 에러 처리

제일 일반적인 에러는 오버랩드 IO READ에서 발생하는 에러다. 특별히 따로 처리할 필요가 없는 이상, READ에서 발생하는 에러는 연결이 끊긴 것으로 간주하면 된다. 이보다 자주 발생하는 에러는 ERROR_PIPE_NOT_CONNECTED와 ERROR_BROKEN_PIPE가 있는데, 이 또한 파이프 연결이 끊어진 것을 의미한다. 파이프를 다룰 때 발생하는 모든 에러를 알고 싶다면 MSDN을 참고하기 바란다.

처리하기 좀 곤란하지만 꼭 처리해야할 경우가 있는데, 클라이언트가 다른 머신의 서버에 접속해 있다가, 서버가 죽은 경우이다. 이 경우 클라이언트는 길이가 0인 메시지를 여러 개 받게 된다. 처리하기 곤란한 이유는 이 경우, 윈도우 에러(GetLastError() 함수의 리턴값)가 뜨지 않기 때문이다. 이 경우도 카운트로 처리해서 일정 횟수 이상인 경우, 연결이 끊어진 것으로 판단해야할 것이다.

약간 비일반적이지만, 안정적인 메시지 전송을 원한다면 처리해야할 일이 있다. 메시지를 보내는 측에서 하나의 메시지를 보낸 후, 다른 메시지를 전송하기 전에 이전에 전송한 메시지가 전송 완료되기를 기다리는 일이다. 이는 오버랩드 IO 관련 함수에서 IO 완료시 Event Notification을 지원하므로 비교적 간단히 처리할 수 있다. 메시지 전송 완료를 기다리지 않고, 막 보내면 PIPE_WAIT 플래그를 이용해 생성한 파이프라고 하더라도, 받는 측의 버퍼가 넘치는 것을 방지할 수는 없다. 예를 들어 빠른 속도로 A, B, C의 메시지를 보내면, 받는 측에서는 A, A, C 이런 식의 메시지를 받게 된다는 말이다. 문제점은 바로 여기에 존재한다. 데이터를 빠른 속도로 마구 보내면, 오버랩드 IO WRITE가 성공/실패 여부를 반환하지 않고 실패하는 경우가 있다. (READ가 이런 경우는 이때까지 본 바로는 없다.) 반환하지 않는 WRITE를 끝내기 위해서는 타임아웃을 사용해야한다. 사실 주어진 시간 안에 끝나지 않는 WRITE는 접속이 끊어진 것과 같이 취급해야 한다고 생각한다.

5 객체 생성과 관련된 문제들

네임드 파이프가 NT 커널 오브젝트이기 때문에 보안과 관련된 몇가지 문제가 생길 수 있다.

첫째, 보안 기술자(security descriptor)로 NULL을 주는 것은 보안 관련 설정이 없는 것이 아니라, '기본' 설정을 이용하겠다는 말이다. 모든 곳에서 파이프 등의 NT 오브젝트를 접근 가능하게 하려면, 보안 기술자를 생성해서 거기다가 모든 곳에서 액세스한다는 것을 표시한 후, 그 기술자를 파이프 생성에 이용해야한다.

둘째, 다른 컴퓨터 간의 통신에 있어서 클라이언트 쪽은 서버 쪽의 프로세스간 통신 공유 장치(ipc$)에 접근할 수 있는 권한이 있어야 한다. 서버 쪽에서 NULL 세션을 이용하면, 모든 클라이언트가 접근할 수 있게 되므로, 이 문제를 해결할 수 있지만, 편법일 뿐이다. 왜냐하면 이렇게 해버리면 보안 설정이 여러 가지로 엉키기 때문이다. 자세한 것은 Microsoft Knowledge Base에 있는 Q124184 "Service Running as System Account Fails Accessing Network" 문서를 참고하기 바란다.

6 Sysinternals 툴들

Sysinternals Freeware에 가면 윈도우 시스템과 관련된 여러 가지 툴들을 얻을 수 있다. 이 중에 Process Explorer를 이용하면, 현재 머신에 존재하는 열린 파이프들을 알 수 있고, FileMon이란 툴을 이용하면 파일은 물론 네임드 파이프의 활동 상황을 모니터링할 수 있다. PipeList란 툴도 살펴보기 바란다.

• see also IPC