CPP-Blog

Blog for Professional C++ Developers

[cpp-blog-com]

IPC – Shared Memory

Shared Memory is the fastest way to share some data between two processes. Concept is very simple - one process will create an area in the Memory which other process can access it.

Creating shared memory is not so difficult as it sounds - In general, it is kind of virtual file that one process creates, and second process read "content" of it.

Code for first process:

// buffer size for 1024 Unicode chars (wchar_t) #define BUF_SIZE 2048 int _tmain(int argc, _TCHAR* argv[]) { HANDLE hFile = ::CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, BUF_SIZE, L"Global\\www.cpp-blog.com"); if (NULL == hFile) { wprintf(L"CreateFileMapping Failed!"); return 1; } wchar_t* pBuf = (wchar_t*)::MapViewOfFile(hFile, FILE_MAP_ALL_ACCESS, 0, 0, BUF_SIZE); if (pBuf == NULL) { wprintf(L"MapViewOfFile Failed!\n"); ::CloseHandle(hFile); return 1; } // here pBuf is a buffer where we could store everything we need // NOTE: be carefully - this buffer can contain maximum BUF_SIZE/2 chars // let's write something in the buffer now const wchar_t* data = L"welcome to IPC introduction from www.cpp-blog.com"; ::CopyMemory((PVOID)pBuf, data, (wcslen(data) * sizeof(wchar_t))); _getwch(); // just "pause" ::UnmapViewOfFile(pBuf); ::CloseHandle(hFile); return 0; }

#define BUF_SIZE 2048 int _tmain(int argc, _TCHAR* argv[]) { // here we have to use the same name HANDLE hFile = ::OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, L"Global\\www.cpp-blog.com"); if (NULL == hFile) { wprintf(L"OpenFileMapping Failed!"); return 1; } // now comes the same code like in on the server side wchar_t* pBuf = (wchar_t*)::MapViewOfFile(hFile, FILE_MAP_ALL_ACCESS, 0, 0, BUF_SIZE); if (pBuf == NULL) { wprintf(L"MapViewOfFile Failed!\n"); ::CloseHandle(hFile); return 1; } wprintf(L"Server told us : %s\n", pBuf); ::UnmapViewOfFile(pBuf); ::CloseHandle(hFile); return 0; }

Here, very important is the name of the file (Global\www.cpp-blog.com) and Buffer size (2048). Server and Client must know those values to be able to share some data. "Global\" prefix/namespace is required for sharing memory between two processes. In this case windows will "register" name in global mapping table accessible for all programs running on the system.

Synchronization

The most difficult thing using Shared Memory IPC is a synchronization. Server doesn't know when Client is finished with reading data, but must keep memory valid all the time. Client could write also something in the memory, but it must inform server when reading is finished.

You can use additional windows messages (check previous blog post) to inform other side when something new is in the buffer, but I prefer other way - using Windows Synchronization Objects.

Main synchronization objects are Event, Mutex and Semaphore.

Event - notifies when something happens - one side can wait for event, and other side can trigger it Mutex - some kind of a locking flag - only one process/thread could own it at the same time Semaphore - kind of a counter  - e.g. only 3 threads could access some resource at the same time

For our purposes we need two events (ServerNewData event and ClientReadFinish event) and one Mutex to prevent accessing to the shared memory at the same time.

ServerNewData event will be triggered from the Server when some new data are stored in a buffer. After that, server can continue, but will not write new data in the shared memory before ClientReadFinish event is triggered to avoid that old data are not overridden before client read it. Basically, mutex is not really required here because client will never read before ServerNewData is triggered and server will never write before ClientReadFinish, but I like to have a mutex for any kind of "shared" data I use.

We are going to build real example, where client is going to start server, and server will search for all files on the C drive and over shared memory give the data back to the client. Instead of plain wchar_t buffer we are going to use WIN32_FIND_DATA struct.

Client

