Re: Best way to do interprocess communication?
From: Bob Moore (no email)
Date: 09/18/04
- Next message: phil cunningham: "copy and paste problem"
- Previous message: Rafeeq C E: "Using CDC::DrawFrameControl() to add resize grip to dialog."
- In reply to: Bredal Jensen: "Best way to do interprocess communication?"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 18 Sep 2004 12:29:49 +0100
On Fri, 17 Sep 2004 10:09:20 +0200, Bredal Jensen wrote:
>But i have no practiacal experiences with these techniques.
Snipped from this page on my website:
http://bobmoore.mvps.org/Win32/framed_tip009.htm
My personal choice would be between named pipes and sockets.
Named Pipes
-----------
Use file APIs, so relatively simple to implement if you're at all
file-savvy. Not queued. Connection-oriented, i.e. point to point, and
therefore can't broadcast. Win9x can act as a named pipe client, but
not as a named pipe server. NT can do both.
Mailslots
---------
Queued, connectionless and can therefore broadcast. Simple to use, but
have some drawbacks :
1. Because the sender doesn't know what protocols are installed on
the receiver, mailslot messages are duplicated on every installed
protocol, and it's your responsibility to sort out the resulting mess
(usually with some sort of tagging system).
2. A length limit of 400 bytes or so.
3. Don't have guaranteed delivery, though I've yet to see one fail
to arrive (on a LAN : see point 4).
4. Broadcasting to a group (e.g. a domain) works fine... but they
most likely won't cross a router, and broadcasting over a RAS link is
broken.
WM_COPYDATA
-----------
Very simple to use. Obviously message based, so you have to pump
messages. If you need something quick and dirty for occasional-use
messaging on a single machine, both apps (or at a minimum the receiver
app) have a message pump and you can get a window handle, this is hard
to beat.
Memory Mapped files
-------------------
MMFs don't necessarily need to be associated with a disk file, so you
can use them for IPC. Since MMFs are the underlying implementation
technique for most of the other IPC methods, you won't get much better
performance if a shared memory technique fits your requirement.
DLL Shared Sections
-------------------
These require you to write a DLL of course, which seems like overkill
just to get two processes talking. There is also a technical problem
which can arise because Windows recognises DLLs by their path, not
their name. So two copies of the same DLL from different paths can get
loaded, and the loading processes won't see the same section. Bummer.
DDE / NetDDE / ddeml
--------------------
Message based shared-memory technique. Functional, but supposedly
moribund. I can only assume MS doesn't want us to use it because
either (a) it doesn't consume enough processor cycles to keep Intel
happy, or (b) it works. Can cause problems because of the broadcast
initiate sent via SendMessage. SendMessage is synchronous and the
broadcast goes to every window in the system, so if someone out there
has a window but isn't pumping messages, your call to SendMessage
won't ever return (Win32 uses GetMessage, PeekMessage and WaitMessage
as synchronisation points, so despite the fact that SendMessage is
supposed to be a direct call to your WndProc, it won't get actioned).
The cure is to use the SendMessageTimeout API.
Sockets
-------
Microsoft's Winsock is based upon the Berkeley Unix sockets
implementation, with proprietary (naturally, this is Microsoft)
extensions. Those extensions include support for asynchronous socket
calls. Sockets have the advantage of simplicity and portability for
heterogeneous environments. If you are working with Internet-aware
applications, sockets are your IPC of choice.
There are two types of sockets, stream (TCP) and datagram (UDP). TCP
is point to point and offers guaranteed in-order delivery. UDP
supports broadcast, is size-limited and offers none of the above. Note
that stream sockets by their very nature do not support framing : one
of your messages may be split across two or more packets, so your
protocol must take account of this (i.e. one receive notification !=
one whole message). Hence you'll have to write your own code to split
message packets out of the stream.
Under Windows, there are various implementation techniques available
to you.
1 Synchronous Sockets
Basically, using worker threads and blocking socket calls. This
is simple to implement, but doesn't scale at all well.
2 Asynchronous : Overlapped I/O
Finicky to code, and doesn't really offer any advantage over the
next two methods.
3 Asynchronous : windows-message notification (a.k.a. the
WSAAsyncSelect method)
Using the function WSAAsyncSelect, you specify that you want to
receive notifications of socket events via the windows message queue.
Upon receipt of the event, calling a specified function resets the
notification ready for the next event. If you have a GUI app and
maximal throughput isn't a necessity, this is a good bet.
4 Asynchronous : I/O Completion Ports
In this technique events are queued through an I/O completion
port, so it combines the convenient queueing of the WSAAsyncSelect
method with the performance of overlapped I/O. For non-GUI apps, or
those that require extreme throughput, this is a good bet. Quality
sample code is also available from www.mvps.org !
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Next message: phil cunningham: "copy and paste problem"
- Previous message: Rafeeq C E: "Using CDC::DrawFrameControl() to add resize grip to dialog."
- In reply to: Bredal Jensen: "Best way to do interprocess communication?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
