IPC advice

  • Thread starter Thread starter Boni
  • Start date Start date
B

Boni

Dear all,
my application runs in 2 processes on the same machine. Now I need to send a
string from one process to another. One process is managed other is native.
The communication should work on any computer (even with firewalls)
I could write file in one process and read it in other but it seems to be
bad solution.
Could somebody advice me about the simple and fast solution.
Thanks a lot.
 
Dear all,
my application runs in 2 processes on the same machine. Now I need to send a
string from one process to another. One process is managed other is native.
The communication should work on any computer (even with firewalls)
I could write file in one process and read it in other but it seems to be
bad solution.
Could somebody advice me about the simple and fast solution.
Thanks a lot.

If it has to work on different computers, regardless of firewall settings,
the best option is to use TCP sockets.
one process acts as a server and allows an incoming connection on a specific
port. the other process connects.
Then they can send data to each other.

I have used winsock (which is unmanaged) in the past like this in a windows
service, and it worked great. this way the different computers don't even
have to run the same OS. UNIX and windows can work together that way without
any problem.

You can use winsock in your unmanaged app, and TcpChannel in your managed app.
For unmanaged you can probably also use MFC classes, but i've never used
those.

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
 
Dear Bruno,
it does not have to work on different computers, both parts always run on
the same PC. Is there a better option or do you still advice to use sockets?
Thanks a lot,
 
Is the string always of the same size and not too big? If yes, you could
implement a DLL with a shared segment. This is by far the fastest option,
because both processes would effectively share the same physical memory.
 
Dear Bruno,
it does not have to work on different computers, both parts always run on
the same PC. Is there a better option or do you still advice to use sockets?
Thanks a lot,

Since you mentioned 'on any computer, regardless of firewall settings' i
assumed that you wanted to use different computers.

The advantage of using sockets is that there is no limitation to what you
can send (types of data, size of data, ...) and you can seamlesly move
applications to different computers.

If you are sure that different computers are never necessary, there are
simpler options like pipes for example.

you can find a good overview here:
http://msdn.microsoft.com/library/d...n-us/ipc/base/interprocess_communications.asp

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
 
Just before I knew nothing about the topic and now I have a full overview.
Thanks a lot Bruno and Marcus for sharing this.
 
Look for the documentation of the CreateEvent, SetEvent, WaitForSingleObject
and CloseHandle APIs. An event in as named cross proccess OS object that can
be used for thread serialization. You can see an event like a boolean flag.
The receiver of the data can block its thread (WaitForSingleObject) until
the boolean flag is set to true by the sender thread (SetEvent).

In the MSDN documentation you should find a sample application.

Marcus
 
It does not sound easy :(.
What I need is:
Proc1 requests data (sends address to Proc2)
Proc2 sends data back.
The speed is important.
Is there no easier solution?
 
Boni said:
It does not sound easy :(.
What I need is:
Proc1 requests data (sends address to Proc2)
Proc2 sends data back.
The speed is important.
Is there no easier solution?
This sounds pretty much like a socket application. Sockets exist in managed
and native APIs. So this should be doable.
 
Guys. First of all the programming was never easy. Second: looking for
answers in some goups without having loooked through MSDN is nonsense.
Nobody will fill your head with knowlege you suppose to earn. Moreover. Even
if you think you have picked up some knowlege without earning - you will
fail horobly. Now, READ the MSDN, take examples, create your own application,
compile , run and fail till you fix it.
NOBODY WILL DO IT FOR YOU !!! never.
 
Back
Top