inventory_sim:
----------------
This is a demo program that illustrates how TIPC can be used to support
distributed applications.  It takes advantage of TIPC's socket-based
messaging, as well as its port naming and port name subscription capabilities.

The demo is a simulation of a store that stocks a variety of numbered items
which are sold to customers upon request.  By default, items and customers
are created randomly (although there are limits on the number of each that
can be present in the store at any given time).  From time to time new items
are delivered to the store; independently of this, customers enter the store,
each looking for a specific item.  If a desired item can be obtained before a
customer gets tired of waiting for it, a sale is recorded; otherwise, a walk-out
is recorded.  If multiple customers attempt to obtain the same item, only one
succeeds; the others are notified of their failure and try again.

Each item and customer is implemented as a separate task.  An item makes itself
available by creating a socket whose port name identifies the item number.
A customer determines the availability of an item by creating a subscription
for the item name and waiting for notification that the item exists; the
customer then obtains the item by sending a message to the socket for the item
and receiving a successful reply.  A logging task is used to record all
significant events encountered by the item and customer tasks during the
simulation, as well as to display the simulation status and statistics on a
periodic basis.

This simulation is most effective when it is run on multiple CPUs at the same
time, which has the effect of creating a network of stores sharing a global
inventory.  Since the port name published by an item is visible throughout the
TIPC cluster, customers are able to obtain items from other CPUs if they are
not available locally.  The more CPUs involved in the simulation, the more
items are available and the less likely a customer will be to walk out of a
store because the item they desire is unavailable.

When a simulation is terminated the logging task waits for all customers to
leave, then creates a janitor task to dispose of the unsold items that remain.
TIPC's name subscription capability allows the janitor to distinguish the items
belonging to its own store from those in other stores.

The simulation can be temporarily halted to permit inspection of the various
tasks used, or to assist in debugging problems.  This is achieved by
publishing the name of a virtual item (item 0), which instructs the logging
task on each CPU to temporarily suspend processing; this causes all customer
and item tasks on the CPU to become blocked when they next attempt to log
an event.  (Note: Pausing the simulation may result in warning messages from
customers about non-responsive items; this is normal behavior resulting from
the way the pause capability is implemented, and is no cause for concern.)

The demo gives the user control over the number of item and customer tasks
used in the simulation, as well as the ability to increase the speed of
processing and to control the amount of output generated.  By default, a
simulation running at normal speed displays all transaction info, while a
simulation running at an accelerated rate displays only the periodic summary.
The simulation can also be run in a deterministic manner by creating a store
having no items or customers, and then generating individual item and customer
tasks manually.

Running the demo
----------------
The simulation is run by issuing the following shell commands:

newSim [#items [#customers [speed [verbosity]]]]
                       - open store
killSim                - close store and clean up
stopSim                - pause simulation of all stores
startSim               - unpause simulation of all stores
newItem [item [count]] - create item (repeat as specified)
newCust [item [count]] - create customer for item (repeat as specified)
helpSim                - display this menu

A missing (or 0) argument value causes the simulation to choose an appropriate
default.  In certain cases, an argument value that is < 0 can also be used
to disable a specific feature of a command.

The output messages generated by the simulation should be self-explanatory.

Examples
--------
1) Run default simulation:		./newSim

2) Run simulation at 10x normal speed:	./newSim 0 0 10

3) Run simulation manually:		./newSim -1 -1   [create empty store]
					./newItem 3      [create item]
					./newCust 3      [create customer]
