IPC Recommendation

[davewolfs]

Hi everyone,

I am new to C#, my background is primarily in Java so I am hoping that I can get some suggestions here to put me on the right track.

Currently I am trying to get an application that I have written in C# to communicate with a 3rd party application.

The reason for this is that the DLL interface provided by the 3rd party does not allow me to send some of the information that I require.

Therefor what I am trying to do is to submit the data that I need and immediately make the DLL call. (The idea is that when code is executed after the DLL call is made, the additional required information will be available)

Because the data is being sent in succession, I am going to need the receiving side to accumulate this data (i.e. add to stack) since by the time the application goes to receive the data more data may have already arrived.

So with that said, if I am looking to send data to my 3rd party app using something such as IPC and need an event to be triggered when the data is received what would be a good place to start, perhaps there is a decent tutorial or someone has a code example of doing this.

The alternative to having the event trigger would be having the receiving app notify the other application that it has received the data and can therefore proceed.

I appreciate your input.

[davewolfs]

Just read up on WM_COPYDATA, is there any reason why I wouldn't want to use this?

[davewolfs]

Unfortunately, I can't edit the post, but I should mention that the number of messages per second could be 1000+. The messages themselves are extremely small, either a single long or small string.

[Arjay]

Just to make sure I have the correct scenario:

You have two apps, app A and app B and are loading a 3rd party dll in app B. You want to communicate between app A and app B.

Is this correct?

[davewolfs]

Just to make sure I have the correct scenario:

You have two apps, app A and app B and are loading a 3rd party dll in app B. You want to communicate between app A and app B.

Is this correct?

Yes.

App B would be my application, app A is the third party app.

App B makes a DLL call which triggers an event in app A and when this event is triggered app A must also have additional information (which I need to send over IPC, it is only a timestamp) which corresponds to this event which must also be sent by app B.

Ideally, before app B makes its next DLL call, it should have some sort of notification from A that it has received the additional information or A needs to queue data on a stack and keep pulling off the items each time the DLL call is made.

What is important is that the additional information corresponds with the DLL call (which is why that IPC call will always happen first). Also performance is a concern since their could potentially be hundreds of calls every couple of seconds.

[Arjay]

App B would be my application, app A is the third party app.

This is a different scenario to what I had in mind. If you own the source code to app A and app B (but not the 3rd party dll), then you can modify app A and app B to code the required notification functionality into both apps.

However, from what you are telling me, both app A and the dll is from a 3rd party and unless you have the source code for app A, you aren't going to add funtionality to app A.

[davewolfs]

App A support plugins that can be written and I have access to the parent forms here.

The plugin/extension in App A that I am writing is actually where I need my data and plan to implement the functionality.

I've done some more reading and either WM_COPYDATA or shared memory both seem to be potential options. Thoughts? If I am pushing thousands of calls per second, then I don't see how pipes could offer more performance.

I found this.

http://blogs.microsoft.co.il/blogs/p...ing-c-cli.aspx

And it looks like a decent way to share memory. One question if you have time to take a look at it, how is the initial handle that is created ever closed, or does the GC somehow handle this?

[Arjay]

Okay, now you're in business since app A supports plugins.

The memory mapped file approach would work. I have a C++ sample called SndLog/SndRcv that's in the bottom two articles listed in my subject line. This sample sends fake log data from one app to another using memory mapped files. You'll need to wrap the api's with pinvoke to use in C# like your link does.

Another option is to use a WCF web service. Unlike the older .Net 2.0 and earlier web services that had to be hosted in IIS, WCF services can be hosted in IIS, a windows or console app, or a windows service. Also, with WCF you have the option of two way communication (so the hosting process can send events to the client process).

What this means to you is that you can host the WCF service inside the plugin of app A or inside app B. Generally you'll host it inside the app that starts first. Then the second app just connects to the web service and makes the typical service method calls.

Creating and host a WCF service is pretty simple. If this sounds interesting, let me know.

[davewolfs]

Okay, now you're in business since app A supports plugins.

The memory mapped file approach would work. I have a C++ sample called SndLog/SndRcv that's in the bottom two articles listed in my subject line. This sample sends fake log data from one app to another using memory mapped files. You'll need to wrap the api's with pinvoke to use in C# like your link does.

Another option is to use a WCF web service. Unlike the older .Net 2.0 and earlier web services that had to be hosted in IIS, WCF services can be hosted in IIS, a windows or console app, or a windows service. Also, with WCF you have the option of two way communication (so the hosting process can send events to the client process).

What this means to you is that you can host the WCF service inside the plugin of app A or inside app B. Generally you'll host it inside the app that starts first. Then the second app just connects to the web service and makes the typical service method calls.

Creating and host a WCF service is pretty simple. If this sounds interesting, let me know.

If I go with the services route, isn't this a lot more overhead then I need? Why not use basic pipes if that is the case.

[Mutant_Fruit]

1000's of tiny messages a second is (at a wild guess) 5000 x 50 bytes which is 256kB/sec (give or take). No matter what method you use, that should be nowhere near stressful. So don't worry about the method of IPC until you actually benchmark and see that it's an issue.

[davewolfs]

So that said, should I just go with WCF since that is probably the simplest method?

[Mutant_Fruit]

Exactly. Your number 1 aim should be making it work in the easiest way possible. Your second aim should be to make it faster/better/more efficient.

[Arjay]

Exactly. Your number 1 aim should be making it work in the easiest way possible. Your second aim should be to make it faster/better/more efficient.

Excellent advice, Mutant.

[Arjay]

A previous poster asked for a solution for a single instance app where the second instance of the app should open an image file passed to it via the cmdline in the first instance.

WCF was used to pass the image path between the two instances.

For the source code, see my response in this post. http://www.codeguru.com/forum/showthread.php?t=487121