Blue Share is designed as a highly portable, object oriented software stack. Because of the design of our software, which emphasizes heavy reuse, we are able to achieve dramatic reduction in software size. Depending on the configuration of the runtime, the Blue Share stack can be as small as 80K. A full featured client/server deployment requires only about 150K.

The platform support for Blue Share consists of three components: Layered components, Primitive components, and Optional components.

Layered Components

The Layered components consist of modules used by the Blue Share stack, but are portable across platforms and do not depend on any specific target capabilities.

Blue Share optionally provides it's own heap management subsystem. Target implementations are able to replace this component with native heap management. Blue Share's heap management is highly efficient, fast, and supports leak detection and accounting.

Blue Share also provides an optional C Runtime module. We have found that not all implementation os target C runtime libraries are equal. We have also found that certain real time operating systems do not provide the same set of routines. To remove any C runtime dependency from Blue Share, our software is provided with its own C Runtime. Target implementations are able to replace or modify this component as they wish to leverage other routines on their platform.

Auditing provides console and system logging for events encountered by the Blue Share Software. Events are classified as debug, informational, warning, critical, and intrusion. Messages can be logged to the console, to a file, or to a target specified callback routine.

Blue Share is able to achieve its performance goals through the use of a real-time scheduling module that provides a state driven applet abstraction. These applets are scheduled within the context of a target thread and allow us to maintain numerous state instances without incurring the overhead of thread context switches.

Blue Share also provides a management and configuration infrastructure. Target applications can manage the configuration of the Blue Share software either through a set of configuration APIs or through an optional persistent management facility based on XML configuration files. The Blue Share configuration facility includes a network monitor that dynamically recognizes network connectivity changes and notifies registered components. This dynamic update facility also supports any managed object.

Consistent use of containers and other data structures are an important concept within Blue Share and provides for reliability and robustness. Our layered object component provides a rich set of tools for efficient software development.

Primitive Components

Each target platform must support a minimum set of standard RTOS features. Blue Share has made every effort to minimize this set. As a result, Blue Share is able to run on a range of platforms, from small embedded RTOSs to high end enterprise servers.

Most of the Blue Share software is written using the state driven applets described above, but some components utilize the concept of separate runtime contexts known as threads. Processes, separate runtime contexts in separate address spaces, are optional, and used when Blue Share is configured in a protected mode environment.

Blue Share is a network protocol and is layered above standard TCP/IP stacks. We provide two porting layers, one for BSD style sockets and another more abstracted layer for those targets which do not support a BSD socket interface. If available, Blue Share will utilize target DNS, and network interface routines.

Target platforms can provide an optional Console API for logging and debug although no console is required.

Primitive synchronization mechanisms must exist to support the multi-threaded components of Blue Share. Blue Share also requires a system tick count with a ms granularity. A Time-of-day facility is optional, but useful in a server environment.

Optional Components

Depending on the configuration of Blue Share, certain optional components may be required.

For the protected mode implementation, Blue Share requires platform support for shared memory and shared semaphores. Communication between protected components can be done through shared memory message queues or through platform specific message queues. Data buffers can also be shared in shared memory or can be copied through message queues depending on the target environment. Client applications communicate with the Blue Share stack through dynamic libraries while the Blue Share components themselves are implement as daemon processes.

The CIFS server component requires a platform file system that can be exported through the server stack. Multiple file system APIs are supported.

If secure authentication is configured for the Blue Share stack, a security infrastructure is required. Blue Share currently supports a SASL and GSSAPI interface.