Last time we saw Pipes as the mechanism for inter process communication. This time we will look at two more important IPC mechanisms. Mail slots and RPC. There are many other's too which I listed last time, but we won't cover these to save time. The study of those will be up to you to pursue.

A mail slot is a psuedofile which resides in memory and can be accessed using standard file access functions. A mail slot usually is a one way communication channel. All mail slots are identified by a unique name. A server process usually creates a mail slot after which some memory (should be less than 64K) is allocated for it. Now any client which knows the name of this mail slot can send messages (mails) to this mail slot. These messages are pushed in the queue to the mail slot which the server can read and access. Messages smaller than 425 bytes are sent over UDP while greater than 425 bytes are sent using TCP. Mail slots can also be used to broadcast messages, that is, one client at a time can send messages to multiple mail slots.

As we saw in named pipes, mail slots have names in following format:

Names are not case sensitive and can contain any characters/forms supported by file naming conventions, for example you can have a mail slot name such as "\\.\mailslot\test\testone" etc. There is only one special function for mail slot communication, other functions are standard file handling functions (createfile()/readfile()/writefile()) etc. The function CreateMailslot() is used by a server process to create a mail slot for itself. The first parameter to this function is the name of the mail slot. You can lookup the description etc, of these functions in MSDN.

Once a mail slot is created, the server process can call ReadFile() to read messages from this mail slot. On the client side, a client will first use CreateFile() function to get a handle to the already existing mail slot, it will then use WriteFile() function to write a message to the mail slot. As I said, mail slots are a one way traffic, so a server cannot use WriteFile() over a mail slot and a client cannot use ReadFile() over same handle.

For two way communication (duplex), both clients and server will have to create one mail slot each. You can get more information about mail slots and it's functions in MSDN and Platform SDK samples.

RPC is a relatively old IPC mechanism. RPC stands for remote procedure call. RPC is similar to any other function call, but differs on one account. Usually when you call a function in your program, it executes on same machine on which it was called. And on most occasions, it executes in the same process in which it was called. RPC differs, that the caller and the called function, can be in different processes, and what's more, they can be on different machines. Most OS's provides some level of support for RPC. Windows too. Like in most other IPC mechanisms, in RPC too, one process is a server process and other one is a client of that. Usually, the server process is the one where the RPC executes, and the client is the one which calls that RPC. When an RPC is called, the parameters passed to it by the client, are sent over the network to the server. The server extracts these and passes them to the actual executing function. The function executes, and produces some output parameters, or some return values. These are returned back to the client. The actual calling and execution of the RPC process is actually hidden from you by OS supplied stub programs which you have to use in your applications. Unlike other IPC mechanisms, RPC does not have names or naming conventions. RPC uses GUID. A GUID is a globally unique identifier, which is guaranteed to be unique universally, whenever it's generated.

So let's see the steps for creation of RPC server first. I won't go into details of these, you can follow that later, I will just explain briefly, what steps you need to perform to setup an RPC server:

As you must have guessed by now, this same GUID will be used by the client also. The GUID can be created in many ways, there are different tools for this. A tool named GUIDGEN.exe which comes with Visual Studio can be used to generate a GUID. You should experiment with this tool and also find out other ways to generate a GUID.

2. Once we have a GUID, we create an IDL file. An IDL file is an interface definition language file which defines what interfaces will be exposed by the RPC server and what will be used by the RPC client. Note that IDL is not specific to RPC, it's commonly used in COM/DCOM.

3. Once you have an IDL with GUID, you define an interface in it using IDL syntax which is mostly similar to C++, but differs on a few accounts. You should explore what is the syntax of the IDL. Here's a sample IDL for our test purposes:

Note that the first part is the GUID definition. The next part defines an interface named MyInterface which has one function Add, which takes two integers and returns another.

4. Next part is compiling our IDL to generate stubs which will be used by both, our client application as well as server. You can use MIDL, which is Microsoft IDL compiler to generate stubs from this IDL file. Note that, you will have to change the GUID for your own testing, this one will conflict with my test application.

5. The MIDL compiler will generate both, server stub as well as client stub. You will add the server stub to your server project, and client stub to your client project.

6. Now you will implement the Add() function in the server which is trivial. Next, you will register the interface using RpcServerRegisterIf(), and start your RCP server using RpcServerListen(). You should explore about these and other RPC helper functions in MSDN. After this your RPC server is not listening for client connections.

2. Now first, you will need to bind to the interface of the listening RPC server. Look at MSDN for RPC binding functions for client. All RPC functions start with RPC.

3. Once bound, you simply call the functions (Add) as if it's defined in your own application, the parameters will be passed to the server which will execute the function and the result will be returned back to you.

I on purpose omitted many details about RPC here, specially the supporting API's etc. You should find out about those on your own and try to write a very simple RPC server/client pair to get confidence in RPC. Good thing about RPC, is that it's language independent, most modern languages have RPC support, so do most OS's.

This should be sufficient for the week. With this we will also conclude our IPC mechanisms, there are others which we have not covered and I would like you to go through those on your own. We will cover some other topic in next mail.

Bpath Counter