CreateFile 같은 파일 관련 API를 사용하기 때문에, 이에 익숙하다면, 쉽게 구현할 수 있다. 큐잉을 지원하지 않으며, 연결 지향이다. 점대점 연결이기 때문에, 브로드캐스팅을 지원하지 않는다. Win9X 계열은 클라이언트로서의 역할만 할 수 있다. 자세한 것은 WindowsNamedPipe 페이지를 참고.
2.1.2 Mailslots
큐잉을 지원하고, 비연결 방식이기 때문에 브로드캐스팅을 지원한다. 사용하기는 간단하나, 몇가지 단점이 있다.
메시지를 보내는 쪽에서는 받는 쪽에 어떤 프로토콜이 설치되어 있는지 모르기 때문에, 설치되어 있는 모든 프로토콜층에 메시지가 중복되어 나타난다. 이것을 정리하는 일(보통 태깅 시스템 같은 것으로...)은 프로그래머의 역할이다.
메시지의 길이가 400 바이트 이내로 제한된다.
UDP와 마찬가지로 전송을 보장하지 않는다.
그룹(예를 들어 현재 도메인 같은...) 브로드캐스팅을 지원한다. 그러나 RAS 링크 바깥으로 브로드캐스팅하는 것은 제대로 지원하지 않는다.
2.1.3 WM_COPYDATA
매우 사용하기 쉽다. 윈도우즈 메시지 기반이기 때문에, 메시지 펌프 처리를 해줘야한다. 메시지 통신의 빈도가 낮고, 빨리 구현하는 것이 우선이라면 이 방법이 좋을 수 있다. 다만 메시지를 받는 쪽이 윈도우 핸들이 가지고 있어야 한다.
2.1.4 Memory Mapped Files
Memory Mapped File도 프로세스 간 통신에 이용할 수 있다. 다른 IPC들이 Memory Mapped File를 이용해서 구현되므로, 속도가 중요하다면, Memory Mapped File이 가장 나은 선택이다. 자세한 것은 WindowsMemoryMappedFile 페이지를 참고.
2.1.5 DLL Shared Sections
이 방법은 당연히 DLL을 만들어야 한다. 간단한 프로세스간 통신을 위해서 DLL을 만드는 것은 어떻게 보면 오버라고도 할 수 있겠다. 또한 윈도우즈가 DLL을 구분할 때 파일 이름을 이용하는 것이 아니라, 패스를 이용하기 때문에 추가적인 문제가 발생할 수 있다. 즉 똑같은 두 개의 DLL이 다른 패스에 존재하는 상황에서, 두 프로세스가 각각의 DLL을 로드하게 되면, 통신이 이루어지지 않는다는 말이다.
2.1.6 DDE / NetDDE / ddeml
메시지 기반 공유 메모리 방식이다. 아직까지는 동작하지만, 언젠가는 윈도우즈 내에서 사라질 기능이다.
2.1.7 Sockets
소켓도 IPC의 일종이라고 할 수는 있으나, 왠지 좀... -_-; 어쨌든 마이크로소프트 윈속은 버클리 소켓을 베이스로 해서, 독자적인 기능을 추가한 것이다. 이 기능들 중에 하나가 비동기 소켓이다. 소켓 방식은 간단함과 이식성에서 다른 방식에 비해 훨씬 뛰어나기 때문에, 인터넷과 관련된 애플리케이션이라면 제일 먼저 고려해봐야 할 것이다.
가장 흔히 쓰이는 타입의 소켓은 TCP와 UDP다. TCP는 점대점 연결을 지원하며, 신뢰성 있는 전송을 보장하지만, 프레이밍을 지원하지 않기 때문에, 메시지 파싱을 직접 해줘야 한다. UDP는 이와는 반대로, 브로드캐스팅과 프레이밍을 지원하지만, 신뢰성 있는 전송을 보장하지 않는다.
![[WWW]](/img/moin-www.gif){kind=small}
Inter-Process Communication - Part 1 