#include "stdafx.h" #include int _tmain(int argc, _TCHAR* argv[]) { HANDLE hServerNewDataEvent = ::CreateEvent(NULL, FALSE, FALSE, L"Global\\IPC_Test_ServerNewData"); HANDLE hClientReadFinish = ::CreateEvent(NULL, FALSE, TRUE, L"Global\\IPC_Test_ClientReadFinish"); HANDLE hLockMutex = ::CreateMutex(NULL, TRUE, L"Global\\IPC_Test_LockMutex"); if (!hServerNewDataEvent || !hClientReadFinish || !hLockMutex) { wprintf(L"Can not get sync handles!\n"); return 1; } const size_t bufferSize = sizeof(WIN32_FIND_DATA); HANDLE hFile = ::CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, bufferSize, L"Global\\www.cpp-blog.com"); if (NULL == hFile) { wprintf(L"CreateFileMapping Failed!"); ::CloseHandle(hClientReadFinish); ::CloseHandle(hServerNewDataEvent); ::CloseHandle(hLockMutex); return 1; } WIN32_FIND_DATA* buff = (WIN32_FIND_DATA*)::MapViewOfFile(hFile, FILE_MAP_ALL_ACCESS, 0, 0, bufferSize); if (buff == NULL) { wprintf(L"MapViewOfFile Failed!\n"); ::CloseHandle(hFile); ::CloseHandle(hClientReadFinish); ::CloseHandle(hServerNewDataEvent); ::CloseHandle(hLockMutex); return 1; } // start another process SHELLEXECUTEINFO sii; ::ZeroMemory(&sii, sizeof(sii)); sii.cbSize = sizeof(sii); sii.lpVerb = L"open"; sii.nShow = SW_SHOW; sii.lpFile = L"C:\\Sources\\IPC_SharedMemory\\Debug\\IPC_SharedMemory_Server.exe"; // allow server to write data to the memory ::SetEvent(hClientReadFinish); ::ReleaseMutex(hLockMutex); BOOL bExecuted = ::ShellExecuteEx(&sii); if (bExecuted) { bool bRun = true; while(WAIT_OBJECT_0 == ::WaitForSingleObject(hServerNewDataEvent, INFINITE)) { DWORD dwRes = ::WaitForSingleObject(hLockMutex, INFINITE); if (dwRes != WAIT_OBJECT_0) break; if (0 == wcscmp(buff->cFileName, L"")) bRun = false; else wprintf(L"File found : %s\n", buff->cFileName); ::ReleaseMutex(hLockMutex); ::SetEvent(hClientReadFinish); if (!bRun) break; } wprintf(L"Done.\n"); } else wprintf(L"Can't start Server\n"); ::UnmapViewOfFile(buff); ::CloseHandle(hFile); ::CloseHandle(hClientReadFinish); ::CloseHandle(hServerNewDataEvent); ::CloseHandle(hLockMutex); return 0; }

Server

