Synchronous Interprocess communication, A wrapper: Part I

• Download source files - 24 Kb

Introduction

In this article I will show yet another approach to IPC. I will demonstrate how the memory mapped files and couple of synchronization objects can be used to accomplish a Client/Server like interprocess communication.

Memory mapped file (swap file backed) is used as the shared memory medium. A mutex object is used to synchronize access to the shared memory.

Then two events are used to handle send/recv. which makes this possible: Client or server cannot send and receive from itself nor can either one of them exist alone.

This same Class can tell whether its current instance is a client or a server by checking who first initialzed the memory mapped file and other internal objects.

Background

You might have already used other IPC method, but when you will use this class you will notice that within two lines of code you will have two processes communicating together smoothly.

Multiple sends will be satisfied only when receive because I am not currently queueing buffers. Last sent buffer is the buffer that will be received.

Using the code

You can start using the code by simply initiating an instance of this class on both of your applications. In order to make them communicate together just specify a unique channel name for each processes pair. The CInterProcessCommunication constructor is defined as:

CInterProcessCommunication::CInterProcessCommunication(
     LPCTSTR SharedName,      DWORD Size,
     BOOL bHandlesInheritable)

The SharedName is the channel name that will be used by these two processes. The Size is the size of the biggest buffer that will be interchanged. The bHandlesInheritable is an optional parameter, you can ignore it.

Now include the class interface in your program and declare an instance:

// Process1Dlg.h : header file

//

.
.
.
/////////////////////////////////////////////////////////////////////////////

// CProcess1Dlg dialog

#include "../interprocesscommunication.h"


class CProcess1Dlg : public CDialog
{
// Construction

public:
    CInterProcessCommunication m_ipc;
    CProcess1Dlg(CWnd* pParent = NULL);    // standard constructor

    .
    .
    .

Now initiate the instance by specifying a channel and max size:

// Process1Dlg.cpp : implementation file

//


.
.
.
.
CProcess1Dlg::CProcess1Dlg(CWnd* pParent /*=NULL*/)
    : CDialog(CProcess1Dlg::IDD, pParent), m_ipc("mychannel", 1024)
{
    //{{AFX_DATA_INIT(CProcess1Dlg)

Now that you have defined the communication means, you still have to connect. In order to connect, another instance of CInterProcessCommunication must be initiated (following the same process as described above).

Now you can connect using the InterConnect()

void CProcess1Dlg::OnBtnConnect() 
{
  // try to connect

  if (!m_ipc.InterConnect())
  {
    MessageBox("Could not connect,
            probably no other instance is ready for connection");
  }    
}

Start the communication using the blocking mode methods void CInterProcessCommunication::ReceiveBuffer(LPVOID Buffer, DWORD Size) void CInterProcessCommunication::SendBuffer(LPVOID Buffer, DWORD Size) The receive method, when called and there is nothing to receive it will block execution until it receives something.

void CProcess1Dlg::OnBtnSayHello() 
{
  char buf[100];
  strcpy(buf, "Hello other process..\r\n");
  m_ipc.SendBuffer(buf, strlen(buf)+1);
}

void CProcess1Dlg::OnBtnReadReply() 
{
  char buf[100];

  // wait until you receive a reply.

  m_ipc.ReceiveBuffer(buf, sizeof(buf));    
  m_ctrlText.SetWindowText(buf); 
}

In the attached sources, follow this sequence to see a demo: Process1: press "Connect" Process2: press "Connect" Process1: press "Say Hello" Process1: press "Read reply" Process2: press "Receive salutation" Process2: press "Send reply"

Points of Interest

I wanted to pass buffers from processes to process easily and in a blocking (synchronous) matter. I had to learn about other IPC methods and as I discovered that they do not fit my needs I wrote this class. After all, hope you like it.

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 2 of 2 (Total in Forum: 2) (Refresh) FirstPrevNext

A few comments... peterchen 12:59 8 Apr '03   a) for the absolutely paranoid: MakeObjectNames should include a GUID to avoid unlikely name clashes b) serious startup race condition: - (A) tries OpenFileMapping, fails - (B) tries OpenFileMapping, fails - (A) decides to "create" the filemapping and act as server - (B) decides to "create" the filemapping and act as server similar race conditions exist at Interconnect. Solution: create the Mutex first, acquire the mutex, THEN try the Open/CreateFileMapping. Also, acquire all other shared resources (event handles) there. (btw. CreateFileMapping alone is enough - if MMF already exists, you will get access to it and GetLastError() returns ERROR_ALREADY_EXISTS. The same goes for CreateEvent/OpenEvent) c) the synchronozation might need some tuning, depending on the needs of the client (e.g. I might need to wait for the other process to have my message received). However, this can "explode" the complexity... Not to say I don't like your code (I do - otherwise I wouldn't have spent the time looking at it). Italian is a beautiful language. amare means to love, and amara bitter. sighist | Agile Programming | doxygen Sign In·View Thread·PermaLink 2.00/5 (2 votes) Re: A few comments... lallous 21:57 10 Apr '03   Hello Peter, Thank you for your constructive comment. I have added race condition checks as you suggested. Regards, Elias Sign In·View Thread·PermaLink

Last Visit: 19:16 5 Jul '09     Last Update: 19:16 5 Jul '09 1