Although decoupling the protocols from Web Storage System increases the reliability, flexibility, and scalability of Exchange 2000, you must have a very fast method for the protocols to exchange data with Web Storage System. To facilitate the rapid transfer of information between the IIS process and Web Storage System, Exchange 2000 has a queuing layer called the Exchange Interprocess Communication Layer (ExIPC) that allows the IIS and Web Storage System processes to quickly exchange data.

The following figure shows a graphical representation of the ExIPC, including circular queues, protocol services in IIS (such as smtpsvc), and the corresponding ExIPC interface, or "protocol stub," in Web Storage System (such as exsmtp).

ExIPC is a high-performance interprocess communication facility. ExIPC uses shared memory from a shared memory heap to communicate between processes. ExIPC consists of a protocol dynamic-link library (DLL) that implements a binding facility, a shared memory heap, and a pair of queues based on shared memory. Note A heap is a portion of memory reserved for a program to temporarily store data structures whose existence or size is unknown until the program runs. The program can request free memory from the heap to hold such elements, use it as necessary, and later free this memory.
One of the key advantages of ExIPC is that, unlike most lightweight remote procedure calls (LRPCs), it functions asynchronously. This allows Exchange to allocate memory immediately after one portion of a process completes, which results in corresponding improvements in performance.

The ExIPC binding facility allows you to create and connect an arbitrary number of queues between two processes, such as the IIS and Web Storage System. This binding facility includes the Central Queue Manager that keeps track of the queues and processes with which a process is communicating. The facility is also used for unbinding and queue clean up in the event of a catastrophic failure on the other process.

Each protocol queue is circular and of a fixed size. During interprocess communications, data is stored in the shared memory heap, referenced by a data handle. The data handle is enqueued and dequeued, and the IIS or the store then references the portion of shared memory from the handle.

Each protocol has an ExIPC interface in Web Storage System. For example, the ExIPC protocol stub for POP3 is expop.dll. This component passes parameters (for example, a pointer to a message or an action) from Web Storage System to the ExIPC interface (drviis.dll) in the IIS process.

The following figure is a graphical representation of the ExIPC process for when a client checks for a message in Web Storage System.

The following steps illustrate the interprocess communication steps that ExIPC goes through when a client checks a mailbox on the server using a POP3 protocol application (such as Microsoft Outlook).

1. The client logs on to the server and gives the command to check e-mail.
2. A Request Mail Message #1 command is created on the IIS side.
3. IIS allocates an amount of shared memory from the shared memory heap for the request. A corresponding handle is assigned to that portion of the shared memory. The handle, which functions as a placeholder or pointer to a referenced portion of memory, is then placed into the circular memory queue (enqueued) in the direction of the Store.
4. On the Store side, the ExIPC DLL for POP3 checks for incoming POP3 requests. The DLL receives the Request Mail Message and removes the handle from the circular memory queue. The Store-side POP3 stub references the handle to the data in the shared memory heap.
5. If there are no failures or performance problems on the Store side, the ExIPC process is complete and the data is successfully communicated from the IIS to the Store. If a queue is full or the store has stopped, an error message is returned.
6. A response (the mail message) is generated on the Store side. The Store allocates the appropriate amount of shared memory for the response from the shared memory heap. A corresponding handle is assigned to that shared memory. The handle is then enqueued in the direction of the IIS.
7. The IIS removes the handle from the circular queue, references the shared memory, and binds them together.
8. If there are no failures or performance problems on the IIS side, the response is complete and the data is successfully communicated from the Store to IIS.