#include "stdafx.h" #include HANDLE g_hServerNewDataEvent = NULL; HANDLE g_hClientReadFinish = NULL; HANDLE g_hLockMutex = NULL; WIN32_FIND_DATA* g_buff = NULL; typedef bool (*CallbackFnct)(const WIN32_FIND_DATA&); bool FileFoundCallback(const WIN32_FIND_DATA &data) { DWORD dwRes = ::WaitForSingleObject(g_hClientReadFinish, 5000); if (dwRes != WAIT_OBJECT_0) return false; // break operation DWORD dwRes2 = ::WaitForSingleObject(g_hLockMutex, INFINITE); if (dwRes2 != WAIT_OBJECT_0) return false; // here we own the mutex, and we can copy our data to the shared memory ::CopyMemory(g_buff, &data, sizeof(WIN32_FIND_DATA)); ::ReleaseMutex(g_hLockMutex); ::SetEvent(g_hServerNewDataEvent); return true; } bool FindFile(const wchar_t* strSearch, CallbackFnct fnct) { WIN32_FIND_DATA findData; wchar_t strFullSearch[MAX_PATH]; wcscpy(strFullSearch, strSearch); wcscat(strFullSearch, L"*.*"); bool bRun = true; HANDLE hFind = ::FindFirstFile(strFullSearch, &findData); if (INVALID_HANDLE_VALUE != hFind) { do { if (0 != wcscmp(findData.cFileName, L"..") && 0 != wcscmp(findData.cFileName, L".")) { if (findData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { // recursion wchar_t strFullSearch[MAX_PATH]; wcscpy(strFullSearch, strSearch); wcscat(strFullSearch, findData.cFileName); wcscat(strFullSearch, L"\\"); bRun = FindFile(strFullSearch, fnct); } else bRun = fnct(findData); } } while (bRun && ::FindNextFile(hFind, &findData)); ::FindClose(hFind); } return bRun; } int _tmain(int argc, _TCHAR* argv[]) { wprintf(L"hallo from server\n"); g_hServerNewDataEvent = ::OpenEvent(EVENT_MODIFY_STATE, FALSE, L"Global\\IPC_Test_ServerNewData"); g_hClientReadFinish = ::OpenEvent(SYNCHRONIZE, FALSE, L"Global\\IPC_Test_ClientReadFinish"); g_hLockMutex = ::OpenMutex(WRITE_OWNER|SYNCHRONIZE, FALSE, L"Global\\IPC_Test_LockMutex"); if (!g_hServerNewDataEvent || !g_hClientReadFinish || !g_hLockMutex) { wprintf(L"Can not get sync handles!\n"); return 1; } const size_t bufferSize = sizeof(WIN32_FIND_DATA); HANDLE hFile = ::OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, L"Global\\www.cpp-blog.com"); if (NULL == hFile) { wprintf(L"OpenFileMapping Failed!"); ::CloseHandle(g_hServerNewDataEvent); ::CloseHandle(g_hClientReadFinish); ::CloseHandle(g_hLockMutex); return 1; } g_buff = (WIN32_FIND_DATA*)::MapViewOfFile(hFile, FILE_MAP_ALL_ACCESS, 0, 0, bufferSize); if (g_buff == NULL) { wprintf(L"MapViewOfFile Failed!\n"); ::CloseHandle(hFile); ::CloseHandle(g_hServerNewDataEvent); ::CloseHandle(g_hClientReadFinish); ::CloseHandle(g_hLockMutex); return 1; } bool bOk = FindFile(L"C:\\", FileFoundCallback); if (bOk) { // send one empty "data" to inform that we are done WIN32_FIND_DATA empty_wfd; ZeroMemory(&empty_wfd, sizeof(empty_wfd)); FileFoundCallback(empty_wfd); // wait for the last client read ::WaitForSingleObject(g_hClientReadFinish, 5000); } ::UnmapViewOfFile(g_buff); ::CloseHandle(hFile); ::CloseHandle(g_hServerNewDataEvent); ::CloseHandle(g_hClientReadFinish); ::CloseHandle(g_hLockMutex); wprintf(L"server done\n"); return 0; }

Conclusion

Using Shared Memory for Inter Process communication is not the simplest way for IPC, but it's definitely the fastest. Here, there is more to do with synchronization then with sharing memory itself. In my exemple we can get some "unexpected" problems in case when server side is not running as the same user. In this case correct access permissions should be used in CreateMutex and CreateEvent methods.

Pros

it's fast

no special windows are needed or window message loops

allocation and sharing memory is relative simple (few methods only)

all methods are native from WinAPI, and it can be used from almost every language

Cons

Synchronization is very complex

Transfer of huge data is not recommended (no stream support)

difficult to configure security issues

transfer different kind (dynamic) of data is not so simple

not so many good examples available

Next time we are going to check what COM can provide for us.

See you.

[cpp-blog-com]

IPC - Windows Messages

One of the most popular way of Inter-Process Communication is over Windows Messages using SendMessage and PostMessage functions.

In this case one process creates new (usually invisible) window and “listen” for specific window messages. Second process needs to know window handle of the first process – usually can get it over command line parameter or to use FindWindow function to find the window with specific title or created with specific Class name. The process that listen to the messages we are going to call the Server, and the one that will send the messages we could call the Client.

Server side

Creating new invisible window is not a big deal:

WNDCLASS wc; ZeroMemory(&wc, sizeof(wc)); wc.lpfnWndProc = WndProc; wc.hInstance = ::GetModuleHandle(NULL); wc.lpszClassName = L"www.cpp-blog.com"; // first we need to register our window class // - the most impotent member is a pointer to WndProc function if (!::RegisterClass(&wc)) { wprintf(L"RegisterClass failed!\n"); return 1; } HWND hWnd = ::CreateWindow(L"www.cpp-blog.com", L"www.cpp-blog.com", 0, 0, 0, 0, 0, NULL, NULL, NULL, NULL); // here comes Message loop ...

