I'm hoping someone can help me with this.

I want to build a service that constantly receives data from an
external server and does minor processing and databasing on the
received data. This part is simple and is already built.

However, I want to also build clients that I can launch from my
machines that will "connect" to this service while it's running and
receive events.

So for example, the service (NumberService) receives a sequence of
numbers (1, 2, 3, 4, 5) and for each number it receives, it stores it
in a database and then raises an event (NumberReceived) and passes that
number.

I want to build a client (SequenceClient.exe) that "subscribes" to the
NumberReceived event and reacts when the sequence (3-4-5) is received.

The deal is, I want to be able to launch this SequenceClient at any
time...sometime it's on and sometimes it's off...but the NumberService
is always on.

I have a feeling that .NET remoting would do this, but I'm wondering if
there is another way (by hooking into the service somehow). The SERVICE
and CLIENT will always be on the same machine, so I have a feeling that
..NET remoting adds a bit of unnecessary overhead. Is .NET remoting the
only way? or is there a better, more efficient way?

Any direction you can take me would be appreciated...the only
stipulation is that it has to be accomplished in a .NET language
(VB.NET, C#) since that's the only area of expertise we currently have.

Basically, the question goes to the heart of raising events across
process spaces. Can it be done? Can one application raise events in
another completely separate process? Is .NET remoting the only way to
accomplish this?

Hi,

..NET Remoting is quite fine, it works well within a single machine boundary
and that's the option I'd go with, given that other alternatives such as
named pipes don't have sufficient managed code support.

However, what I doubt is the event-driven architecture in which the service
initiates communication with its clients - while events CAN be implemented
in .NET remoting, some hassle might be involved. Can you think of another
way where the clients would poll the service? You can probably use
cross-process named synchronization objects (such as mutexes) to facilitate
this.

<mrmi***@gmail.com> wrote in message
Show quoteHide quote

Dmytro,

Thanks for the initial reply.

OK, you'll have to forgive me, as my personal multi-threading
vocabulary is limited.

There are a few things you should take note of:
1) All clients will need to be notified when a number is received since
most clients do different things based on a different sequence of
numbers. For example, we have a plotter client that will plot the
numbers, and then we have a database client that will database the
numbers. The reason? because we want the database client to be running
at MOST times of the day, while the plotter app will only be used when
students bring it up from their terminals.
2) These numbers come in real-time, and a delay of even a second could
cause false readings, as the time-sensitivity is a critical factor.
That's why I'm apprehensive of ANY polling because it implies that the
client has to initiate some sort of timer which does not imply
real-time.
3) We have a third-party application that has an API for sending in
real-time data that is used for scientific charting. Here in lies the
main reason we want a cross process communication. If we direct the
real-time feed into the API, the database application must stop running
since our lab only has access to one real-time feed. This is
unacceptable, since we want to keep the database application running
while various terminals (through a remote desktop-like interface) will
run real-time studies using this application.

Again, I'm probably not nearly as versed in .NET as some of the users
on this board, which is why I'm hoping you're onto something. I know
..NET remoting events may be a hassle...but is there another way? I'm a
little apprehensive of using MSMQ because I don't know what happens if
you have multiple applications monitoring the same Queue, and since
..NET remoting has a similar event driven model, I thought that might be
the best way...but this Mutex object...how can I can synchronize my
applications using this object? As far as I could tell, and I didn't
look into it very deep, I can see where the Mutex can help to prevent
more than one application than running, but how can I tie that
functionality to informing all clients relatively simulatenously (some
delay during broadcast is expected, but even a second delay between the
reception and AT MOST 3 applications running is unacceptable)? Please
point me in the right direction? some web page tutorials/other code
posts...whatever...just need a good start here.

Can't set ConnectionStringSettings.ConnectionString property
MulticastDelegate.GetHashCode returns not usable hashs in .NET 2.0
Calling managed code from C
BackGroundWorker.ProgressChanged "Cross-thread operation not valid" at 2nd/3th/... progress
Array Sort issue