Many services grow exponentially to support the increasing demand by the users and the nature of the media being served. We can give thousands of very popular web sites on the Internet as an example. As more and more people race to browse through web sites with images that get bigger and animated, the machines that the servers are running on become overwhelmed. To remedy this problem on the web, a simple solution of server aliasing/switching is used where requests from a single URL are serviced by an array of machines.
As the computing age matures even further, billions of clients will need millions of servers. Most servers will be tiny, but some will need to be large. With the belief that this spectrum of different sized servers can be built using small modular components, we decided to implement Oasis using small modular components that work with each other, while maintaining abstraction amongst them.
Oasis had to run on a typical home PC with small amount of disk Space, a single processor, which might be on an Ethernet LAN. As a personal server or as server which is meant to service a small office of people. But Oasis also had to run on multiprocessor machines with ample amount of disk space and memory and possibly multiple network interfaces. As a Video server which might need to service an Intranet. And still, if the needed, Oasis had to service many thousands of people, such as in a large residential area.
One way of scaling a service is to distribute it, allowing multiple machines to work with each other to improve the service. It was our task to allow for distribution of a single Oasis Server among multiple machines and to make an Oasis Server work cooperatively with other Oasis Servers. Oasis needed to be configurable so that parts of it could run on other machines, to decrease the computing requirements and to increase the network bandwidth for servicing the clients.
A pool of Oasis servers working together had to balance the load produced by all the clients. To do this, an Oasis server had to easily and seamlessly pass and receive active clients from and to other Oasis servers. If needed, an Oasis server had to act as a Proxy server between a client and another Oasis Server that are geographically far apart.
Multiple Oasis servers had to be able to work together to service a single client. While a client could initially connect to a single Server, it could then ask for media located on other servers in the pool.
Oasis can be broken up into seven main modules. Each of these modules provides a set of interfaces for other modules to call. Each of the modules has a module interface and something we call the module core. The module core contains the main functionality of the module while the module interface is just the communication mechanism between the modules. We call any installation of Oasis, which contains all the module interfaces on a single machine, a parent Oasis server. We call any installation of a set of module cores on a machine that is not a parent Oasis server, a child Oasis server. For each parent installation of Oasis, all the module interfaces must exist on the same machine, but not all the module cores. The core of some of the modules can be configured to reside on different machines. This gives Oasis the ability to conform to many different types of server architectures enabling, scaling of the service. We will not go over the general structure for a module.
As we have mentioned earlier, each module has a Module Interface, and Module Core. For some of the Oasis modules, the Module Core does not have to reside on the same machine as the Module Interface. The Interface provides a standard way for communicating with other modules, namely by using function calls. The interface passes any received functions to the Module Core, which is responsible for the processing requests from other modules. To allow the Interface and the Core to reside on different machines, we have to provide an abstracting communication mechanism between the Interface and the Core. This Internal Abstraction Layer within the Module is there to allow communication between the Modules' Interface and the Core over many different types of communication media, whether it is ATM, Ethernet or Shared Memory. Ideally, different Abstraction Layers would be available, and depending on the configuration of the server, appropriate Abstraction Layers would be used.
If the Interface and the Core resides on the same machine, then a simple Abstraction Layer Module can be used to simply call functions between the Interface and the Core. If the Interface and the Core reside on different machines, then the Abstraction Layer must use sockets or possibly other protocols to communicate with its remote end. In this case, Abstraction layer has to transfer possibly large chunks of data between the two machines. This tells us that some Abstraction Layer Modules which use networks, should be used over a very high speed and low latency network, and reminds us that administrator configuration of the system is as important as the design and implementation of the system.
The database manager is responsible for managing the database needs of Oasis. The Database Manager provides a set of interfaces for any other module to use. The Database Manager makes use of the Internal Abstraction Layer, allowing the Core Database Module to reside on another computer. Since the Database Manager provides a standard Interface for other modules of the system and because of the Internal Abstraction Layer, any database, such as Oracle, Access, or Fox Pro, can be easily integrated into the system. Below is a diagram showing the Database Manager.
The Database Manager only requires an interface from a Resource Manager residing on system where its core is located. Please see Resource Manager for the reasons why access to the Resource Manager is so important.
For any application (ex. Video Server) to be stable and robust, it must monitor the system it is running on. It must know whether any request made from the system, such as allocation of memory from the heap, can be satisfied, and whether this will put the system or its self in a less then efficient state.
The task of keeping track of the systems integrity is the task of the Resource Manager. Its job is to generate critical events, make reservations for any system resources, and report resource usage.
It provides a standard interface to all other modules of Oasis, through which resources can be allocated. Other modules do resource allocation but they are not allowed to make any resource allocation before logically reserving it with the Resource Manager.
It is possible that at any time another application running on the system can allocate resources such as disk space or memory which might breach the threshold of minimum free resources warning level, set by the Configuration Manager. At this time, the Resource Manager will generate an critical event warning all modules. Modules at this time will avoid any further allocation of resources and possibly reduce the amount of resources allocated.
Of course, just as resource reservations are made through the Resource Manager, resource cancellations are also made through the Resource Manager.
This is the most important component of Oasis Media Server, for it is responsible for accepting connections from clients and servicing them. It allocates resources and tracks the state of each client and Media Objects requested by the clients. It allows for good scaling by providing service through multiple network interfaces. The Client Managers’ architecture represented by the figure below.
As we can see from the figure above, the Client Manager does not make use of the so-called, Internal Abstraction Layer. This is because the Core of the Client Manager Module must stay at the parent Oasis server, whereby using the central server model in dealing with clients local to its self.
To Provide Service through multiple network interfaces, an Object of the Network Interface Module is instantiated for each of the network interfaces used to service clients. A service network interface does not have to be on the local system. To provide better scaling, the service network interfaces can be distributed among multiple systems. This is done to increase the total amount of network bandwidth for servicing clients and possibly help in servicing a larger geographical area. Each instance of the Network Interface Module is responsible for network I/O done through the network interface it is assigned to. It is also responsible for any communication between the parent Oasis Server and the remote system that holds the remote network interface. By dynamically adding and deleting instances of Network Interface Modules for remote network interfaces through special, high bandwidth, low latency interconnects, proxy servicing is achieved.
The User Manager keeps an account of the users, their privileges and their activities. It provides an interface to the Client Manager, which queries the User Manager to provide Access Control for the system. Special User accounts are kept for special clients such as guests, auditors, content providers and monitoring and configuration clients such as Shade. Its architecture is rather simple since it does not make use of the Internal Abstraction Layer. It requires an interface from the Database Manager for accessing, local or remote user databases for adding, deleting and verifying users.
It is important for a service provider to keep track of the activities of the system for this is one way the service can be improved, and the clients can be audited. Log manager keeps a record of anything that any of the other Modules wants to keep track of. It keeps the logs through the Database Manager. It other responsibility is to filter the logs and events at the request of the Configuration Manager. It is the job the Log Manager to also time stamp event logs so that more meaningful data can be returned back to special monitoring and auditing clients. This is the reason why even the Database Manager should log things through the Log Manager, although it could easily do it its self.
The Configuration Manager is the module responsible for the configuration of all modules. Every other module provides an interface for the Configuration Manager. Configuration Manager is the main module that instantiates, sets up, and "starts" all other modules. It only provides an interface for the Client Manager. This is because Oasis allows special clients to change the configuration of the system and the Client Manager has the task of passing configuration requests to the Configuration Manager. The figure below shows the internal structure of the Configuration Manager.
The Configuration Manager is the only module that doesn’t store its data in the Database Manager. It uses flat files to keep its own configuration information.
The Configuration Manager is also responsible for instantiating, initializing and starting all of remote modules on child Oasis Servers. This is done by starting a copy of its self at a remote machine using RPC, which then starts all the modules for the child Oasis Server.
Media Objects are stored, retrieved and replicated at remote machines by the Media Object Manager. It can store Media Objects as it is best suited, whether in flat files, within archiving media (ex. Tape Drive) or within a local database through the Database Manager. It is responsible for I/O required to store and retrieve Media Objects from Local Disk and archiving media, whereas the Database Manager will handle I/O for Media Objects stored at the Database.
The Media Object Manager is also responsible for reporting the availability of Media Objects at the local Oasis server. It keeps track of all available Media Objects using the Database Manager. Media Object characteristics such as Bandwidth requirements, file size, and availability are just some of the variables stored in the database for quick metadata retrieval.
Replications of Media Objects at other Oasis Servers are handled by the Media Object Manager by acting as a special client, namely as a content provider.
Our intentions were to build a sound and robust product while making sure that it would not limit our research. It was important to use good Object Oriented Programming style during the implementation of Oasis. We have made full use of modularity to allow easy updates and additions to the system. This allowed us to easily plug in new code to improve sections of the system and add new features. Modular programming also made the system much easier to debug and test. We wanted to make sure that Oasis did not crash under heavy loads and that Oasis did not alter the integrity of the system it was running on. This is one of the reasons why we have put a lot of effort in monitoring the system, which Oasis was to run on.
Current implementation of Oasis is limited compared to the Functional Model provided above. The structure described above has been put in place using a highly rich set of C++ virtual classes. Then many derived classes have been written to implement a working server. This server is limited in a number of ways:
As development and expansion of Oasis continues, missing parts will be implemented to provide the functionality desired as described above in the Function Model section.
We have discussed the functionality of Oasis by breaking it up into seven modules. These modules are used among many threads, which are used to implement Oasis. Total number of threads are given by the following formula:
3 + f + nc + nd
One thread is used to start all other threads and then to monitor the system resources and active clients. One thread is used to wait for a connection at a particular port. One other thread is used by the user interface of Oasis, which currently just displays the logs generated by the Manager Modules. f threads are used as worker threads for doing file I/O. nc + nd threads are used for doing network I/O for command and data channels respectively, where f, nc, and nd are either the number of processors the machine has or a concurrency level which is chosen by Windows NT.
Current implementation of Oasis consists of a project with more then two dozen C++ and header files that were written with Visual C++ 4.2. This project generates a single executable file and two DLLs. The executable is the core of Oasis. The two DLLs are used as plug-ins to Oasis. One of them is a generic Internal Abstraction Layer that implements allows Module Interfaces to communicate with Module Cores that reside on the same machine. The second DLL is a Database Abstractor that implements a simple database using flat files. The use of these DLLs allows for easy expansion to the system, without recompilation of Oasis.