Interprocess Communication

  • Thread starter Thread starter Daniel
  • Start date Start date
D

Daniel

I search for a good way to communicate between processes. I have a main
application(might be more instances) and an tool that should exchange
information such as which user is logged in into the application and
more.

Now i'm doing it by sending API WM_COPYDATA messages with SendMessage.
Our users are identified by a Guid and getting the app user by sending
four WM_COPYDATA with kind a "GiveMeUserGuidPart0of4" and putting to
gether the 4 int values to a guid is kind a sick :/
Not to mention the fun if a application's main window get hidden and is
send to tray and therefore Process.MainWindowHandle gets null.

Any good idea to solve that correctly? Didn't do much with remoting,
would that be the thing to use or is it to oversized?

Thx in advance
 
Hi Daniel,

Remoting is certainly one way to go.

If you find it too complicated, you can implement your own simple
communication using Socket or TcpClient.

Both of the above will let you distribute your application between more
physical machines.

In my opinion, using WM_COPYDATA in year 2005 is one of the most
terrible things to do ;)

HTH,
Stefan
 
Hi,

If you are not satisfied with Remoting, try to use TCP/IP as Stefan
suggested, or NamedPipes, SharedMemory....

Recently, I wroted commercial library for Interprocess Communication for
..NET , and i can tell you that thru NamedPipes you can solve your problem.

Regards,
Josip Habjan, Croatia
URL: http://www.habjansoftware.com
 
Since i try to avoid API calls and Named pipes & Shared memory afaik
aren't implemented anywhere in the framework, i'll give the sockets a
try.
 
Since i try to stick to the mechanisms built into the framework, i'll
give the sockets a try.

TcpListener & TcpClient seems the classes for it. But which port to
use? Just take any high value and hope it's free or is there any way
name or register a port so i can somehow connect to
"localhost/MyApplicationServerPart". Or is that the reason for *named*
pipes? :)
 
You know what happens when Microsoft takes a really powerful communication
library and makes it easy for people to use? People look at it, say "that's
too easy" and they write their own.

Use remoting. It provides you all the mechanisms you need, is fully
debugged, and is ready to go right now.

Don't reinvent the wheel.

I recommend a book by Ingo Rammer called "Advanced .Net Remoting" to get you
going. You will be writing remoting code by the end of chapter two.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Daniel.

IPC per se is not possible using fully managed code in .NET 1.1. You can use
remoting to go over the TCP stack, but that has a performance penalty.

..NET 2.0 includes an IPCChannel which makes your life a lot easier.

I have implemented this very functionality in .NET 1.1 however by using
Win32 Api functions MoveMemory etc. in Kernel32.dll to help two processes
communicate. You can see the code as the Cache example (last example) in a
talk I gave on serialization. The reason I demo'ed it as a part of
serialization was because I wanted to make a point that "look if your biz
obejcts are serializable, you can do all this cool stuff".

Anyway, the download's here -
http://codebetter.com/blogs/sahil.malik/archive/2005/02/23/55923.aspx

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
 
Back
Top