|
The '''localLocal procedureInter-Process callCommunication'''<ref name="ntdebugging">{{cite web|url=https://docs.microsoft.com/en-us/archive/blogs/ntdebugging/lpc-local-procedure-calls-part-1-architecture|title=LPC (Local procedure calls) Part 1 architecture|website=[[Microsoft Docs]]}}</ref> ('''LPC''', often also referred to as '''lightweightLocal procedureProcedure callCall''') facilityor '''Lightweight Procedure Call''') is aan serviceinternal, undocumented [[inter-process communication]] facility provided by the [[Microsoft]] [[Windows NT]] [[Kernel (computeroperating sciencesystem)|kernel]] for light weightlightweight [[messageinter-process queuecommunication|IPC]] between [[process (computing)|process]]es on the same computer. TheAs LPCof interface[[Windows isVista]], partLPC ofhas Windowsbeen rewritten as NT's''Asynchronous undocumentedLocal [[NativeInter-Process API]]Communication'''<ref name="ntdebugging"/> ('''ALPC''', althoughoften italso can'''Advanced beLocal usedProcedure indirectlyCall''') in applicationsorder viato theprovide a high-speed scalable communication mechanism required to efficiently documentedimplement [[remoteUser-Mode procedureDriver callFramework]] system(UMDF), usingwhose theuser-mode NCALRPCparts transportrequire (whichan isefficient implementedcommunication bychannel LPC)with UMDF's components in the [[Architecture_of_Windows_NT#Executive|executive]].<ref>{{Harvcoltxt|Russinovich|Solomon|Ionescu|2009|p=201}}</ref>
The (A)LPC interface is part of Windows NT's undocumented [[Windows Native API|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., Awhich serverare process first creates a port objectsecurable (with a well known[[Access-control namelist|ACL]]s, and waits for clients toallowing connecte.g. Aonly clientspecific process[[Security thenIdentifier|SID]]s connectsto byuse opening that portthem) and sendingallow aidentification connect message. Ifof the serverprocess acceptson the connection,other aside new unnamed port object is created forof the connection. PortIndividual objectsmessages are also securable: kernelapplications objectscan thatset allowper-message aSIDs, processand toalso identifytest for changes of the processsecurity oncontext in the othertoken sideassociated ofwith the connection(A)LPC message.
The typical communication scenario between the server and the client is as follows:
For short messages (fewer than 304 bytes) the kernel copies the message buffers between processes. Longer messages require the creation of a shared memory section to transfer data, which the LPC service maps between the processes instead. ▼# 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:<ref>{{Harvcoltxt|Russinovich|Solomon|Ionescu|2009|p=203}}</ref>
A related method of [[inter-process communication]] known as "Quick LPC" uses shared memory for data transfer and special event pair objects for synchronization. Event pairs allow the called thread to continue the current quantum, reducing scheduling overhead and latency. A standard port object (or some other IPC mechanism) is needed for initial communication.
▲* For short messages (fewer than 304256 bytes) the kernel copies the message buffers between processes . Longer messages, requirefrom the creation[[address space]] of a sharedthe memorysending sectionprocess to transferthe data,system whichaddress thespace, LPCand servicefrom mapsthere betweento the processesreceiving process' address insteadspace.
* 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 [[Input/output completion port|I/O completion ports]] instead of synchronous request/reply mechanism that LPC exclusively uses.<ref>{{Harvcoltxt|Russinovich|Solomon|Ionescu|2009|p=204}}</ref> 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 useduses (A)LPC heavily for communication between client and the subsystem server ([[Client/Server Runtime Subsystem|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 [[Reference monitor|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 [[objectObject linkingLinking and embeddingEmbedding|OLE]] and [[Distributed Component Object Model|DCOM]] in many cases uses (A)LPC for local communication as well.
==See also==
* [[Doors (computing)|Doors]]
* [[Remote procedure call]]
==Notes==
{{reflist}}
==References==
* {{citation |first1=Prasad |last1=Dabak, |first2=Milind |last2=Borate, |first3=Sandeep |last3=Phadke. ''|title=Undocumented Windows NT.'' |publisher=[[Hungry Minds]], |year=1999. ISBN |isbn=0-7645-4569-8}}
* David{{citation A.|title=Windows® Solomon,Internals| edition=5th |first1=Mark E.|last1=Russinovich |author1-link=Mark Russinovich. ''Inside|first2=David Windows|last2=Solomon |first3=Alex |last3=Ionescu 2000.''|year=2009 |publisher=[[Microsoft Press. ISBN]] |isbn=978-0-7356-10212530-53}}
==External links==
* [{{webarchive |url=https://web.archive.org/web/20080612141354/http://www.windowsitlibrary.com/Content/356/08/toc.html |date=June 12, 2008 |title=Local Procedure Call] -}} — Includes explanation of undocumented functions
* [http://www.zezula.net/en/prog/lpc.html LPC Communication]
| 