The Wayback Machine - https://web.archive.org/web/20120615225715/http://www.codeguru.com:80/cpp/com-tech/atl/misc/article.php/c7387/Interprocess-Communication-Using-the-Running-Object-Table-ROT.htm

Interprocess Communication Using the Running Object Table (ROT)

Introduction

This article describes a simple technique to share data across multiple processes running on the same machine using the Running Object Table (ROT from here on).

Scenario

You must have come across scenarios where you need to share data across multiple applications quite often. Various approaches are available to share data:

  1. Using memory mapped files.
  2. Clipboard.
  3. DDE and so on.

All these methods are no doubt effective in the context they were intended, but come with certain basic problems. Synchronizing access to the data, ensuring client and server are alive and healthy at various stages, packing, and unpacking data from whatever custom formats are used and so forth.

To avoid this headache, I have come upon a pretty simple approach to sharing data. Basically, what this entails is that each process, when launched, creates a single instance of a common component, ICommHelper, and adds this interface with the ROT using a Server Name prefixed with a filter (a hard coded string). I prompt the user for a server name; you would probably need to come up with an algorithmto generate the Server Name based on the application name, instance handle, process ID, server that the user has logged in to (if it is a client/server app), as a moniker. The ICommHelper interface provides methods to add and remove itself from the ROT.

The AppViewer process can enumerate the ICommHelper interfaces present in the ROT using the prefixed filter, and from this can get the Server name of the SampleServer process. So, the user can enumerate the SampleServer instances running on the machine. If the user wants to send data from the AppViewer (to any SampleServer) process, the AppViewer process queries the ROT to retrieve the ICommHelper interface pointer registered by the selected SampleServer application.

Once the ICommHelper interface is retrieved, the AppViewer can invoke the SendData method to transfer data to the selected SampleServer process. (The action to be performed by the SampleServer application, which will need to be modified as per your requirements, of course. This can be done synchronously or asynchronously.)

And voilà—your data has been transferred!

And, whenever the target application shuts down, the IRProcComm interface will need to be removed from the ROT.

Source Code Layout

  1. IPCHelper—DLL that hosts the COM Component IProcComm.
  2. TargetApp—MFC Dialog application that creates an instance of IProcComm and registers it with the ROT.
  3. SourceApp—MFC Dialog application that retrieves the IProcComm interface from the ROT and invokes the SendData method.

About the Author

Raghupathy Srinivasan

just a run of the mill code monkey aspiring to be a grease monkey. i write articles infrequently and blog on http://quixver.blogspot.com/

Downloads

IT Offers

Comments

  • Problems debuging the IPCHelper DLL.

    Posted by subzero73 on 01/08/2009 11:47am

    Great Job. I'm trying to debug and step in to the IPCHelper DLL code with no success. It seems the symbols are not loading! Any reasons why? My other apps/dll'ss work fine. Best Regards, Chris

    • Problem found

      Posted by subzero73 on 01/08/2009 12:21pm

      I just reallize i was trying to step in the IPCHelper Dll in the AppViewer Application, but that's only a link to the real DLL instance, where it's in the SampleServer Application.

      Reply
    Reply
  • How's about performance in real time applications

    Posted by Pkadian on 01/26/2006 07:41am

    HI , It's nice to share the instance , but I jus want to know (If i m right) , What's about the performance to enumrate the instabce in ROT every time , whenever to SendData(..). Or to keep an instance of server on Client appliaction as an storage. regards, Pardeep Kadian

    • re:How's about performance in real time applications

      Posted by raghupathys on 01/26/2006 10:12am

      You dont need to enumerate every time. You can just cache your moniker, and call IRunningObjectTable::GetObject to retrieve your server interface. Performance is pretty decent, but of course you will need to profile your app and check if it meets your requirements.
      Caching the server interface is not a good idea.

      Reply
    Reply
  • New dimension

    Posted by kirants on 12/30/2005 05:00pm

    nicely written. Would've preferred to see some pictures explaining the communication mechanism though. I see no pictorial representation of objects and their relation/communication in any of your articles. It would really take your already excellent articles a notch higher :)

    • cool

      Posted by kirants on 01/03/2006 06:03pm

      cool.. good luck :)

      Reply
    • sorry for the lack of pix

      Posted by raghupathys on 12/31/2005 12:08am

      Hi Kiran, Thank you very much for your kind comments. And you are absolutely right, pictures would definitely help - and the reason I havent put up any images is because I'm such a lazy sod :( One of my new year resolutions is to put up some images for the articles. regds, raghu

      Reply
    Reply
  • New dimension!

    Posted by reachuraj on 06/16/2004 12:14am

    It looks to be a new way of inter process communication. As this is new technique, it would be good if you explain the theory behind this. Also why this technique should be adopted compared to other techniques? More light pls!

    Reply
  • Too Good.

    Posted by sjaykumar78 on 06/15/2004 04:25am

    This is technically funda stuff.Very good article..

    Reply

Whitepapers and More

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds