Using .Net Remoting for messaging, Help Needed

[S.Creek]

Hi,

I am trying to build a multi clients application with C# that will send
and receive messages using a listener on a server,
the computers are all on the same LAN, the listener need to identify a
message in the MS Queues he listens on, and send it to the relevant
clients (not all need to get all messages) it can send the message
through an event or an interface.?


I thought of using .Net remoting for that, i have no experience with
..NET remoting and appreciate any help.

Few of my questions:

1. How can I identify the clients, how do i send a specific message to
a specific client.

2. Is the listened needs to be a service?

3. Does anyone have a link or example for something similar?

Thanks you

S.Creek

 

[W.G. Ryan eMVP]

Remoting is a technology to handle your communications layer primarily.
Whether or not you use Queues, the decision to use remoting is a separate
beast. If you haven't used Remoting and/or DCOM, it's WELL worth your time
to learn but I will caution you, you won't get there without some
determination, persistence and a lot of commitment.

1) There are a ton of ways you can know who's listening. You can use
Remoting to create an object and then wire up an event handler for on of
that object's events. However there are a lot of other ways taht are
probably a lot better suited for someone just getting started in this area.
The easiest of which is trapping the app start event and then writing a db
record indicating that you are listening. You can remove the record when
you're done. You'll need to handle situations where the app may close but
the message doesn't get sent to the db for whatever reason, so you can poll
or use some interval to verify the client is still listening and remove the
subscription accordingly. I could write chapters on this subject b/c it
really depends on a lot of factors, but basically you want to implement a
version of publisher/subscriber.

2) No but it may make a good candidate.You can have an application start
whenever someone logs one by putting it in the startup folder for instance.
But with Sql Server, this wouldn't be a very good solution b/c if the power
went out, someone would have to show up and log onto the machine to get it
running again. This would waste time and pose a whole slew of other
problems, the least of which is security.

3) The situation described comes up quite a bit in Distributed Architecture
scenarios and if you google on "Service Oriented Architecture" +
"Messaging", I think you'll probably find quite a few.

I'll see what I can find for you though.

 

[Willy Denoyette [MVP]]

Not sure why you refer to remoting here, if you are using MSMQ why not use
the infrastructure of MSMQ to forward or pick-up the messages, you simply
don't need remoting for this.

Willy.

 

[S. Creek]

Thanks for the answers

the reason i thought of using Remoting is :

i have multiple clients that needs to listen on the same queue, where
the server puts its messages to them.

i need to handle messages and transfer them to the relevant clients,
messages are not always a response, sometimes they are invoked by the
server.

on the other hand all clients are running on the same computer as the
server.

i implemented a Listener for MSMQ , the problem is that it has a
different instance for each client, and then i have a race condition for
the messages in the Queue, not talking about what if message is
addressed to all clients,

i will be happy to hear more ideas if you have how to solve that
problem,

Thank you

S