IPC Issue 
Author Message
 IPC Issue

Hello all,

A little background first : I have a TCP server running as a system
service (using Olaf's dhRichClient RPC components), which is
responsible for synchronizing data between peers on a LAN. I also have
a client app (the UI), which may or may not be running at any given
time.

The basic concept:
1) A remote computer makes changes to one or more records.
2) The remote computer then broadcasts the changes to all other peers.
3) The local RPC service receives the changed records, and updates its
own database.
4) *If* the UI is loaded, the service notifies the UI of the changes,
otherwise goes on its' merry way.

The actual mechanism of getting the service to communicate reliably
with the UI is where I'm having difficulty. I tried it with an ActiveX
EXE that functioned as a central event sink, where any interested app
could create an instance of the notification object, and be notified
via an event. Unfortunately, although it worked perfectly during
testing, when the service raised a broadcast event, none of the
clients received the notification. That leads me to believe that COM
can't communicate across system account boundaries. Is this a correct
statement?

I'm currently using Post/SendMessage and WM_COPYDATA as a notification
method, but that is proving to be unreliable, ie: a small percentage
of notifications aren't being received, as if the window messages are
being 'eaten'.

Am I missing something here? Should I move away from a system service?
Any other ideas? Will I ever finish this contract? ;)

Seriously, any help would be appreciated.

        TIA,

        J.
    Jeremiah D. Seitz
    Omega Techware
    http://www.*-*-*.com/



Sat, 18 Feb 2012 23:16:36 GMT  
 IPC Issue


Quote:
> I'm currently using Post/SendMessage and WM_COPYDATA as a notification
> method, but that is proving to be unreliable, ie: a small percentage
> of notifications aren't being received, as if the window messages are
> being 'eaten'.

Sending messages to/from services to a UI doesn't work in Vista and after.
Services run in their own terminal services session. See this article:

Application Compatibility: Session 0 Isolation
http://msdn.microsoft.com/en-us/library/bb756986.aspx

Another way is using named pipes, luckily it works like WM_COPYDATA. Every
message sent is received in whole, unlike TCP which is byte stream that you
must analyze to determine where a message begins and ends.

How To Use Named Pipes in a Visual Basic 32-bit Program
http://support.microsoft.com/kb/177696



Sat, 18 Feb 2012 23:47:13 GMT  
 IPC Issue

Quote:

>Sending messages to/from services to a UI doesn't work in Vista and after.
>Services run in their own terminal services session. See this article:

>Application Compatibility: Session 0 Isolation
>http://msdn.microsoft.com/en-us/library/bb756986.aspx

I did not know that. You just saved me a lot of trouble down the road.

Quote:
>Another way is using named pipes, luckily it works like WM_COPYDATA. Every
>message sent is received in whole, unlike TCP which is byte stream that you
>must analyze to determine where a message begins and ends.

>How To Use Named Pipes in a Visual Basic 32-bit Program
>http://support.microsoft.com/kb/177696

Assuming I can get the example to work (it doesn't), I'm leery of
named pipes, especially in that they are either blocking, as in the
example, or non-blocking, in which case I have a lot more work ahead
of me. I appreciate the link regardless, but I don't think it will
work for this particular case.

I think in the meantime I'll do a bit of testing with the server
running as a 'straight' executable, in conjunction with the
centralized AX EXE. There is no requirement that the server run as a
service; I just saw that method as being 'neater', as well as more
stable, in that you can specify that service's dependencies (ie:
network layer must be loaded first, etc.)

Olaf's RPC architecture provides exactly the kind of tight coupling I
need, in that the client application *knows* a packet was sent and
acknowledged, or failed to be sent. I merely want to extend that logic
to the notification mechanism.

Thanks again!

        J.
    Jeremiah D. Seitz
    Omega Techware
    http://www.omegatechware.net



Sun, 19 Feb 2012 01:24:02 GMT  
 IPC Issue


Quote:
> Hello all,

> A little background first : I have a TCP server running as a system
> service (using Olaf's dhRichClient RPC components), which is
> responsible for synchronizing data between peers on a LAN. I also have
> a client app (the UI), which may or may not be running at any given
> time.

> The basic concept:
> 1) A remote computer makes changes to one or more records.
> 2) The remote computer then broadcasts the changes to all other peers.
> 3) The local RPC service receives the changed records, and updates its
> own database.
> 4) *If* the UI is loaded, the service notifies the UI of the changes,
> otherwise goes on its' merry way.

:
:

Quote:
> J.
>    Jeremiah D. Seitz
>    Omega Techware
>    http://www.omegatechware.net

The three alternatives that come to mind here are:

1.) A DCOM server written as an ActiveX EXE and properly configured in terms
of security.  The hoary old sample "Coffee Monitor" project in the VB6
documentation and samples should lead you to ways to use either events or
callbacks to notify interested clients.

2.) A straightforward TCP socket service that accepts client connections
from each peer and the UI application.  You'll need to layer a message
framing protocol on top of this.  Messages of interest can be "relayed" to
each client to simulate broadcasting... much as a chat server does.

3.) MSMQ 3.0 "multicast" queues in WinXP or later.  This can offer a number
of advantages including "offline" operation tolerant of a network outage,
and most likely no new custom service would be required... though each
machine must have the Windows MSMQ components installed and the service
running.

