Windows® Internals, Sixth Edition, Part 1

Server connection port. A named port that is a server connection request point. Clients can connect to the server by connecting to this port.

Server communication port. An unnamed port a server uses to communicate with a particular client. The server has one such port per active client.

Client communication port. An unnamed port a particular client thread uses to communicate with a particular server.

Unconnected communication port. An unnamed port a client can use to communicate locally with itself.

ALPC follows a connection and communication model that’s somewhat reminiscent of BSD socket programming. A server first creates a server connection port (NtAlpcCreatePort), while a client attempts to connect to it (NtAlpcConnectPort). If the server was in a listening state, it receives a connection request message and can choose to accept it (NtAlpcAcceptPort). In doing so, both the client and server communication ports are created, and each respective endpoint process receives a handle to its communication port. Messages are then sent across this handle (NtAlpcSendWaitReceiveMessage), typically in a dedicated thread, so that the server can continue listening for connection requests on the original connection port (unless this server expects only one client).

The server also has the ability to deny the connection, either for security reasons or simply due to protocol or versioning issues. Because clients can send a custom payload with a connection request, this is usually used by various services to ensure that the correct client, or only one client, is talking to the server. If any anomalies are found, the server can reject the connection, and, optionally, return a payload containing information on why the client was rejected (allowing the client to take corrective action, if possible, or for debugging purposes).

Once a connection is made, a connection information structure (actually, a blob, as will be described shortly) stores the linkage between all the different ports, as shown in Figure 3-30.

Figure 3-30. Use of ALPC ports

Message Model

Using ALPC, a client and thread using blocking messages each take turns performing a loop around the NtAlpcSendWaitReplyPort system call, in which one side sends a request and waits for a reply while the other side does the opposite. However, because ALPC supports asynchronous messages, it’s possible for either side not to block and choose instead to perform some other runtime task and check for messages later (some of these methods will be described shortly). ALPC supports the following three methods of exchanging payloads sent with a message:

A message can be sent to another process through the standard double-buffering mechanism, in which the kernel maintains a copy of the message (copying it from the source process), switches to the target process, and copies the data from the kernel’s buffer. For compatibility, if legacy LPC is being used, only messages up to 256 bytes can be sent this way, while ALPC has the ability to allocate an extension buffer for messages up to ~64KB.

A message can be stored in an ALPC section object from which the client and server processes map views. (See Chapter 10 in Part 2 for more information on section mappings.)

A message can be stored in a message zone, which is an Memory Descriptor List (MDL) that backs the physical pages containing the data and that is mapped into the kernel’s address space.

An important side effect of the ability to send asynchronuos messages is that a message can be canceled—for example, when a request takes too long or the user has indicated that she wants to cancel the operation it implements. ALPC supports this with the NtAlpcCancelMessage system call.

An ALPC message can be on one of four different queues implemented by the ALPC port object:

Main queue. A message has been sent, and the client is processing it.

Pending queue. A message has been sent and the caller is waiting for a reply, but the reply has not yet been sent.

Large message queue. A message has been sent, but the caller’s buffer was too small to receive it. The caller gets another chance to allocate a larger buffer and request the message payload again.

Canceled queue. A message that was sent to the port, but has since been canceled.

Note that a fifth queue, called the wait queue, does not link messages together; instead, it links all the threads waiting on a message.

EXPERIMENT: Viewing Subsystem ALPC Port Objects