469,077 Members | 1,393 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,077 developers. It's quick & easy.

IPC mechanism Named Pipes or windows messages or sthg else ?

Sorry for repeated posting but I couldnt get things right/completely
in the first post.

I am in the process of deciding the IPC mechanisms to use for
communication between

1) An application API (which would be set up as a NT service). It
could be C++ or C#. The API as such might be talking to the
underlying application (UA) via WM_COPYDATA messages.

2) A top level application (TLA) that would use the API to drive the
UA. The application is quite low level dealing with
telephony. The UA will pass up "async events" to the TLAs as well.

I must write the API and support an IPC that would give the TLA
developer the maximum flexibility in terms of languages
(VB.NET, C#, C++, Java). I might not want to worry about Scripting
languages here.

I had suggestions for MsgConnect but I have been advised by my Boss to
get things going without any commercial products.

The determining factors could be
1) both the TLA and the UA with its API would be on the SAME machine
2) TLA and UA are different processes.
3) The data being exchanged is not much, almost always just a phone
number "STRING". The phone number cannot be passed as a long integer
LParam in windows messages and there could be more than one number as
well. So may be a string is best, or even a struct.
4) No need of security

5) Maximum flexibility of language choice and least work / simplest
IPC mechanism for the TLA developer.
6) The API might need to support WM_COPYDATA style windows or custom
messages to talk to the UA.

I have been looking at / been advised to look at
i) Windows messages - They have the advantage of handling sort of
"async event" message delivery right away and also it seems to extend
the WM_COPYDATA communication between the API and the application.

But, given that the TLA and the API are different process spaces, does
this mechanim need a memory area accessible by both the processes (say
by FileMappingObject etc) ? When using WM_COPYDATA ? When using custom
messages ?
If yes, then to me it seems that windows messages are not a preferable
mechanim at all (as it again needs shared memory !)
when talking between different processes.

ii) Named pipes - Thought they seem to go well for the case, I have to
support windows messages based communication
between the API and the UA. Also, how good is this mechanism from
the perspective of a TLA developer ?

Any help is greatly appreciated. I am in urgent need to find the right

Thanks !
Jul 21 '05 #1
0 1291

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Srijit Kumar Bhadra | last post: by
reply views Thread by Matt W | last post: by
1 post views Thread by Sharon | last post: by
2 posts views Thread by Rudolf Bargholz | last post: by
7 posts views Thread by andrewb | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.