... and our WndProc ...

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch(msg) { case WM_CLOSE: DestroyWindow(hwnd); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hwnd, msg, wParam, lParam); } return 0; }

If you have a trouble with Creating window and WndProc, check very good article about that here.

#define WM_CPPBLOGMSG  (WM_APP+0x001)

Client Side

Client side is even easier, just find handle and use SendMessage or PostMessage. Here is complete code of the one simple message:

#define WM_CPPBLOGMSG (WM_APP+0x001)   int _tmain(int argc, _TCHAR* argv[]) { HWND hServerWnd = ::FindWindow(L"www.cpp-blog.com", NULL); if (NULL == hServerWnd) { wprintf(L"Can't find Server window!\n"); return 1; }   ::PostMessage(hServerWnd, WM_CPPBLOGMSG, 123, 456);   return 0; }

It’s very simple … isn’t ?

Windows Vista & Windows 7

Under Windows Vista this wil not work in case that Server and Client are not running as the same user and with the same privileges (e.g. Server is Elevated). But in our scenario when we start second process to do some admin tasks for you, that second process will be Elevated and PostMessage will fail. Why? Security – you can NOT Send or Post message to higher privilege application windows.

Solution is to change Window Message Filter using ChangeWindowMessageFilter or ChangeWindowMessageFilterEx function.

simple call that method on the Server side:

ChangeWindowMessageFilter(WM_CPPBLOGMSG, MSGFLT_ADD);

 … will allow you to send message from Client to the Server process. Anyway, if you need to make runnable code on Windows XP/2000 too, you will have to use GetProcAddress for importing those functions instead of direct call, because function is available only under Windows Vista and higher.

Conclusion

Inter-Process communication over Windows Messages is probably the most simplest way, very easy to use, you can integrate without any problem in your existing window and use it with few extra lines of code. Under Vista or higher you have to set additional filter, but that is also not so difficult. Also bi-directional support could be made making client to act as a server too.

Pros

easy to use

easy to integrate in existing code

very good documented

many examples

could be used from almost every language or even script languages

Cons

low security – everyone could simulate or hook messages

it is possible to transfer only lParam/wParam but no binary data or strings*

no real bi-directional support

*For transfere binary data or strings you can use WM_COPYDATA

In next post, I’m going to describe how to use Shared Memory to exchange data between two processes.

See you soon.

[cpp-blog-com]

IPC – Inter Process Communication

Every of us developers had sometime needs for the communication between two processes. Either we need to start new process as a different user or to communication with installed service or even to share some data with process on the other computer in local network or over the Internet. In all those cases we need to involve some way of communication between two different processes – IPC.

In this post, I'm going to touch some solutions when the both processes are running on the same computer.

Why we need IPC?

With the Windows Vista we got User Elevation confirmation (popular named UAC dialog – User Account Dialog), that is more-less extended version of RunAs from Windows XP. New User Elevation is very simple – even when the user is a Local Administrator, programs are started with Limited privileges – some kind of virtual Administrator without real Admin rights. That process can't modify any system settings (e.g. Registry keys), can’t write to the system files nor to start/stop services. To do that, process must get Admin rights which mean that user must confirm UAC dialog.

You can enforce to start your program with an Elevated rights by adding correct manifest and this will prompt our user on every start for UAC confirmation - no, we don't want that. Those system modifications are not required every time that application is in use, and what if we want to have system tray app – UAC on windows start is not “cool” at all.

Solution : Start program as a normal (non elevated) user, and when we need admin rights we could start another process that will do “dirty” job for us. And there comes need to talk with that second process – that is why we need IPC.

We could start second process that will do something for us, and wait until it is finished. As a return value we could get process return code and we can transfer our data to that process over command line parameters. It is easy, and unfortunately many developers using this way for communication between two processes. I say unfortunately because this method is not effective and communication is only in one direction with the simple return value.

And what about more complex tasks, or the case when second process must “ask” something?

Advanced IPC Solutions

There are many different advanced solutions:

Windows Messages

Shared Memory

COM

Local Procedure Call (LPC)

XML/JSON RPC (Remote Procedure Calls)

Windows RPC

Named Pipes

TCP/IP

CORBA

Every of them have some advantages and disadvantages and deciding which solution to us depends of the concrete problem.

More about concrete solutions I will write in my next post… see you soon.