P
piyush
Sorry for repeated posts, I couldnt get things right and complete in
the previous 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
always.
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
mechanism.
Thanks !
the previous 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
always.
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
mechanism.
Thanks !