The History Behind Broadcatch - VOS

VOS - The Venue Operating System (1996)

(rev. 4.0 3/2/97)

The Venue OS - a localized, multi-media intensive instantiation of a personalized Broadcatch environment - was designed to support the Canter Technology Media Bar project in late 1996 and early 1997. Funding was never secured for this visionary project.

The three main sections of the Venue Operating System consist of:

1. The VOS Daemon (specifically, its spawned client threads)
   • maintains connectivity with
     • a schema-oriented DBMS thread
     • a single client station
   • receives, interprets, formats and directs messages
     • to and from the DBMS
     • to and from the client machines
     • to the logger
   Additionally, in the near future the VOS will also
   • communicate with a Broadcatch engine
   • accept Show Control input from human operators,
   • interface with the ARTI physical systems interface, and
   • (what else?)
2. The Database (DBMS) (and its spawned schema threads) which
   • stores all the data used by all the schemas in a venue,
   • supplies shared content for the applications,
   • provides persistent storage for e.g. customer (avatar) preferences,
   • provides caching of frequently used tables, such as the Station Table and cppAll, and
   • maintains customer usage and account records (see also: the Venue Cash Card)
3. A Base Network Object which enables
   • generalized communications between applications and the VOS/DBMS (see prototypes),
   • simple and complex queries (see message types),
   • asynchronous notifier-style messages from the VOS to the client station (see verbs & events),
   • (what else?)

Order of operations:

1. The VOS and DBMS processes are started on a server machine
2. Each sets up a TCP/IP socket listener on a well-know port
3. A client machine (Art - bottom left) makes a connection request to the VOS listener passing requested database schema name and machine ID
4. The VOS listener spawns a child thread (essentially a copy of itself)
5. The VOS thread requests a schema-oriented connection from the DBMS parent listener
6. The DBMS listener checks to see if there is already a thread started for the given schema
   • if not, then it spawns a DBMS thread for that schema
7. A bi-directional communications line is accepted between the DBMS (schema) thread and the (client specific) VOS thread
8. The VOS thread
   • requests a list of cached database versions from the DBMS thread
   • accepts a bi-directional stream socket connection with the client machine
   • notifies the client machine of the current database versions

VOS Process Flow:

Notes:

• The VOS parent and child processes are lightweight and could be safely implemented in Java without a significant performance sacrifice
• There is one VOS thread per client station but only one DBMS thread per active schema
• Communications between the VOS thread and the client station will be via a client architecture independent message structure
• The communications protocol between the VOS and DBMS threads is TBD