Pros/Cons of using Windows Post message along with shared memory for cross process communication

Hi,
We have a requirement to notify different clients (exe/processes, windows/MFC based UI) when certain values change in the system.
These values are stored in a file (which cannot be changed), and a server process shall poll these files for change in value and notify the clients whenever any change occurs. This notification shall happen via post message. The server would have stored the updated value in shared memory before notifying the clients. This values is either a long value or a string value of 250 uni code characters .
The flow shall be:
1> The server (notifier/publisher) would start on system start up. This server shall have a dummy window created (hidden) to receive post message notifications from clients.
2> The clients when launched or started shall subscribe/register themselves with the server using post message.
3> The clients shall find the server window name (using find window) and call post message on the server HWND to pass its own HWND as and its interested event ID as input value. (using WPARAM and LPARAM parameters of post message)
4> The server shall store the interested client's HWND and corresponding events in its memory in a map.
5> The server shall have a timer thread running for polling the file for any changes for sending notifications.
6> When value is changed, the server does a post message for particular events to interested clients using their HWND stored in their memory.
7> The client processes the post message from server and then decide to read the shared memory (based on name) to get the updated value to be displayed in its UI.
8> When client goes down, it shall unsubscribe itself with the server.
There might be max 4-6 clients at any point in time currently, its a windows machine and all clients shall be on the same machine.
I do understand that HWND value is only unique for a desktop, if there are multiple desktops, the HWND value need not be unique.
Also window's name need not be unique, hence find window done by the clients might get a different/duplicated window.
Also the notification from server to all the clients shall be sequential since there is no option of multi casting in this case. However post message in itself is asynchronous unlike send message which is blocking.
I would like to know the experts advice on using this approach and if there are any major concerns with this approach that they would like to highlight.

Thanks and regards,
Karrtik
LVL 15
Karrtik IyerSoftware ArchitectAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sarabandeCommented:
if you already have a server/service process permanently running and shared memory in memory mapped file, you could go completely without windows messages and handle the events and messages solely via shared memory. for that the server would create a 'slot' in the shared memory where new clients could add a request to connect to the server. synchronisation for this slot would be made using a mutex or semaphore (for example a named mutex created by CreateMutex function). if a client was accepted by the server, the server would provide shared memory for exchanging messages between the specific client and a server thread resonsible only for this connection. synchronisation could be done either by mutex or by "traffic light" flags (red-green for both server and client) in the shared memory.

another proved method is to using sockets (winsock). it has the advantage that client and server could reside on different computers even outside of the local network. here the server provides an socket where clients can connect to. for each accepted connection you would use a further socket (mostly with a server thread) where you could exchange messages using tcp/ip.

also combinations of the above or messgae/exchange by using windows messages + shared memory are valid, though from my experience a straight forward communication by means of sockets is the simplest and less error-prone method.

Sara

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Karrtik IyerSoftware ArchitectAuthor Commented:
Thanks for your wonderful comments Sara.
One more question,
So if we go with the approach of using only shared memory (without windows messaging), the each client shall have to wait for the event/mutex/semaphore to be released using WaitForSingleObject call, is that understanding, right?
In that case, if the client is a window based UI or dialog based UI and single threaded, this wait for single object call shall block the main UI thread itself, is that correct?
jkrCommented:
Since you are handling basically 'small' chunks of data, the concept seems legit. But also take a look at the other options you have, i.e. http://www.codeproject.com/Articles/13724/Windows-IPC ("Windows IPC"). For such a small amount of clients, I'd raher consider Named Pipes or Mailslots, since Windows messages (albeit WM_COPYDATA exists) was never thought for IPC. Also, you might want to do yourself a favor and not poll for changes in that file, but rather use a way to have the system infor you about that - line in https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx ("Obtaining Directory Change Notifications")
Fundamentals of JavaScript

Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.

Karrtik IyerSoftware ArchitectAuthor Commented:
Thanks JKR for your very good comments and suggestions.
Sara, any inputs from you for the questions that I asked on your previous comments?
Regards,
Karrtik
Karrtik IyerSoftware ArchitectAuthor Commented:
Excellent answers!
sarabandeCommented:
yes, when using shared memory, you could synchronize the exchange of data by means of event/mutex/semaphore. this surely is necessary at least until your server has reserved an exclusive piece of the memory solely for one client-server connection. if such an exclusive "slot" existed, however, you could exchange data without additional system resources and wait functions, but only by status flags which are maintained in the reserved slot itself. since any of server and client has its own part for writing and is only reading from the other part, the exchange would be safe without further synchronisation (though the latter could make the coding easier).

Sara
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.