tags:

views:

182

answers:

3

Hello, we have a windows service running and we also have a console application that we use to configure this service, we also have an option to see some log being recorded.

The very ugly thing with this is that this communication is made by a text file, the console app writes to a text file and the service reads it and vice versa.

What would you use for this communication? TCP/IP is not an option because the console app will be used for the local running service only.

Windows API SendMessage should be the way to go?

thanks!

+2  A: 

I would recommend WCF as the first thing to consider for all comms on windows if using .net as its built for this kind of thing and its relatively easy to use. Since you're excluding TCP, I'd suggest using the Named Pipes Binding.

There are also an number of windows comms apis available for intra-machine comms. Named Pipes (as mentioned), MailSlots, Shared Memory (Memory Mapped files) etc.

My suggestion would be be use Named Pipes either with WCF or natively.

Preet Sangha
A: 

Shared Memory? See here for an article on Codeproject, here's another fastipc article on the same site. There's a blog entry detailing on how to use a memory mapped file for sharing via a wrapper.

Hope this helps, Best regards, Tom.

tommieb75
+1  A: 

You run less risk of deadlocks if you use non-blocking methods of message passing. PostMessage, or SendNotifyMessage are better than SendMessage because they don't block the caller.

But they depend on the service having a window handle. Does it?

You can also use the WM_COPYDATA message, to pass more than just a wParam a lParam. If you use this message with PostMessage, you need to be careful not to free the memory until the receiver is done with it. It's safest to use SendMessage for WM_COPYDATA.

John Knoeller
+1 - I'm not sure what the OP is using for their coding, but I've used WM_COPYDATA PostMessage for comms between processes in the past. If memory is assigned right, you set it up for the receiver to deallocate it on message reception. This keps it asynchronous.
ChrisBD
Note that the `PostMessage` approach fails on Vista and later in some circumstances due to session 0 isolation - see e.g. http://blogs.technet.com/askperf/archive/2007/04/27/application-compatibility-session-0-isolation.aspx
romkyns