Introduction to RPC on Windows, Part II - Explicit binding handles
(Page 5 of 5 )
Finally, Explicit binding handles allow for maximum control over the binding process. Client/server applications may benefit greatly from using explicit binding handles. Just as with implicit handles, explicit binding handles also enable your client application to select a server to execute calls for it, apart from enabling your client/server application to create an authenticated RPC communication session. When using explicit handles, your client may connect to more than one server at the same time and execute remote procedures on any of them one at a time. If the client is multithreaded and asynchronous, it can choose to connect to multiple servers and execute multiple remote procedures at the same time. We shall learn about the asynchronous mode of RPC in the next article.
But here the client needs to pass the explicit binding handle (it is mandatory!) as a parameter to each remote procedure call it makes and defines in the MIDL interface. With MS RPC, the handle is always the first parameter on each of remote procedures invoked. But depending on your requirements you may use the Microsoft extensions to RPC to specify the binding handle in other positions.
In order to create an explicit handle, declare the handle as a parameter to the remote calls in the IDL file. The Hello, World example can be redefined to use an explicit handle as shown:
/* IDL file for explicit handles */
[
uuid(2CBD1C41-8292-4bcc-B0E8-54145A626433),
version(1.0)
// Note that no handle here
]
interface IMine
{
void Foo([in] handle_t hExplicit,
[in, string] int* pVal);
}
You can always choose to mix explicit and implicit handles in a single interface depending on your needs. A very simple rule is followed here: if a function consumes an explicit handle as its parameter, that handle will be used, otherwise the default implicit handle will be used.
Using Context and Binding Handles in your Applications
Based on the above conditions you may use a binding handle in your own application and create/modify the interfaces appropriately. You must also modify the ACF file for using a particular type of binding handle because MIDL generates code based on not just the IDL but the ACF file as well. Personally, I still don’t understand the need for a separate file when this information itself could be inserted in the IDL; ij any case, it’s not a matter of concern.
Now we’re all set to write a full fledged RPC app and shall do so in the next article.
Oh, one final note: if the server becomes unavailable or crashes, the client application should call the function RpcSmDestroyClientContext to free its context data.
Summary
Context and Binding handles in RPC are very powerful tools and they let us unleash their power in the way we want. They allow for developing object oriented and modular applications with RPC. As we have seen in the theory above, an object on the server can be tokenized to a context handle on the client, and using this encapsulation, the implementation of an object on the client can simply map functions directly to the server, by using context handles. But these are just the basics (really) and we shall see some code in execution (rather action) in the next article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
