Celerra

DART file server software executes entirely in the kernel—a real-time kernel, the design of which is based on monotonic scheduling. The DART kernel environment is not a generic user-application environment. Instead, the DART kernel provides a run-time environment for the file service; an embedded, dedicated application. The DART file server software is linked with the kernel into a single system image that is loaded for execution at boot time.

DART is organized into seven layers. These layers handle all the data movement in DART, and all functionality in DART is directed at implementing the processes contained in these layers. Starting with the layer closest to the hardware and ending with the layer closest to the user interface, DART’s functionality is organized as follows :

• Layer 1: Operating system, consisting of the kernel and the kernel debugger.
• Layer 2: Hardware device drivers, consisting of media, network, and SCSI driver components.
• Layer 3: I/O layer, consisting of Continuous Media Network (CMNET), UDP, TCP/IP, CAM, Storage and components.
• Layer 4: File systems layer, consisting of Virtual File System (VFS), Security, and shared files within a Cluster.
• Layer 5: Programming Interfaces, consisting of Remote Procedure Call (RPC), Common File System (CFS), UNIX File System (UFS) and Continuous Media File System (CMFS). The Uthread (UNIX-like thread) component overlaps and interfaces with this layer and with Layer 6.
• Layer 6: Application layer, consisting of Continuous Media Stream (CMSTREAM), Common Interface File System (CIFS), PAX, NDMP, NFS, File Transfer Protocol for DART (FTPD), ONCRPC, HTTP, NIS, and SNMP components.
• Layer 7: System management and control, consisting of Management and Configuration and System components.

Layers 1 – 4 comprise functions performed within the kernel. The programmer typically uses components limited to the higher numbered layers (5 and 6) to add data moving applications.

DART’s RPC framework component provides both client and server facilities, which are implemented over STREAMS, not sockets. DART acts as an RPC server in the context of NFS, and as an RPC client in the context of NIS.

DART External environment. The DART is designed to provide rapid data movement and information sharing across a variety of hardware platforms in a networked environment. All data transfers are either request-response (pull-type for file transfers) or streaming (push-type for multimedia data) with time-sharing, real-time, or isochronous characteristics.

Two types of RPC are implemented on DART: traditional RPC, and ONC RPC. Due to DART’s multi-threaded architecture, traditional RPC has been implemented on DART with several modifications. For example, on a SUN OS, the RPC code generator, RPCGEN, assumes a single-threaded UNIX process that calls into the library directly. However, DART doesn’t have UNIX processes; but instead uses true multi-threading—that is, n threads pick up RPC messages as they come in. Therefore, when using traditional RPC in DART, an application must perform such functions as registering with the portmapper and extracting credentials and other security information from the message (or checking security without extracting).

Most of the responsibility falls on the application developer—thread creation, initialization, end point creation, initial create main loop, processing stream, reading message, and so on. The Collector, a general synchronizer (not particular to RPC) needs to be declared, whereas in ONCRPC, the collector is built in.

In addition, traditional RPC has a basic structure for receiving the message, but then the application developer must take it apart by means of xdr format and analyze it. In addition, the client-side is not fully implemented. Finally, while RPC is primarily a synchronous protocol, it is used asynchronously in DART in conjunction with mutexes, condition variables, and other types of locks.

DART implements RPC over both the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP). Each application has a single UDP stream and one TCP stream per connection, with the common IP module acting as a multiplexer.