The Local Inter-Process Communication (LPC, often also referred to as Local Procedure Call or Lightweight Procedure Call) is an internal, undocumented inter-process communication facility provided by the Microsoft Windows NT kernel for lightweight IPC between processes on the same computer. As of Windows Vista, LPC has been rewritten as Asynchronous Local Inter-Process Communication (ALPC, often also Advanced Local Procedure Call) in order to provide a high-speed scalable communication mechanism required to efficiently implement User-Mode Driver Framework (UMDF), whose user-mode parts require an efficient communication channel with UMDF's components in the executive.

The (A)LPC interface is part of Windows NT's undocumented Native API, and as such is not available to applications for direct use. However, it can be used indirectly in the following instances:
 when using the Microsoft RPC API to communicate locally, i.e. between the processes on the same machine
 by calling Windows APIs that are implemented with (A)LPC (see below)

Implementation
(A)LPC is implemented using kernel "port" objects, which are securable (with ACLs, allowing e.g. only specific SIDs to use them) and allow identification of the process on the other side of the connection. Individual messages are also securable: applications can set per-message SIDs, and also test for changes of the security context in the token associated with the (A)LPC message.

The typical communication scenario between the server and the client is as follows:
 A server process first creates a named server connection port object, and waits for clients to connect.
 A client requests a connection to that named port by sending a connect message.
 If the server accepts the connection, two unnamed ports are created: 
 client communication port - used by client threads to communicate with a particular server
 server communication port - used by the server to communicate with a particular client; one such port per client is created
 The client receives a handle to the client communication port, and server receives a handle to the server communication port, and the inter-process communication channel is established.

(A)LPC supports the following three modes of message exchange between the server and client:
 For short messages (fewer than 256 bytes) the kernel copies the message buffers between processes, from the address space of the sending process to the system address space, and from there to the receiving process' address space.
 For messages longer than 256 bytes a shared memory section must be used to transfer data, which the (A)LPC service maps between the sending and receiving processes. First the sender places data into the shared memory, and then sends a notification (e.g. a small message, using the first method of (A)LPC) to the receiving process pointing to the sent data in the shared memory section.
 Server can directly read and write data from the client's address space, when the amount of data is too large to fit in a shared section.

ALPC has a performance advantage over the former LPC interface, as it can be configured to use I/O completion ports instead of synchronous request/reply mechanism that LPC exclusively uses. This enables ALPC ports high-speed communication which automatically balances the number of messages and threads. Additionally, ALPC messages can be batched together so as to minimize user-mode/kernel-mode switches.

Known usage
(A)LPC is used heavily in communication between internal subsystems in Windows NT. The Win32 subsystem uses (A)LPC heavily for communication between client and the subsystem server (CSRSS). Quick LPC was introduced in version 3.51 of Windows NT to make these calls faster. This method was largely abandoned in version 4.0 in favor of moving the performance critical server portions into kernel mode (win32k.sys).

The Local Security Authority Subsystem Service (LSASS), Session Manager (SMSS), and Service Control Manager all use (A)LPC ports directly to communicate with client processes. Winlogon and the Security Reference Monitor use it to communicate with the LSASS process.

As mentioned, Microsoft RPC can use (A)LPC as a transport when the client and server are both on the same machine. Many services that are designed to communicate only on the local computer use (A)LPC as the only transport through RPC. The implementation of remote OLE and DCOM in many cases uses (A)LPC for local communication as well.

See also
 Doors
 Remote procedure call

Notes

References

External links
  — Includes explanation of undocumented functions
 LPC Communication

Windows communication and services
Inter-process communication
로컬 프로시저 호출(, LPC, 또는 Lightweight Procedure Call나 Local Inter-Process Communication라고도 함)은 내부의 문서화되어 있지 않은, 프로세스 간 통신(IPC) 기능이다. 이것은 프로세스들 간의 경량 프로세스 간 통신을 목적으로 윈도우 NT 커널에서 제공한다. 윈도우 비스타의 경우 LPC는 빠른 속도의 통신 방법을 제공하기 위해 Advanced Local Procedure Call (ALPC)로 재작성되었다. 이것은 효율적으로 사용자 모드 드라이버 프레임워크를 구현한다. ALPC의 유저 모드 부분은 executive 내부의 UMDF의 구성요소와의 효율적인 통신을 필요로 한다.

(A)LPC 인터페이스는 윈도우 NT의 문서화되지 않은 네이티브 API의 한 부분이며, 응용 프로그램이 직접적으로 사용할 수 없다. 그러나 아래의 예처럼 간접적으로 사용될 수 있다.
 같은 머신의 프로세스들끼리 서로 통신할 때처럼 마이크로소프트 RPC API를 사용하는 경우.
 (A)LPC로 구현된 Windows API를 호출할 때.