UDP and Mailslot (which uses UDP) broadcasts between machines are not
reliable.  MSMQ multicast uses the PGM protocol instead which loses a lot
fewer broadcasts.



Sun, 19 Feb 2012 07:19:59 GMT  
 IPC Issue



Quote:
> A little background first : I have a TCP server running as a system
> service (using Olaf's dhRichClient RPC components), which is
> responsible for synchronizing data between peers on a LAN. I also have
> a client app (the UI), which may or may not be running at any given
> time.

> The basic concept:
> 1) A remote computer makes changes to one or more records.
> 2) The remote computer then broadcasts the changes to all other peers.
> 3) The local RPC service receives the changed records, and updates its
> own database.
> 4) *If* the UI is loaded, the service notifies the UI of the changes,
> otherwise goes on its' merry way.

> The actual mechanism of getting the service to communicate reliably
> with the UI is where I'm having difficulty. I tried it with an ActiveX
> EXE that functioned as a central event sink, where any interested app
> could create an instance of the notification object, and be notified
> via an event. Unfortunately, although it worked perfectly during
> testing, when the service raised a broadcast event, none of the
> clients received the notification. That leads me to believe that COM
> can't communicate across system account boundaries. Is this a correct
> statement?

In case of ActiveX-Exes ...  yes.
Also the new thread-helper-classes in the RichClient cannot
communicate across system-account-boundaries (otherwise
they would be the recommended alternative to ActiveX-Exes
for your centralized broadcast scenario, which could work
even regfree and/or directly integrated into the RPCServer-
instance).

With the given (Service-)Background, the easiest (and also
most reliable way) would be, to make use of the IPC-stuff
which already does your main-work - and that's the
crossmachine-capable RPC-mechanism.

Nothing holds you back, to connect to the very same service
that already is hosting the RPC-Server on each machine with
this hosts local IP from other (UI-) Client-processes which
run on the same machine.
Even if you have reduced the RPC-Servers Threadpool to
1 RPC-worker-thread (running one serverside RPC-
Classinstance only), you can connect additional RPC-Client-
instances to it over the local IP (then using the LoopBack-
interface of that machine ... the TCP/IP-packets not visible
"on the wire").
And since the single RPC-WorkerClass already "knows"
the current "LogState" of all the last (sync-)actions, you only
need to add a public method/function to it, which hands out
the last "Log-additions" (newer than a LastLogID, the local
UI-Client in question could pass as a parameter).
Each UI-Client would only need a RPCClient-Classinstance,
which is polling the RPC-Service with a relative short interval
as e.g. 100msec - this should reflect new data in the UI
fast enough IMO and would cause an additional CPU-
load that is near Zero, since most of the polling-calls
are "non-expensive ones", in case the passed LastLogID is
equal to the most recent LogID (meaning "no new received
data in the RPC-Class was received from outside").

All you need in your UI-App(s) is a small class, that encapsulates
a cRPCConnection- and a cTimer-Instance and in turn is
raising Events to your GUI from within the internal PollingTimer-
EventHandler (if the additional RPC-MethodCall is returning with
Data, that is newer then the passed LastLogID).

Olaf



Sun, 19 Feb 2012 09:07:37 GMT  
 IPC Issue

Quote:

>> clients received the notification. That leads me to believe that COM
>> can't communicate across system account boundaries. Is this a correct
>> statement?
>In case of ActiveX-Exes ...  yes.
>Also the new thread-helper-classes in the RichClient cannot
>communicate across system-account-boundaries (otherwise
>they would be the recommended alternative to ActiveX-Exes
>for your centralized broadcast scenario, which could work
>even regfree and/or directly integrated into the RPCServer-
>instance).

Thanks. At least I know I'm not completely senile ... yet. <g>

Respectfully 8<snipped >8

Quote:
>All you need in your UI-App(s) is a small class, that encapsulates
>a cRPCConnection- and a cTimer-Instance and in turn is
>raising Events to your GUI from within the internal PollingTimer-
>EventHandler (if the additional RPC-MethodCall is returning with
>Data, that is newer then the passed LastLogID).

The polling approach *might* work. I could probably simulate the tight
coupling with a polling loop in those cases where that would be
required.

I had the thought to combine polling with your postmessage/hidden
window method, where the window message would temporarily set the
polling timer's interval to 1 msec, but as Nobody pointed out, window
messages can't be sent from a service under Vista and above.

For now, I'm just modifying the RPC server to run as a standard
executable, in conjunction with the AX EXE notifier. That seems the
easiest and fastest solution. Otherwise, I'll need to do a *lot* of
work to implement the polling approach. ;)

Quote:
>Olaf

        Thanks again!

        J.
    Jeremiah D. Seitz
    Omega Techware
    http://www.omegatechware.net



Sun, 19 Feb 2012 23:26:44 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. ipc and vb

2. Ideas on IPC?

3. VBPJ: IPC

4. IPC$ in vbscript

5. Using IPC within VB

6. IPC in VB

7. How to share information between VB6 apps (IPC)

8. IPC between VB and DCOM App.

9. Help: IPC in Win95

10. IPC in vb

11. Update to WM_COPYDATA for IPC with eVB

12. Office XP Mail Merge issue Insertdatabase issue and problems with copying a macro

 

 
Powered by phpBB® Forum Software