You are correct that message queues are one-to one. If you wanted to
deliver to multiple workstations, you would need to deliver multiple
messages and you would need to know the machines that would be
receiving.
Since you have to track the subscribing machines anyway, I would
approach this as two applications, server and client, if you will.
The server has three exposed methods:
RegisterClient
UnRegisterClient
BroadcastMessage
The client has two exposed methods:
ReceiveMessage
Heartbeat
When the client starts, it tries to attach to the server and call the
RegisterClient method. When it shuts down, it calls the
UnRegisterClient method. An option within the client application,
possibly protected, allows the submission of a message to all other
registered clients, in which case the client sends the message to the
BroadcastMessage method.
When the server starts, it tries to attach to each of the clients it has
recorded in its last clients list (can be a database, XML, or text file)
and call its Heartbeat method. If it does not get a response, it is
removed from the list. When it recieves a call on its RegisterClient,
it adds the computer name to the client list if not there already. If
it recieves a call on the UnregisterClient method it removes the
computer. If it receives a message on the BroadcastMessage method, it
runs through its list of computers and calls each client's
ReceiveMessage method. On a timer, the server runs through the list and
calls each client's Heartbeat method and if there is no response, the
client is removed from the list.
These types of client/server communications should be pretty easy with
indigo (WCF).
This is just a general idea and probably has some flaws, but it will
support the immediate delvery of messages from a single source to
multiple and varying clients.
hope this helps.
Gregory Gadow <te******@serv.net> wrote in
news:43***************@serv.net:
I am looking for a networkwide messaging system to announce server
reboots, etc. To implement various custom features, I would much
rather roll my own than use an out-of-the-box type of app. Because my
company has a very strict, industry regulated archival policy, I would
like to avoid using email (which relies on the user having Outlook up
and running anyway, not always a safe bet.)
Using VB.NET 2.0, I've written an app that uses MSMQ to send text on a
message queue and a service that monitors the queue and displays the
message as a balloon tip from the tray. This works great, as the
balloon tips are always on top and do not take focus away from what
the user is doing at the moment. The only problem is that queues seem
to be a one-to-one transmittal. If I have three or four machines
monitoring the queue, the first one to grab the message will display
it while the other machines remain silent.
1) Is there a way to configure message queues to send one-to-all?
2) Is there a different mechanism for making system-wide announcements
than queues, and if so, could someone point me to a .NET code example?
(I can translate from C# if I need to.)
Thanks for the help.
--
Gregory Gadow
