Using Async RPC with Your Client/Server Applications

Summary: Asynchronous Remote Procedure Call (RPC) is an extension of the synchronous RPC mechanism. This article discusses asynchronous RPC in detail and includes a comparison between the two. (7 printed pages)

Contents

What Is Async RPC?
Sync vs. Async on the Client
Sync vs. Async on the Server
Transport Protocols
When To Use Async RPC
Features and Semantics
Changing an Existing RPC Client or Server
Overhead and Performance
Call Complete Notification with Async RPC
Conclusion

What Is Async RPC?

Asynchronous Remote Procedure Call (RPC) is an extension of the synchronous RPC mechanism. In synchronous RPC the thread that issued the RPC call blocks the client until the RPC call is complete. Async RPC allows the thread that issued the call to continue execution and pick up the results at a later time. Similarly, on an async RPC server the logical RPC call can continue even after the dispatched call returns from the application code into the RPC runtime (manager routine), as shown in Figure 2.

Figure 1. Synchronous RPC

1. Call is issued by the application.
2. The RPC runtime sends the call to the server, on behalf of the client. Meanwhile, the client thread that issued the RPC call is stuck in the RPC runtime waiting for the call to complete.
3. The call is dispatched by the server side RPC runtime. The server application then executes the remote call.
4. Control returns back to the server RPC runtime.
5. Server RPC runtime sends the reply to client.
6. The client thread unblocks. The RPC call is complete.

Figure 2. Async RPC

1. The client submits Async RPC call. Control returns back to the client thread. The thread is free to continue with other work.
2. RPC runtime sends request to the server, on behalf of the client.
3. Request is dispatched to the server. The server application begins execution of the remote call. Control returns back to the server RPC runtime, but the server side call is not complete.
4. Server completes the call.
5. Reply is sent back to the client.
6. Client is notified that reply has arrived.
7. Client calls back into the RPC runtime and picks up the reply. At this point, the Async RPC is complete.

The following pseudocode (p-code) illustrates the difference between the two.

Sync vs. Async on the Client

Synchronous RPC

Function CallFoo ()
{
..
// Make the synchronous RPC call
x  =  Foo(a, b, c);
// When we get here, the synchronous RPC call is complete. 
// The return value and the [out] parameters are valid. 
}

Asynchronous RPC

Function SubmitFoo ()
{
..
// Submit the Async RPC call
// initialize the Async handle
RpcAsyncInitializeHandle(pAsync);
Foo (pAsync, a, b, c);
..
// Do other work
}

Function FooComplete ()
{
// When the app is notified the above RPC call is complete
Status = RpcAsyncCompleteCall (pAsync, &x);
// Return value and out parameters are valid here.
}

Sync vs. Async on the Server

Synchronous RPC

FooManagerRoutine ()
{
// This is remote application code.
// Do the work and fall back into the RPC runtime.
}

Asynchronous RPC

FooAsyncManagerRoutine (pAsync)
{
// This is where the logical call starts
// Do some work
// Fall back into the RPC runtime. The logical RPC call is still not complete
//
}

CompleteFooAsyncCall ()
{
// The logical call is about to be complete
Status = RpcAsyncCompleteCall (pAsync, &retval);
// The logical call is complete. The async handle has become invalid
}

Transport Protocols

Async RPC is supported on all transport protocols on which sync RPC is currently supported.

When To Use Async RPC

Client

It is useful to use async RPC on the client in the following cases:

• The thread is a UI thread, and it can't afford to block on the RPC (because the UI will freeze). When a thread makes a synchronous RPC call, it is stuck in the RPC runtime until the RPC call completes. If the thread that is making the RPC call can't afford to block, it shouldn't be making a synchronous RPC call. For example, if the thread is a UI thread (that is, it has a message pump), it cannot afford to block in an RPC. If it does, the UI will hang until the RPC is complete.
• The remote procedure call will take a while to complete and the client can do other work on the thread before it needs the results of this RPC.
• The client needs to make simultaneous calls to one or more servers. Using async RPC is much better than spinning off threads to do the same. For example, if a client wants to make simultaneous synchronous RPC calls to four servers, it cannot do so with one thread. It has to spin off at least three threads and make an RPC call in each thread. However, if it is using async RPC, it can make all four calls on the same thread and then wait for all of them.

Server

It is useful to use async RPC on the server in the following cases:

• The processing of the call will take a long time to complete (especially if it blocks). Instead of just processing the call in the dispatch (as with sync RPC), the app can use async RPC on the server. When the call is received, it can be added to a work queue. When the work is complete, the async RPC can be completed (see Figure 2). If synchronous RPC is used, the server application will have a thread used up for every dispatched RPC call.
• The processing of the call depends on another asynchronous task. Instead of synchronously waiting for the task (as with synchronous RPC), the application can use async RPC. When an async RPC call is dispatched, the application can initiate the asynchronous task. The app can then use the completion of the asynchronous task to drive the completion of the async RPC.

Features and Semantics

Async RPC supports all features supported by synchronous RPC. However, there are some new/different semantics associated with using async RPC, including:

• Cancels in async RPC work differently. (See the Asynchronous RPC section in the Platform SDK located in the MSDN Library for details.)
• Distributed computing environment (DCE) pipes work differently on async RPC. (See the Asynchronous RPC section in the Platform SDK located in the MSDN Library for details.)
• Async RPC enforces causal ordering of remote procedure calls. If a thread issues three async RPC calls—A, B, C, in that order—the remote procedure call runtime will make sure they are dispatched in the order A, B, C on the server. This does not apply to synchronous calls because sync RPCs are blocking. The causal ordering semantics can be turned off.

Changing an Existing RPC Client or Server

Async RPC is wire-compatible with synchronous RPC. You can change just the client or the server to async and still interoperate with existing clients and servers.

Overhead and Performance

The overhead associated with each outstanding async RPC call is minimal. An async RPC call is 20-30 percent slower than a sync call. Async RPC should not be used as a direct replacement for sync RPC. It should be used when the situation warrants its use (see the section When To Use Async RPC earlier in this article). Although async RPC is slower in terms of time taken for a single call, overall throughput can be improved significantly by efficient usage (for example, with overlapped calls).

Call Complete Notification with Async RPC

Async RPC offers five different methods for getting call complete notification. The choice of which one to use depends on the design of the application using async RPC. The five methods include:

• Window handles
  This method is useful when the app has a UI thread and it is already handling different kinds of events in its WndProc, the function that handles dispatched window messages.
• APCs (asynchronous procedure calls)
  If the application is going to be in a wait state on the thread that issued the async RPC call, using APCs might be good.
• Polling
  This method is useful if the thread is actively doing work and does not want to block.
• Events
  This method is useful when the application want to do some work and block on one or more async RPCs.
• I/O completion ports
  This method is useful when the app is already using I/O completion ports, and wants to be notified of call completions on that port.

Conclusion

Async RPC is a powerful and convenient paradigm for distributed computing. Async RPC is wire compatible with synchronous RPC, and supports all the features supported by synchronous RPC. However it should not be used as a direct replacement for synchronous RPC. It should only be when it fits well with the architecture of the client/server application.