Software ICs

“Complexity must be grown from simple systems that already work.” —Kevin Kelly

Courier

Occasionally it is necessary in a design for two receiver
processes to exchange messages. The courier construct illustrated
below is a good way to accommodate this requirement.

Figure 6. Courier

A typical example would involve a user-interface process.
Typically user interfaces, be they simple text-based interaction or
GUIs, want to be receiver-type processes. It is not often that you
would want the user interface to block on a send. Very often in
these designs the user interface (UI) requires information from
another receiver process. If you went ahead and coded a blocking
send into the UI then you could potentially have a place in the
operation of the UI where the interface would freeze while the
request was being serviced. This may not be the desired
behavior.

The courier construct takes advantage of the delayed reply
concept illustrated in the agency construct above. In our
discussion we will assume that the UI process is “receiver1” and
the recipient process is “receiver2”. When the courier process is
started the first thing it does is locate the UI process it is
designated to service. Once located, the courier will send a
registration-type message to that process indicating that it is
ready for action. The UI process will simply note that the courier
is available and not reply, thereby leaving the courier reply
blocked. At the point in the UI where the asynchronous request to
the receiver2 process needs to be accomplished, a message is
composed and sent (replied) via the courier. The courier is now
unblocked and proceeds to locate and forward the message to the
receiver2 process using a blocking send. At this point the courier
is reply blocked on receiver2 and the UI is completely free to do
other things as permitted by its logic. When receiver2 replies to
the courier, the courier simply forwards that reply on to the UI
process using a blocking send and once again becomes reply blocked
on the UI. The UI receives this message in the normal manner, notes
that it came via the courier, marks that the courier is once again
available and processes the message in accordance with the logic
coded.

This simple courier described above is a single request
version. If a second UI request intended for the receiver2 process
is generated within the UI before the courier returns its first
response that request will be refused, siting the “busy courier”.
A simple enhancement to this single request logic is to have a
single-message-queuing capability in the UI. The “busy courier”
response then would only come if a third UI request is attempted
before the original response is received. In most UI processes this
single message queue is more than adequate. A larger queue depth
algorithm could be constructed readily, but the need for this is
often indicative of a poor UI design elsewhere.

Another variation on the courier model is to have a parent
process fork the couriers on demand. In some cases this capability
is more desirable than having the courier prestarted along with the
GUI process. The web applet type GUI applications are examples
where this courier spawning technique is desirable.

Especially in user-interface designs, the courier construct
is a very useful SIMPL building block indeed.

Broadcaster

There are times in a design where there is a need for a
one-to-many sender/receiver relationship. For simple cases, one can
simply have the sender locate all the intended recipients and loop
through sending to each. In more sophisticated designs the
broadcaster construct illustrated below is very powerful.

Figure 7. Broadcaster

The broadcaster actually consists of two parts: a receiver
and a sender. We call the sender part the broadcaster. The receiver
is typically a message queue as we shall see shortly. It works in
the following manner: and the queue looks after message queuing and
sequencing. The broadcaster maintains a list of processes to send
to.

A typical sequence may start with a receiver (say receiver1)
deciding that it wishes to receive broadcast messages. As part of
that sequence it sends a registration-type message to the
broadcaster's queue process. The queue will then place a
REGISTRATION-type message onto its internal queue. Meanwhile the
broadcaster returns from one of its broadcast sequences by sending
a message down to the queue process asking whether there are any
new messages queued. In this example the REGISTRATION message for
receiver1 is delivered as a reply to the broadcaster. When the
broadcaster process detects that the message is a new REGISTRATION,
it does a nameLocate on that the recipient (receiver1 in this
example) and stores the ID in its internal broadcast list. It sends
a confirmation message back to the queue process, which then
proceeds to reply and unblock the original receiver (receiver1—who
was temporarily a sender). If there were no more messages on the
internal queue, the broadcaster would simply be left reply blocked
at this stage. At this point the sender may send a message to the
broadcaster's queue process that is intended for broadcast.
Typically the queue would queue the message and reply immediately
to the sender, but one could do a blocking send scheme similar to
that of the registration process. If the queue detects that the
broadcaster is reply blocked it immediately forwards the message
via a reply to the broadcaster. Once the broadcaster gets the
message it notes that this is not a registration and therefore is a
message to be sent to all the registered recipients in its
broadcast list. Once this series of sends is complete the
broadcaster will send back to the queue for the next message and
the process repeats.

When a recipient wishes to cancel its registration with the
broadcaster, it simply repeats the registration process with a
DEREGISTER message to the queue. It is typical that the queue would
simply queue and acknowledge this request.

If a recipient “forgets” to deregister and simply vanishes,
the next broadcast attempt will detect that condition and the
broadcaster would proceed to remove that ID from its internal
broadcast list.

The broadcaster construct is a very powerful SIMPL tool. A
typical example of its use would be to synchronize multiple
instances of a GUI applet with the same information.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.