Introducing the BBE Workstation Alert System

Broadcaster: The Broadcaster (message server) is the software that actually sends the messages. The Broadcaster can send its messages to any or all of 8 available Client groups at the same time (see Client description below). If the 'Use Repeater' function is enabled, the Broadcaster will also upload a copy of the message to an FTP site for retrieval and re-distribution by the Repeater software. If the 'Use Repeater' function is not enabled, then no upload occurs and the Broadcaster simply sends the broadcast out on the segment of the network that it exists on. The Broadcasters are passive and produce no network load except when they are actually sending a message. Typical messages are in the 500 byte range. There can be any number of Broadcasters on a given network.

Repeater: The Repeater is used to fetch messages down from an FTP site and re-broadcast them, unaltered, on the network segment that it is on. The messages would have been previously uploaded by a Broadcaster (see above). The Repeater does not originate any end-user messages of its own, it simply re-broadcasts messages that the Broadcaster has uploaded. The Repeaters do, however, originate System Status messages to inform administrators of various Alert System conditions that may require immediate attention -- inability to connect to the FTP download site, hacking attempts, or other important system conditions. Use of the Repeater is completely optional. If you don't need to span network segments or LAN's, then you will not need to use the Repeater. The Repeaters should be installed on computers that are, generally, always on. A server, where available, would be the best location. As a backup, more than one Repeater should be installed on each segment. Multiple Repeaters on the same segment do not interfere with each as long as they are running on different computers. There is no certain limit to the number of Repeaters that can operate on a given segment, however, as a practical matter, to minimize network traffic and the possibility of access conflicts, two Repeaters on a given segment should suffice.

Client: The Client receives the messages sent by the Broadcasters or Repeaters and displays those messages to the end-user. The Client should be installed on every computer on the network. Each Client is assigned to 1 of 8 available groups. These groupings exist to enable you to selectively send a message to any, or all of them, at one time. The Client software is completely passive, so produces no network load. Hundreds or even thousands can be deployed on the same network without producing any network load at all.

Back to top

There a number of commercial products out there that do a similar type of thing to the BBE Workstation Alert System. Some of these use Instant Messenger protocols, some use a 'connected' client/server TCP/IP delivery system, and some use other delivery schemes. The BBE Workstation Alert System was designed with the 'keep it simple' approach. There are no client-server connections established during operation. The UDP network protocol is utilized throughout. The Broadcaster user interface is dead simple and messages can be sent in as few as two steps. There is no learning curve associated with using the Broadcaster. Demo files are included and anyone can be shown how to use it in 60 seconds or less. The BBE Workstation Alert System has no potential for end-user misuse as the Clients are completely passive and possess no way to originate a message.

The UDP protocol is what is referred to in network terms as 'connectionless' and 'non-guaranteed' delivery. To a non-technically oriented person this 'non-guaranteed' delivery characteristic may seem like a scary proposition for a messaging system that may be needed to carry emergency messages. There are several things to keep in mind though:

The phrase 'non-guaranteed delivery' does not refer to any less reliability in the network's or software's ability to deliver such a data stream and only reflects the lack of acknowledgment and error checking in the delivery method. The BBE Workstation Alert System provides it's own error checking which renders the latter shortcoming moot. The phrase 'acknowledgment' here refers not to an end-user's actions but to the guaranteed delivery functionality of a connected protocol. The client and server negotiate a connection, exchange the data, and check the transmission for errors. If there were errors in the transmission the whole process is repeated until the data is transferred correctly. It's easy to see how this might rapidly get out of hand the more clients you add to the system using a connected approach.
It's impossible to know, at a critical moment, whether someone will necessarily be at a particular terminal when an important message is sent. A 'connected' system with receipt acknowledgment cannot improve upon this fact.
Connected protocols have a lot more overhead than connectionless protocols do. The packet sizes are bigger and the network traffic can be prohibitive given enough simultaneous client connections that must be established and maintained. There can be a real network load cost involved in 2000 machines simultaneously sending receipt acknowledgments back to the server.
Guaranteed delivery may not be necessary or desirable in a given application. The BBE Workstation Alert System philosophy, in this case, is to compensate for the shortcomings of a connectionless system with the sheer volume of clients (it is recommended to install a client on every machine on your network) and to send each message repeatedly to increase reliability and compensate for any network latencies. Each time a message is sent it can be automatically re-sent as many times as you desire or are necessary to compensate for any network latencies in your system. That is, you click the 'Send' button once and, behind the scenes, the message is sent repeatedly without any further intervention by the sender. This is harmless as duplicate messages, or messages that fail an integrity check, are ignored by the Clients.

Lastly, let me leave you with this analogy: I liken a non-guaranteed delivery system to the days before phone answering machines were invented. If I called your house and you weren't home ... I let it ring for a while, then hung up ... when you got home, there would be no indication at all that I had ever even attempted to contact you. Still, the absence of answering machines did not negate the value of attempting to contact someone and certainly many millions of emergency phone calls were made, and responded to, before answering machines were invented.

An internet accessible FTP account will only be necessary if you are using the Repeater application. The Repeater application is used to span LANs or network segments. If you don't need to do this, then you will not need to use the Repeater and, therefore, you will not need an FTP account. The way it works is that the Repeaters work hand-in-hand with the Broadcasters. Every time a Broadcaster sends a message, it uploads a copy of that message up to an FTP site. All Repeaters, in turn, poll that same FTP site at regular intervals to acquire any new messages that appear. When a new message appears, every Repeater downloads that message and re-broadcasts it on its own segment. In this way, the Repeaters provide the exact same functionality as the Broadcaster, except that it is spanning the network segments that the originating Broadcaster had no access to.