Network-wide messaging system?

[Gregory Gadow]

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.

 

[cbDevelopment]

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.