구현 
(A)LPC는 커널의 안전한 포트 객체들을 사용하여 구현되며, 연결 상대방 프로세스의 식별을 허락한다. 각 메시지들 또한 안전하다. (응용 프로그램들은 메시지마다 SIDs를 세팅하며, (A)LPC 메시지와 관련된 토큰 내부의 security contest가 바뀌었는지를 테스트한다.

서버와 클라이언트 사이의 전형적인 통신 시나리오는 아래와 같다.
 먼저 서버 프로세스는 named server connection port 객체를 생성하고 클라이언트의 연결을 기다린다.
 클라이언트는 연결 메시지를 보냄으로써 알려진 포트에 연결을 요청한다.
 만약 서버가 연결을 수용할 경우 두 unnamed  포트들이 생성된다.
 클라이언트 통신 포트 - 특정한 서버와의 통신을 위해 클라이언트 쓰레드에서 쓰인다.
 서버 통신 포트 - 특정한 클라이언트와 통신하기 위해 서버에서 쓰인다. 클라이언트 마다 각 포트들이 생성된다.
 클라이언트는 클라이언트 통신 포트 핸들을 받고, 서버는 서버 통신 포트 핸들을 받으며, 프로세스 사이의 통신 채널이 확립된다.
(A)LPC는 서버와 클라이언트 간의 메시지 교환에 대한 아래의 세 가지 모드를 지원한다.
 작은 메시지들 (256 바이트 이하)을 위해 커널은 프로세스들 간의 메시지 버퍼를 복사한다. 이것은 보내는 프로세스의 주소 공간 부터 시스템 주소 공간까지, 그리고 그곳부터 받는 프로세스의 주소 공간까지이다.
 메시지가 256 바이트를 넘어설 경우, 공유된 메모리 섹션은 데이터 전송을 위해 사용되어야 한다.(A)LPC 서비스는 보내는 프로세스와 받는 프로세스들 간에 지도를 만들어 준다. 첫번째로 보내는 쪽은 공유된 메모리에 데이터를 놓고 받는 프로세스에게 공유된 메모리를 가리키며 통보를 한다.
 데이터가 너무 커서 공유된 섹션에 맞지 않을 때, 서버는 클라이언트의 주소 공간에서 직접적으로 데이터를 읽고 쓸 수 있다.
ALPC 과거 LPC 인터페이스보다 LPC가 배타적으로 사용하는 동기화 요청/답변 메커니즘 대신 I/O completion ports를 사용하여 설정할 수 있으므로 성능적으로 유리한 점이 있다. 이것은 메시지들과 쓰레드들의 수를 자동으로 균형을 맞춰, ALPC 포트들을 높은 속도로 통신할 수 있게 해준다. 게다가 ALPC 메시지들은 일괄처리될 수 있으므로 사용자 모드/커널 모드 전환을 최소화할 수 있다.

알려진 용법 
(A)LPC는 윈도우 NT의 내부 하위 시스템들 사이의 통신에서 많이 스인다. Win32 서브시스템은 (A)LPC를 클라이언트와 CSRSS 사이의 통신에서 많이 사용한다. Quick LPC는 윈도우 NT의 3.51 버전에서 이 호출들을 더 빠르게 하기 위해 도입되었다. 이 방식은 4.0 버전에서 대부분 버려졌는데, 서버의 성능을 중요시하는 부분들이 커널 모드(win32k.sys)로 넘어왔기 때문이다.

로컬 보안 인증 하위 시스템 서비스(LSASS : Local Security Authority Subsystem Service), 세션 관리자 하위 시스템(SMSS : Session Manager SubSystem), 그리고 서비스 제어 관리자(SCM : Service Control Manager) 모두 클라이언트 프로세스들과 통신을 위해 직접적으로 (A)LPC 포트들을 사용한다. 윈로그온과 보안 참조 모니터(SRM)는 LSASS 프로세스와의 통신을 위해 사용한다.

이미 언급했듯이, Microsoft RPC는 클라이언트와 서버가 같은 머신에 있는 경우 전송을 위해 (A)LPC를 사용할 수 있다. 많은 서비스들은 오직 RPC를 통해 단지 로컬 컴퓨터와 통신하기 위해 만들어졌다. 많은 경우에 Remote 객체 연결 삽입과 분산 컴포넌트 오브젝트 모델은 로컬 통신을 위해 (A)LPC를 사용한다.

같이 보기 

 원격 프로시저 호출

노트

각주

외부 링크 
  — Includes explanation of undocumented functions
 LPC Communication

윈도우 구성 요소
프로세스 간 통신