Inferno... The Solution for Thin Client Distributed Computing
The Inferno universal thin client paradigm for distributed computing provides a flexible, scalable, configurable architecture for edge-of-the-network devices. Inferno encapsulates complexity into Styx servers, which run on larger hardware in the network. Heavyweight, backbone CORBA, DCOM, and DCE services are fully available from the thin client - all side by side native Inferno resources and services - all with a uniform, simple interface.
The purpose of this paper is to discuss Inferno's distributed computing methods. Particular attention is given to the Inferno computing model relative to other distributed computing solutions.
Darrin Lewis, C. F. Yurkoski and Samuel J. Paone
Inferno Network Software Solutions
Lucent Technologies, Inc.
November 7, 1997
1. Introduction
Any computer programmer will tell you that tradeoffs are a fundamental aspect of programming. There have been tradeoffs since John von Neumann and company determined that developing and supporting ENIAC with 18,000 vacuum tubes was preferable to employing thousands of humans to perform mass computations. Today we see that many programmers are willing to trade application execution speed for code portability when using the Java programming language. Application developers recognize that there is rarely ever one best solution, and never any free lunch. Developers must assess competing programming environments and decide which tradeoffs to make.
The Inferno development team at Lucent Technologies' Bell Labs has made tradeoffs that have yielded a superior system for developing and deploying distributed applications. The result is Inferno - a programming environment that provides an efficient, dynamic, secure, multithreaded framework for building distributed applications. Inferno combines a small, powerful operating system with the benefits of easily reused code, maximum security and procedural language speed and size efficiencies. Inferno traded off the market momentum of strict object oriented programming in exchange for a programming environment supremely optimized for thin client distributed computing. Inferno enables thin client devices to leverage network resources. These resources can be Inferno applications, legacy systems and databases and CORBA, DCOM, DCE and RMI objects and services.
2. Distributed Thin Client Computing
Recently, the computing and communications industry and press
have been praising and anticipating the arrival of ubiquitous
computing. Typically, the ubiquitous computing vision includes
extensive deployment of inexpensive "Information Appliances",
e.g., wireless devices, intelligent telephones and television
set-top boxes. Achieving this vision requires that these devices
rely, to varying extents, on services based within resource rich
networks. Subsequently, industry members have begun to search
for distributed computing technologies that can locate, acquire,
package and deliver services across heterogeneous, networked resources.
One of the technologies most often employed to accomplish these
tasks is the Object Management Group's Common Object Request Broker
Architecture (OMG CORBA). CORBA is designed to standardize distributed
object computing. The bulk of the standard evolved during the
early 1990s and continues to mature today. Though conceptually
object technology is quite different from the DCE model, many
CORBA services are similar to their DCE predecessors.
CORBA is based upon the OMG's Object Management Architecture (OMG
OMA) which sets a framework for distributed object computing.
An object is an entity. It may be a file, or a computer, or an
application program, or a database server. Each object is defined
in terms of its interface - the set of operations it exposes.
The interface, which is specified in an implementation-independent
Interface Definition Language (IDL), describes how to obtain service
from the object.
The developer first writes the IDL, then the server code to implement
the new procedures and the client code to call the new procedures.
All other details are handled by CORBA tools. The IDL compiler
generates two sets of procedures from an interface definition.
A set of stubs is generated for the client, in its preferred implementation
language and a set of skeletons is generated for the server in
its preferred implementation language. These translations, from
the language-independent interface definition to the client and
server implementation languages, constitute a large ease-of-use
factor for CORBA and an improvement over DCE. All of the data
type translations, byte ordering, formatting, and message passing,
known collectively as parameter marshalling, are handled by the
generated stub and skeleton procedures.
The OMG have defined a set of CORBA services in their Common Object Services Specification (COSS). These services include object naming, event passing, object life cycle management, persistence, transaction management, concurrency control, querying, and licensing. Future services include archiving, backup/restore, logging, and replication. All services have IDL interfaces and are implemented under CORBA. It is important to note that CORBA is the result of an open standards process, and thus it is rather all encompassing. Though the design may be general, the current standard is directed toward large business objects, which provide large granules of functionality. CORBA's object oriented designs can provide many useful features, particularly, reusable software components. However, there are engineering tradeoffs associated with strict object oriented programming. For example, the late binding of objects typically causes object designs to be larger and slower than traditional procedural designs. These overheads prohibit CORBA's use for lightweight applications such as window management or component based development. This makes CORBA unsuitable for delivering distributed services to inexpensive clients. Inferno fills this void.
3. Inferno
Inferno is both an augmentation to CORBA and other distributed
systems and a potential substitute for these technologies. Inferno
is a distributed operating system, and as such, it facilitates
distributed application development in a natural way. Inferno
is programmed in the Limbo language, which features byte code
portability, strong type checking, and automatic garbage collection.
Inferno has a highly portable micro kernel and runs on minimal
hardware. It is compact, efficient, natively distributed and highly
generalized, by design. Its creators chose a simple, universal
interface and applied it throughout the system. Inferno's ability
to engulf other systems is inherent in its design, and limited
only by imagination.
Inferno operates in two main modes - as a self sufficient operating system on several microprocessor architectures and as a hosted environment on Windows NT, several versions of Unix and Win 95. Inferno's distributed computing capabilities result from two simple yet powerful core tenets: every resource in the system, either local or remote, is represented by a hierarchical file system; and a user or process assembles a private view of the system by constructing a file name space that connects these resources.
3.1 Resources
A resource is a basic Inferno object. Every resource provides a file-like interface, i.e., open, read, write, close, et cetera. Resources are arranged hierarchically into tree structures, like directories. As a whole, Inferno resources adhere to a file system metaphor, that is, they appear like a file system. Each resource exposes a fixed interface, and responds to messages by invoking functions, which take a series of arguments and return a result. For example, a resource may provide the service of persistent storage manipulation. In effect, it behaves as a traditional file. However, resources may behave in a variety of other ways.
It is important to note that an Inferno resource is an active object, which communicates via a stream of messages. Even when acting as a file, a resource may provide other desirable services such as backup and recovery, or replication. Regardless, the interface remains the same. Based on this simple interface, Inferno resources can provide rich services such as networking protocols, window management, database access, process control and remote execution.
3.2 Names
Each resource has a human-readable name. Because resources are
arranged hierarchically, a name is expressed as a compound string,
like a UNIX path. Taken together, the resource trees known to
a process comprise its name space. A fully qualified name resolves
to exactly one resource within a name space.
Rather than manage a global name space, Inferno chooses to work
only with a local name space and a set of global conventions as
to where one should expect to find a given resource. The name
space of a process can be dynamically extended by mounting a remote
file system. A bind operation dynamically reconfigures the name
space to make resources appear in expected or conventional locations.
All resources in a name space appear to be local, i.e., the name
space provides network transparency.
The benefit of a homogeneous name space cannot be overstated. A similar regularity of form and function is the underpinning of the world wide web. Where the web breaks down, is where it deviates, providing a special, proprietary interface for each new resource. By leveraging Inferno's ability to provide a uniform interface to a series of disparate services on a myriad of platforms, Inferno delivers a universal thin client, and interoperability with other systems.
3.3 Messaging
Inferno provides a platform-independent communication protocol,
Styx, on top of which sits a hierarchical name space of resources.
Styx is the only communication protocol on which Inferno depends,
and Styx can be implemented above any reliable, in-order network
transport. For example Styx can be implemented on PPP without
TCP/IP. This lightweight solution gives Inferno an advantage when
competing against other platforms. Even greater though, is the
advantage of being independent of the underlying network protocols.
Each operation on a resource is realized by a pair of Styx messages.
The Styx protocol consists of only 14 message types, making it
small enough for almost any hardware to support. The messages
negotiate simple file-system-like services. The uniform nature
of these message types creates an ideal platform for interoperability.
Any Styx client, without specific knowledge of what functionality
can be obtained from a given server, can access its interface
in an identical way. This allows a Styx client to explore and
discover the capabilities of a server by browsing.
The difference, between Styx and traditional object systems, is
that Styx requires each resource to conform to a file system metaphor.
All resources interact using Styx messages, which present a uniform,
file-system-like interface. A Styx server must export a resource
hierarchy (virtual file system), tailored to delivery of specific
services. The client, which sends a Styx request, always knows
how to process the server's reply.
The syntax and semantics of a particular resource are expressed
within the messages exchanged with the resource, not through a
functional API. This permits considerable runtime flexibility,
because it is easier, in most programming environments, to rearrange
a message than a function call. It is also convenient to stream
large messages to a resource for continuous processing, as with
multimedia data. One can even use this streaming concept to establish
a pipeline through a series of resources. This data flow model
offers attractive benefits. In addition, Inferno's command line
directly supports meaningful interaction with resources.
There is strong merit to this single-interface approach. It is an accepted principle of software development to avoid special-case logic, because programming effort is wasted, code becomes complicated and unmaintainable, and testing is impeded, as the number of execution paths balloons. The result is poor quality software. By eliminating special cases, the Inferno approach encourages reuse of simple components, which results in compact, reliable programs. The small size of the Inferno operating system and its applications attest to this fact.
3.4 Virtual File Systems
Inferno uses the Virtual Machine (VM) concept to abstract a common
programming environment from disparate hardware. Analogously,
Inferno employs a Virtual File System concept to abstract a common
networking environment from disparate protocols and services.
The file metaphor provides a single, simple interface for all
resources. Thus, every "file" in Inferno, local or remote, is
actually a resource/object served by Styx. The Inferno name space
allows a process to mount and bind local and remote resources
into a single, local hierarchy, resulting in network transparency.
Connectivity to other systems is accomplished via Styx servers,
which can bridge protocols to non-Styx services, when necessary.
The benefit, and challenge, of presenting services in the Inferno
way is to design an appropriate file-system metaphor. Inferno's
Styx protocol is a means of describing and generating a file-system
interface. Additionally, Styx is a convention, whereby the syntax
and semantics of the interface can be browsed.
The inclusion of semantic information in the metadata of an interface
file, together with the flexibility of Inferno's message-passing
architecture, allows runtime arbitration between client and server.
A discovery process can transpire during which adaptive techniques
can be applied to the resource brokering process. A suitable interface
can be located to provide the desired service. This degree of
interoperability can ensure the timely delivery of best fit services
from a heterogeneous network of distributed providers.
Application programmers will have uniform access to the objects and the services offered by CORBA, DCOM, RMI, and DCE. Though the Inferno OS and its distributed computing model are tightly integrated, Inferno is open to data and services from other existing and foreseeable platforms. In this way, Inferno is the best choice for edge devices that may need access to services from one or more of these heavyweight enterprise-oriented providers. We embrace these technologies, but question their efficacy on memory/CPU constrained devices.
3.5 Services
Figure 1 shows the relationship between thin Inferno clients, Inferno servers, and service providers on existing networks. Notice how a single Inferno client may interact with more than one server, to gain access to back end network services. This architecture makes Inferno flexible; name space and resources make Inferno possible.
Figure 1. 
In addition to the core operating system, Inferno provides some services and conventions that facilitate distributed computing. The preferred way to integrate services is to write an appropriate file system metaphor. A server will export the virtual file system for use by Styx clients. The client program will mount the file system and bind resources into its name space. The resources may be manipulated from programs, or even directly from the command line. This approach embodies the Inferno paradigm. Lucent Technologies is working to build a rich set of Inferno services and is recruiting key industry partners to participate in this effort. Two of these services are Directory Service and Network Services.
3.5.1 Directory Service
Foremost among Inferno services is a Styx directory service, which is used to locate resources, which provide services for clients. The directory service, itself, is presented as a resource in the client's name space, and may be mounted from some other machine in the network. The response from the directory service is the location of the requested resource. That file system location can be mounted and bound into the local name space for use by the client.
Clients and servers alike must be aware of directory servers on the network. A server should register its service with one or more directory servers. A client will make a request of a directory server, asking for a particular resource name. That server will attempt to locate the service among those registered. If it cannot locate the service, it may pass the request to another directory server. Some network specific limit, on search size, must be defined by the appropriate network administrator thus limiting the fan out of the search. This will also prevent infinite cyclic searches. A successful search will result in the name of a machine, which can provide the requested service.
The client will use that machine name to establish a connection to Styx services on that machine. The client will mount the exported file system and will bind the /services directory after its own. Now the client has access to all exported services of the remote machine. Access to services is controlled by authentication and subsequent permissions on the resources that expose services. In this case, group permissions become particularly important. If a client subscribes to a service, the client id will be added to a group that permits access to the resource.
3.5.2 Network Services
A very lightweight Inferno client may not have the capacity to support every communication protocol that it may need. Therefore, the client may want to mount one or more network protocols from a server that provides them. This is a very flexible policy, which minimizes the requirements of the client platform. The client need not have any direct knowledge of the communication protocol that will be used in the deep end of the network. This is another way in which Inferno shows its strength as a truly distributed operating system, and as a universal thin client.
4. Inferno and CORBA
Because Inferno's distributed computing solution space intersects the CORBA problem domain we now explain some of the key differences between these two technologies.
4.1 Scalability
Inferno offers a large advantage over CORBA in terms of scalability. In an Inferno network, all network resources, whether local or remote and whether persistent or dynamically synthesized, are viewed by the application as local files. Therefore, unlike CORBA the syntax used by a service user to communicate with a service provider is not compiled into either the client or the server program as is done with CORBA's IDL. Using Inferno the only function calls that the service user makes are file operations, e.g., open(), read(), write() etc. and these never change. Subsequently, in an Inferno network, there is never a need to flash cut when a service is upgraded. New versions of the services and service user applications can be phased in over time providing great advantage for network service providers, network administrators and developers. One can easily see that the larger and more complex the network is the more important this type of scalability becomes.
4.2 Networking
Often the bane of distributed application development, support for network specific code is built directly into the Inferno system. Inferno's name space and file metaphor enables developers to write distributed network applications without writing any network code. Because all resources in the Inferno network appear to the application code as local files, knowledge about which resources are remote and which are local is not coded into the application when it is written. Rather these decisions may be made at execution time. The name space in which the application runs is dynamically created at run time. Consequently, an application's run time name space creation can consider such factors as available memory, available CPU, network bandwidth, cost, priority, etc. For example, an application, when run on a resource-limited device such as a cell phone, might execute with many of the resources running remotely. However, the same application, the exact same byte codes, running on a more capable device may run with most of the resources and execution locally. Inferno applications can be so dynamic that the physical distribution of resources between local and remote can be altered between one run and the next without the application code ever being aware of this change. The value of this capability cannot be overstated when discussing ubiquitous, network dependent computing.
4.3 Procedural vs. Object Oriented
There exists a vigorous debate in the development community among those preferring procedural programming and those promoting object oriented methodologies. Inferno enables application developer's to achieve many of the advantages of object oriented programming, e.g., code reuse without the overhead associated with objects. Inferno modules are loaded out of the name space and since Inferno name spaces are extremely malleable, inheritance is easily accomplished by "binding" specific modules in front of generic ones. For example if an application expects to find the code for a phone interface in a directory and in a file called "phone.dis" and it is currently dealing with a GSM phone then the GSM specific "phone.dis" module would be bound into that directory. However, when the same application is dealing with a TDMA phone the TDMA specific "phone.dis" would appear in the appropriate place in the application name space. The salient point is that the application is only cognizant of the need to load "phone.dis". This provides a level of abstraction and code reuse on par with standard object oriented systems.
A significant distinction between Inferno's application development methodology and object oriented methods is that Inferno applications are much smaller than object based applications. One key element in Inferno's ability to reduce application executable size is Inferno's facility for dynamically loadable software modules. With Inferno only those software module's that are needed along a particular execution path are loaded as the module runs. Unneeded modules are never loaded and the memory that required software modules use is automatically and immediately freed by Inferno's garbage collection scheme as soon as the module goes out of scope. This is in stark contrast to systems that wait until a program exits before reclaiming memory.
5. Conclusion
Distributed computing is a generic term that has many meanings. Lucent Technologies believes that distributed computing means availing all entities to the power of the networks to which they belong. This belief necessarily includes the multitude of devices at the very edge of networks. The best example of this philosophy is the power that the most prolific and inexpensive communications device, the telephone, derives from the world's most complex and reliable network, the public switched telephone network. Our goal is to extend this model to put all manner of intelligent voice and data communications devices at the disposal of consumers.
Inferno is designed to drive network resident computing power to high volume, inexpensive consumer devices. Inferno accomplishes this by providing a small, scalable and portable framework for developing and deploying distributed applications. Inferno recognizes the need for many computing technologies and provides the ability to unify and leverage these technologies across entire networks. Inferno represents a core technology in making ubiquitous, distributed computing a reality.
Send Questions or
Comments to: infernoweb@lucent.com