Daniel J. Pezely
pez@hitl.washington.edu
January 1993
One limiting factor of virtual environment systems today is communications.
Communications for server-to-server exchanges and terminal-to-server exchanges require robust implementations of fault-tolerant and elegant designs to permit the first generation of marketable large-scale virtual environment applications. Such applications are being developed within research and commercial environments alike, and when the actual users demand performance, that demand must be satisfied.
This is a proposal to implement such a robust system. Specifically, the implementation is to be built on top of the Microsoft NT micro-kernel operating system as an application programming interface, running concurrently with the Windows environment and the POSIX-compliant interface.
The facilities required include a few inexpensive workstations for development and testing. An exclusive or shared investment of computer hardware, operating system licenses, development software, and funding for the researchers/developers will finance this project, providing a high-performance platform to run the applications being developed today.
* * *
Virtual reality enables high-capacity computer-mediated communication between people.
While the human-factors issues and virtual environment applications are being developed elsewhere, within the Human Interface Technology Laboratory (HITLab), robust lower level computer-computer communication facilities required for practical applications remain undeveloped.
The users of virtual environments, both experimental and commercial in nature, require robust, scalable, extremely fast and flexible message transportation between computers– transportation which is compatible with and provides needed information to the higher level user applications.
Developing such computer-computer communications facilities will provide the testbed required by near-future research and commercial projects.
To expedite preliminary development of a virtual environment operating system (VE-OS), the HITLab’s original implementation time schedule required omitting certain design elements. Other elements within the laboratory environment provided the justification for the omissions, such as a controlled, small-capacity, fixed-scale work environment.
Developers and researchers alike must address the near-future issues today such that demands will be met in a timely fashion. Some issues approaching involve performance and expandability.
The proposed project is to satisfy these issues: This is MOSES, the Meta Operating System and Entity Shell, development of a robust VE-OS.
To accommodate robustness, performance, and expandability issues, the MOSES system includes robustness features for fault-tolerant distributed shared memories, expandable communications channels, network optimization, and mechanisms allowing administrative accounting of resources.
The resulting implementation will satisfy the needs of researchers and commercial/industrial users alike.
To the community of virtual reality (VR) researchers, developers, and users, the MOSES Project proposes the development of a virtual environment operating system (VE-OS) which will:
And the schedule planned for this project will have a deliverable system within a year with demonstrations beginning after six months. A second year is planned to expand the system to add functional libraries.
Implementation of the MOSES core.
The MOSES kernel will run on top of the Microsoft NT operating system as an application programming interface (API). Microsoft Corporation’s market positioning for NT will ensure its success as the commercial and business operating system of choice. Building upon this choice, a VE-OS operating on top of NT as an API will ensure an installed base of possible users.
Development of test environments.
Evaluation of applications on the MOSES platform: performance is to be measured with the introduction of pseudo-random noise, periodic noise, varying amounts of congestion, intrusion and undisciplined messages, simulated node failures, and simulated link failures.
Non-inclusive test environments include:
Demonstrations of test environments:
Development of virtual environment elements.
The common existing virtual environment input/output facilities will be added, including graphic rendering, stereo graphics, 3D sound, 3-space tracker input, and wand input.
The HITLab “VEOS” world-building tools will be installed with necessary modifications to take advantage of the additional features of MOSES over the HITLab “VEOS.” This is the Meta Layer of the MOSES design.
Development of virtual environment enhancements.
Application of switchable, high-performance algorithms will be installed on top of MOSES. Such algorithms include: predictive caching of graphic objects, caching data, migration of shared data to point of demand, migration of message routes, optimization of network link, etc.
Installation of MOSES at participating test sites.
A MOSES-based virtual environment platform will be installed and maintained at the HITLab to be connected with remote sites running the MOSES system to explore multiple remote environments and single environments distributed over wide areas.
This will be a good application for regional/national multi-gigabit networks.
Stage One: Core Development
Estimated time: one person, three months (one month to complete the remaining kernel functions and two months to implement and test the protocol.)
Justification: Conceptually, the design is very small, and this carries over to the implementation design. Building upon an existing OS, Microsoft NT, the normal OS internals will not need to be implemented. Being a “systems” project and introducing no new computer science theory, no issues require further study here. The implementation should proceed smoothly.
Stage Two: Scalability Testing and Simulation
Estimated time: one person, three months (one month to research current network problems, such as forms of congestion and noise control; one month to implement the test functions; and one month to build and test demonstration environments)
Justification: Researching the current state of network traffic beyond what is already known to the researchers will be a simple matter of communicating with colleagues in the network engineering community. Implementing the test functions will be straightforward since these routines will only be used for testing and not for long-term system features. The third month will consist mostly of experiments and a one day workshop/demonstration for the funding agents.
Stage Three: Meta Layer Tool Construction
Estimated time: one person, six months (five months to build stub functions, one month to port higher level routines from HITLab “VEOS”)
Justification: Higher level functions will be directly installed from the HITLab “VEOS” distribution once the intermediate stub functions are written. From examining the HITLab “VEOS” distribution, six months should sufficient to reproduce the stub functions within the MOSES system. This time estimate is conservative.
Stage Four: Expansion of the Meta Layer
Estimated time: two people, twelve months (six months to get default algorithms in place, six more months for installing alternate algorithms and the functionality to change between default and alternates on demand)
Justification: For the default algorithms, the research has already been done, so only the implementation of the various caching and migration methods remain. The alternate algorithms require further research to find any new concepts which may have surfaced since our research was initially done.
Development workstation features:
Quantity requested:
Workstation peripherals:
Operating system/software for each computer:
Note: all hardware must be compatible with the Microsoft NT operating system.
Salaries:
Daniel Pezely,
Chief Systems Researcher & Developer
Annual salary at 100%: $45,000.
Equipment:
Approximate retail cost:
Each workstation: $12,000.
Desired quantity: x 4
------
$48,000.
Minimum quantity: x 2
------
$24,000.
Peripherals: $ 3,000.
Software: $ 269.
Miscellaneous (shipping, backup-media, etc)
$ 500.
------
$ 3,769.
Totals:
Desired configuration: $99,769.
========
Minimum configuration: $75,769.
========
Salaries:
Daniel Pezely,
Chief Systems Researcher & Developer
Annual salary at 100%: $45,000.
Michael Almquist,
Systems Researcher & Developer
Annual salary at 100%: $45,000.
------
Total: $90,000.
========
The MOSES Project is a scalable virtual environment operating system (VE-OS) project focusing on research, designs, and development of robust, fault-tolerant, distributed and shared memory, local- and wide-area operating environments drawing upon current cutting-edge projects being developed around the world.
Although this is a “systems” project introducing no new computer science theory, the end result is novel and currently is not known to exist elsewhere in related communities.
Some of the features of the MOSES Project system include:
Many features are by-products of these resource elements, providing a unique system of industrial quality for both researchers and users alike.
It is the intent of the MOSES Project to be established as a standard after being merged with the applications from the current HITLab “VEOS” development project. (The reason for parallel development is that the HITLab VEOS system had to be in use from day one and matured around that development schedule, while MOSES was designed and will be developed with the majority of its features in place before the generation of the first executable version–two extremes of system development, both necessary, each in their own way.)
What follows this introduction is a brief history of the HITLab’s conceptual “VEOS” design, continued research, and an overview of its existing implementation. After the background material, the actual design is presented without the implementation specifications, formally or informally. Then, a detailed explanation of the project stages is given, followed by a technical summary of goals and expected results. Semi-formal specifications are retained outside of this document.
The HITLab’s conceptual virtual environment operating system (VE-OS) design, named “VEOS,” is based upon the question: How can we create a reality? And that prompts the question: What is a reality, in a generic sense?
These questions deal with heavy metaphysics, but from a non-traditional perspective. Traditionally, metaphysics deal with questions such as: What is the nature of reality?
By reversing the point-of-view of such questions, an actual conceptual model was created. This creation was the HITLab’s “VEOS” design.
The very first implementation of the HITLab’s “VEOS” was put together simply to test the concept. It worked. The conceptual design did what it was supposed to, but being a demo implementation, performance was excessively poor. Poor performance did not matter.
As new versions were created either by modification or by clean rewrites with alternate approaches, new versions achieved better performance. However, all early versions were designed and developed to be run by researchers within a research environment. This environment at the time did not need industrial standards of robustness, fault-tolerance, or practical commercial features such as resource accounting, thus were not planned for, nor implemented.
Due to the nature of the existing HITLab “VEOS” kernel, modifications to add such robustness features are best suited to a clean write of the kernel with a new implementation design.
This is the purpose of the MOSES project, to build the lowest level of a VE-OS platform rather than to modify an existing one, to suite industrial quality.
This next-generation VE-OS is given a distinct name to show that the implementation is different from known existing systems, and the acronym chosen to mark what will hopefully become a de facto industry standard in this era of early VR history.
Reflection upon the HITLab conceptual “VEOS” design, we found many similarities with other existing projects around the world outside the VR community. Such projects were in the areas of operating systems and internetworking, as well as the seemingly obvious areas of CAD, expert systems, artificial intelligence, databases, etc.
The outside research consulted includes: The Amoeba Project, the ARPANet, Asynchronous Transfer Mode (ATM) networks, BSD Unix, Kerberos, Mach, The MULTICS Project, Prosperos, and The V Kernel, among others.
After the summer of 1990 when the HITLab conceptual “VEOS” was sketched out, one of the four designers, Daniel Pezely (aka Pez), returned to continue his degree and consulted two more people for feedback, further maturing the design. The two people were Michael Almquist (aka Squish) and Mark Evenson.
The result was very similar the HITLab conceptual “VEOS,” but minor changes were made, providing an elegant implementation design. This design was specified as precisely as possible without using a formal specification language.
The implementation design was called MOSES, the Meta Operating System and Entity Shell.
The term “Meta Operating System” was chosen because the OS would possess the typical hardware abstractions and the desired top-level system-independent interfaces while removing the intermediate layers. The “Entity Shell” notion was included in the name since the communications protocols were combined within one functional unit to progress beyond the teletype (tty) versus network port interface distinction; here, we have a single abstraction with functional distinctions determined when requested, not at the design level.
Implementing MOSES at this time is important now that this conceptual refinement and new implementation design have been completed. Now that the preliminary HITLab “VEOS” system has an application base, to ensure that when the demand of a higher-capacity foundation system is upon us, we will be able to deliver with MOSES.
Implementation has already begun, but without funding from supporters, this project will not be given the attention required and will sadly become a hobby effort.
At the core, the MOSES design deals with arbitrary information. The information is arbitrary in that the kernel does not distinguish the data being shuffled around as information since the content is never put into any context for use, comparison, or evaluation. Instead, “data”–identified as such, thereby creating information–gets determined at the point of use, not by the kernel. The kernel is merely a message-routing system, so the details of bit, byte, and word orderings are not necessarily of concern to the kernel.
While this strict message-routing does not interact with its data, the design complexity is moved out of the kernel and up to the protocol evaluators. The protocol evaluators, then, reside logically above the kernel, thus become as easily replaced as device drivers or versions of application programs by replacing a module/part and not the keystone. Modular design arguments apply, as usual.
Using strategies from database design and file system design, combined with concepts for shared and distributed memories, a user-centric memory can be created which is functionally global though actually shared and/or distributed. The functional memory created is possible via the “grouple” concept. A grouple is a nested tuple, and while such a definition is semantically contradictory, the result is an infinitely configurable memory structure.
This grouple structure stores, manages, and transports the arbitrary information within the kernel as well as provides the back-end mechanism for a programming interface which can be used for resource drivers, tools, applications, virtual world construction, and debugging each element.
Stemming from the functionality permitted by the grouple structure, shared memories are inherent to the design, thus no additional code is required to provide the service. Additional code, of course, is required for enhancing and complementing the service, all of which may be done at the next logical layer above the kernel.
To provide the distributed memory, features of the grouple structure permit non-local and non-resident addressing. This structure is a fundamental difference between the existing HITLab “VEOS” and MOSES.
To assist in the management of distributed memories, closure tables can be maintained such that all internal grouples addressing external grouples–and all external grouples referencing internal grouples–are tracked. This tracking provides the fault-tolerance features.
Dealing with issues of communication between systems, the protocol to be implemented is a hybrid of the Internet Protocol family (TCP/IP). This hybrid essentially allows the standard TCP/IP protocol bounds to be modifiable upon registration or re-registration. Such registration allows for optimization between host-host, host-gateway, and gateway-gateway links.
Incidentally, the MOSES design permits use of the kernel for a network router, mail system, file server, database server, as well as the encompassing virtual environment server for which it was intended. Each of these alternative uses are elements of the back-end of virtual environment systems.
The MOSES system is intended to be a robust platform to build, test, and use virtual environment applications.
Ideally, the system will be developed on a platform which makes MOSES accessible to the greatest number of potential researchers and developers, while permitting the established researchers, such as the members of the HITLab, to use high-end equipment.
After watching the computer industry and studying the NT operating system from Microsoft, it would be in the best interests of the HITLab, the community of VR researchers and developers, and the future users of VR applications to build MOSES on top of the NT micro-kernel operating system, residing adjacent to Windows applications and the POSIX-compliant system.
There has been sufficient editorials written in industry trade journals explaining why building upon NT would be beneficial, so the details will be omitted here. (See BYTE magazine, October 1992.)
Essentially, by using NT, MOSES will benefit from having a vast number of machines to support it with the absolute minimum of porting efforts (a simple cross-compilation will typically suffice). Also, by the nature of MOSES being a robust system, expanding MOSES into a commercial product will be simple from the technical end.
Familiarity with Microsoft NT to date has come from the new book Inside Windows NT, by Helen Custer, Microsoft Press, 1993, and from experimenting with a Beta version of the Windows NT system on i486 workstations.
Minimal Entity Shell:
Extended Entity Shell:
Networking:
Kernel Applications:
I/O Facilities:
World-Building Tools:
Euclidean space tools:
Algorithm types:
The purpose of the MOSES Project is to bring a robust virtual environment operating system (VE-OS) to both researchers and commercial/industrial users alike. Further, the need to establish a de facto standard now, before the virtual reality (VR) community members are locked into incompatible designs, is important and should be done by an independent laboratory not driven by commercial factors. Finally, we feel that our design is both simple and general enough that by introducing our system as a proposed standard this early in the history of VR, we will not be stifling future design maturation or growth.
The rationale behind a second system to the Human Interface Technology Laboratory (HITLab) “VEOS” system is to generate a clean implementation, not tied down by existing designed-in functional limitations. It is recognized that the original HITLab “VEOS” system was developed such that an executable form would be available quickly and feature enhancements made rapidly, this approach is not ideal for robustness. To ensure robustness and to introduce new design functionality, a clean write is required.
To guarantee the success of this project, MOSES is a “systems” effort, thus no new theoretical computer science ground will be broken, thus the outcome of the Project is clear.
Since the age of 15, he worked in the computer industry as a programmer and consultant. Drawing from his CAD experience, his fascination for telecommunications, and using his artistic abilities, his research and design work since 1987 later helped develop the Virtual Environment Operating System at the HITLab. To complement his personal education, Daniel completed a B.S. in Computer Science with a Philosophy minor at the University of Delaware.
not available.