Cache channel at network nodes to pass request and data or pointer to shared buffer

This application is a continuation of Ser. No. 09/382,311 filed Aug. 24, 1999 that issued Mar. 20, 2001, as U.S. Pat. No. 6,205,475 as U.S. Pat. No. 6,205,475; which is a continuation of Ser. No. 09/144,602 filed Aug. 31, 1998, that issued Feb. 15, 2000, as U.S. Pat. No. 6,026,452; which is a division of Ser. No. 08/806,441 filed Feb. 26, 1997, that issued Apr. 6, 1999, as U.S. Pat. No. 5,892,914; which is a division of Ser. No. 08/343,477 filed Nov. 28, 1994, that issued Mar. 11, 1997, as U.S. Pat. No. 5,611,049, and that claimed priority under 35 U.S.C. § 371 from Patent Cooperation Treaty (“PCT”) International Patent Application PCT/US92/04939 filed Jun. 3, 1992.

TECHNICAL FIELD

The present invention relates generally to the technical field of multi-processor digital computer systems and, more particularly, to multi-processor computer systems in which:

1. the processors are loosely coupled or networked together;

2. data needed by some of the processors is controlled by a different processor that manages the storage of and access to the data;

3. processors needing access to data request such access from the processor that controls the data;

4. the processor controlling data provides requesting processors with access to it.

BACKGROUND ART

Within a digital computer system, processing data stored in a memory; e.g., a Random Access Memory (“RAM”) or on a storage device such as a floppy disk drive, a hard disk drive, a tape drive, etc.; requires copying the data from one location to another prior to processing. Thus, for example, prior to processing data stored in a file in a comparatively slow speed storage device such as hard disk, the data is first copied from the computer system's hard disk to its much higher speed RAM. After data has been copied from the hard disk to the RAM, the data is again copied from the RAM to the computer system's processing unit where it is actually processed. Each of these copies of the data, i.e., the copy of the data stored in the RAM and the copy of the data processed by the processing unit, can be considered to be image of the data stored on the hard disk. Each of these images of the data may be referred to as a projection of the data stored on the hard disk.

In a loosely coupled or networked computer system having several processors that operate autonomously, the data needed by one processor may be accessed only by communications passing through one or more of the other processors in the system. For example, in a Local Area Network (“LAN”) such as Ethernet one of the processors may be dedicated to operating as a file server that receives data from other processors via the network for storage on its hard disk, and supplies data from its hard disk to the other processors via the network. In such networked computer systems, data may pass through several processors in being transmitted from its source at one processor to the processor requesting it.

In some networked computer systems, images of data are transmitted directly from their source to a requesting processor. One operating characteristic of networked computer systems of this type is that, as the number of requests for access to data increase and/or the amount of data being transmitted in processing each request increases, ultimately the processor controlling access to the data or the data transmission network becomes incapable of responding to requests within an acceptable time interval. Thus, in such networked computer systems, an increasing workload on the processor controlling access to data or on the data transmission network ultimately causes unacceptably long delays between a processor's request to access data and completion of the requested access.

In an attempt to reduce delays in providing access to data in networked computer systems, there presently exist systems that project an image of data from its source into an intermediate storage location in which the data is more accessible than at the source of the data. The intermediate storage location in such systems is frequently referred to as a “cache,” and systems that project images of data into a cache are be referred to as “caching” systems.

An important characteristic of caching systems, frequently referred to as “cache consistency” or “cache coherency,” is their ability to simultaneously provide all processors in the networked computer system with identical copies of the data. If several processors concurrently request access to the same data, one processor may be updating the data while another processor is in the process of referring to the data being updated. For example, in commercial transactions occurring on a networked computer system one processor may be accessing data to determine if a customer has exceeded their credit limit while another processor is simultaneously posting a charge against that customer's account. If a caching system lacks cache consistency, it is possible that one processor's access to data to determine if the customer has exceeded their credit limit will use a projected image of the customer's data that has not been updated with the most recent charge. Conversely, in a caching system that possesses complete or absolute cache consistency, the processor that is checking the credit limit is guaranteed that the data it receives incorporates the most recent modifications.

One presently known system that employs data caching is the Berkeley Software Distribution (“BSD”) 4.3 version of the Unix timesharing operating system. The BSD 4.3 system includes a buffer cache located in the host computer's RAM for storing projected images of blocks of data, typically 8 k bytes, from files stored on a hard disk drive. Before a particular item of data may be accessed on a BSD 4.3 system, the requested data must be projected from the hard disk into the buffer cache. However, before the data may be projected from the disk into the buffer cache, space must first be found in the cache to store the projected image. Thus, for data that is not already present in a BSD 4.3 system's buffer cache, the system must perform the following steps in providing access to the data:

Locate the buffer in the RAM that contains the Least Recently Used (“LRU”) block of disk data.

Discard the LRU block of data which may entail writing that block of data back to the hard disk.

Project an image of the requested block of data into the now empty buffer.

Provide the requesting processor with access to the data.

If the data being accessed by a processor is already present in a BSD 4.3 system's data cache, then responding to a processor's request for access to data requires only the last operation listed above. Because accessing data stored in RAM is much faster that accessing data stored on a hard disk, a BSD 4.3 system responds to requests for access to data that is present in its buffer cache in approximately {fraction (1/250)}th the time that it takes to respond to a request for access to data that is not already present in the buffer cache.

The consistency of data images projected into the buffer cache in a BSD 4.3 system is excellent. Since the only path from processors requesting access to data on the hard disk is through the BSD 4.3 system's buffer cache, out of date blocks of data in the buffer cache are always overwritten by their more current counterpart when that block's data returns from the accessing processor. Thus, in the BSD 4.3 system an image of data in the system's buffer cache always reflects the true state of the file. When multiple requests contend for the same image, the BSD 4.3 system queues the requests from the various processors and sequences the requests such that each request is completely serviced before any processing commences on the next request. Employing the preceding strategy, the BSD 4.3 system ensures the integrity of data at the level of individual requests for access to segments of file data stored on a hard disk.

Because the BSD 4.3 system provides access to data from its buffer cache, blocks of data on the hard disk frequently do not reflect the true state of the data. That is, in the BSD 4.3 system, frequently the true state of a file exists in the projected image in the system's buffer cache that has been modified since being projected there from the hard disk, and that has not yet been written back to the hard disk. In the BSD 4.3 system, images of data that are more current than and differ from their source on the hard disk data may persist for very long periods of time, finally being written back to the hard disk just before the image is about to be discarded due to its “death” by the LRU process. Conversely, other caching systems exist that maintain data stored on the hard disk current with its image projected into a data cache. Network File System (“NFS®”) is one such caching system.

In many ways, NFS's client cache resembles the BSD 4.3 systems buffer cache. In NFS, each client processor that is connected to a network may include its own cache for storing blocks of data. Furthermore, similar to BSD 4.3, NFS uses the LRU algorithm for selecting the location in the client's cache that receives data from an NFS server across the network, such as Ethernet. However, perhaps one of NFS's most significant differences is that images of blocks of data are not retrieved into NFS's client cache from a hard disk attached directly to the processor as in the BSD 4.3 system. Rather, in NFS images of blocks of data come to NFS's client cache from a file server connected to a network such as Ethernet.

The NFS client cache services requests from a computer program executed by the client processor using the same general procedures described above for the BSD 4.3 system's buffer cache. If the requested data is already projected into the NFS client cache, it will be accessed almost instantaneously. If requested data is not currently projected into NFS's client cache, the LRU algorithm must be used to determine the block of data to be replaced, and that block of data must be discarded before the requested data can be projected over the network from the file server into the recently vacated buffer.

In the NFS system, accessing data that is not present in its client cache takes approximately 500 times longer than accessing data that is present there. About one-half of this delay is due to the processing required for transmitting the data over the network from an NFS file server to the NFS client cache. The remainder of the delay is the time required by the file server to access the data on its hard disk and to transfer the data from the hard disk into the file server's RAM.

In an attempt to reduce this delay, client processors read ahead to increase the probability that needed data will have already been projected over the network from the file server into the NFS client cache. When NFS detects that a client processor is accessing a file sequentially, blocks of data are asynchronously pre-fetched in an attempt to have them present in the NFS client cache when the client processor requests access to the data. Furthermore, NFS employs an asynchronous write behind mechanism to transmit all modified data images present in the client cache back to the file server without delaying the client processor's access to data in the NFS client cache until NFS receives confirmation from the file server that it has successfully received the data. Both the read ahead and the write behind mechanisms described above contribute significantly to NFS's reasonably good performance. Also contributing to NFS's good performance is its use of a cache for directories of files present on the file server, and a cache for attributes of files present on the file server.

Several features of NFS reduce the consistency of its projected images of data. For example, images of file data present in client caches are re-validated every 3 seconds. If an image of a block of data about to be accessed by a client is more than 3 seconds old, NFS contacts the file server to determine if the file has been modified since the file server originally projected the image of this block of data. If the file has been modified since the image was originally projected, the image of this block in the NFS client cache and all other projected images of blocks of data from the same file are removed from the client cache. When this occurs, the buffers in RAM thus freed are queued at the beginning of a list of buffers (the LRU list) that are available for storing the next data projected from the file server. The images of blocks of data discarded after a file modification are re-projected into NFS's client cache only if the client processor subsequently accesses them.

If a client processor modifies a block of image data present in the NFS client cache, to update the file on the file server NFS asynchronously transmits the modified data image back to the server. Only when another client processor subsequently attempts to access a block of data in that file will its cache detect that the file has been modified.

Thus, NFS provides client processors with data images of poor consistency at reasonably good performance. However, NFS works only for those network applications in which client processors don't share data or, if they do share data, they do so under the control of a file locking mechanism that is external to NFS. There are many classes of computer application programs that execute quite well if they access files directly using the Unix File System that cannot use NFS because of the degraded images projected by NFS.

Another limitation imposed by NFS is the relatively small size (8 k bytes) of data that can be transferred in a single request. Because of this small transfer size, processes executing on a client processor must continually request additional data as they process a file. The client cache, which typically occupies only a few megabytes of RAM in each client processor, at best, reduces this workload to some degree. However, the NFS client cache cannot mask NFS's fundamental character that employs constant, frequent communication between a file server and all of the client processors connected to the network. This need for frequent server/client communication severely limits the scalability of an NFS network, i.e., severely limits the number of processors that may be networked together in a single system.

Andrew File System (“AFS”) is a data caching system that has been specifically designed to provide very good scalability. Now used at many universities, AFS has demonstrated that a few file servers can support thousands of client workstations distributed over a very large geographic area. The major characteristics of AFS that permit its scalability are:

The unit of cached data increases from NFS's 8 k disk block to an entire file. AFS projects complete files from the file server into the client workstations.

Local hard disk drives, required on all AFS client workstations, hold projected file images. Since AFS projects images of complete files, its RAM is quickly occupied by image projections. Therefore, AFS projects complete files onto a client's local hard disk, where they can be locally accessed many times without requiring any more accesses to the network or to the file server.

In addition to projecting file images onto a workstation's hard disk, similar to BSD 4.3, AFS also employs a buffer cache located in the workstation's RAM to store images of blocks of data projected from the file image stored on the workstation's hard disk.

Under AFS, when a program executing on the workstation opens a file, a new file image is projected into the workstation from the file server only if the file is not already present on the workstation's hard disk, or if the file on the file server supersedes the image stored on the workstation's hard disk. Thus, assuming that an image of a file has previously been projected from a network's file server into a workstation, a computer program's request to open that file requires, at a minimum, that the workstation transmit at least one message back to the server to confirm that the image currently stored on its hard disk is the most recent version. This re-validation of a projected image requires a minimum of 25 milliseconds for files that haven't been superseded. If the image of a file stored on the workstation's hard disk has been superseded, then it must be re-projected from the file server into the workstation, a process that may require several seconds. After the file image has been re-validated or re-projected, programs executed by the workstation access it via AFS's local file system and its buffer cache with response comparable to those described above for BSD 4.3.

The consistency of file images projected by AFS start out as being “excellent” for a brief moment, and then steadily degrades over time. File images are always current immediately after the image has been projected from the file server into the client processor, or re-validated by the file server. However, several clients may receive the same file projection at roughly the same time, and then each client may independently begin modifying the file. Each client remains completely unaware of any modifications being made to the file by other clients. As the computer program executed by each client processor closes the file, if the file has been modified the image stored on the processor's hard disk is transmitted back to the server. Each successive transmission from a client back to the file server overwrites the immediately preceding transmission. The version of the file transmitted from the final client processor to the file server is the version that the server will subsequently transmit to client workstations when they attempt to open the file. Thus at the conclusion of such a process the file stored on the file server incorporates only those modifications made by the final workstation to transmit the file, and all modifications made at the other workstations have been lost. While the AFS file server can detect when one workstation's modifications to a file overwrites modifications made to the file by another workstation, there is little the server can do at this point to prevent this loss of data integrity.

AFS, like NFS, fails to project images with absolute consistency. If computer programs don't employ a file locking mechanism external to AFS, the system can support only applications that don't write to shared files. This characteristic of AFS precludes using it for any application that demands high integrity for data written to shared files.

DISCLOSURE OF INVENTION

An object of the present invention is to provide a digital computer system capable of projecting larger data images, over greater distances, at higher bandwidths, and with much better consistency than the existing data caching mechanisms.

Another object of the present invention is to provide a generalized data caching mechanism capable of projecting multiple images of a data structure from its source into sites that are widely distributed across a network.

Another object of the invention is to provide a generalized data caching mechanism in which an image of data always reflects the current state of the source data structure, even when it is being modified concurrently at several remote sites.

Another object of the present invention is to provide a generalized data caching mechanism in which a client process may operate directly upon a projected image as though the image were actually the source data structure.

Another object of the present invention is to provide a generalized data caching mechanism that extends the domain over which data can be transparently shared.

Another object of the present invention is to provide a generalized data caching mechanism that reduces delays in responding to requests for access to data by projecting images of data that may be directly processed by a client site into sites that are “closer” to the requesting client site.

Another object of the present invention is to provide a generalized data caching mechanism that transports data from its source into the projection site(s) efficiently.

Another object of the present invention is to provide a generalized data caching mechanism that anticipates future requests from clients and, when appropriate, projects data toward the client in anticipation of the client's request to access data.

Another object of the present invention is to provide a generalized data caching mechanism that maintains the projected image over an extended period of time so that requests by a client can be repeatedly serviced from the initial projection of data.

Another object of the present invention is to provide a generalized data caching mechanism that employs an efficient consistency mechanism to guarantee absolute consistency between a source of data and all projected images of the data.

Briefly the present invention in its preferred embodiment includes a plurality of digital computers operating as a network. Some of the computers in the network function as Network Distributed Cache (“NDC”) sites. Operating in the digital computer at each NDC site is an NDC that includes NDC buffers. The network of digital computers also includes one or more client sites, which may or may not be NDC sites. Each client site presents requests to an NDC to access data that is stored at an NDC site located somewhere within the network. Each item of data that may be requested by the client sites belongs to a named set of data called a dataset. The NDC site storing a particular dataset is called the NDC server terminator site for that particular dataset. The NDC site that receives requests to access data from the client site is called the NDC client terminator site. A single client site may concurrently request to access different datasets that are respectively stored at different NDC sites. Thus, while there is only a single NDC client terminator site for each client site, simultaneously there may be a plurality of NDC server terminator sites responding to requests from a single client site to access datasets stored at different NDC server terminator sites.

Each NDC in the network of digital computers receives requests to access the data in the named datasets. If this NDC site is an NDC client terminator site for a particular client site, it will receive requests from that client. However, the same NDC site that is an NDC client terminator site for one client, may also receive requests to access data from other NDC sites that may or may not be NDC client terminator sites for other client sites.

An NDC client terminator site, upon receiving the first request to access a particular named dataset from a client site, assigns a data structure called a channel to the request and stores information about the request into the channel. Each channel functions as a conduit through the NDC site for projecting images of data to sites requesting access to the dataset, or, if this NDC site is an NDC client terminator site for a particular request, the channel may store an image of the data in the NDC buffers at this NDC site. In addition to functioning as part of a conduit for transmitting data between an NDC server terminator site and an NDC client terminator site, each channel also stores data that provides a history of access patterns for each client site as well as performance measurements both for client sites and for the NDC server terminator site.

When an NDC site receives a request to access data, regardless of whether the request is from a client site or from another NDC site, the NDC first checks the NDC buffers at this NDC site to determine if a projected image of the requested data is already present in the NDC buffers. If the NDC buffers at this NDC site do not contain a projected image of all data requested from the dataset, and if the NDC site receiving the request is not the NDC server terminator site for the dataset, the NDC of this NDC site transmits a single request for all of the requested data that is not present at this NDC site from this NDC site downstream to another NDC site closer to the NDC server terminator site for the dataset than the present NDC site. If the NDC buffers of this NDC site do not contain a projected image of all data requested from the dataset, and if the NDC site receiving the request is the sever terminator site for the dataset, the NDC of this NDC site accesses the stored dataset to project an image of the requested data into its NDC buffers. The process of checking the NDC buffers to determine if a projected image of the requested data is present there, and if one is not completely present, requesting the additional required data from a downstream NDC site or accessing the stored dataset repeats until the NDC buffers of the site receiving the request contains a projected image of all requested data.

The process of one NDC site requesting data from another downstream NDC site establishes a chain of channels respectively located in each of the NDC sites that provides a conduit for returning the requested data back to the NDC client terminator site. Thus, each successive NDC site in this chain of NDC sites, having obtained a projected image of all the requested data, either by accessing the stored dataset or from its downstream NDC site, returns the data requested from it upstream to the NDC site from which it received the request. This sequence of data returns from one NDC site to its upstream NDC site continues until the requested data arrives at the NDC client terminator site. When the requested data reaches the NDC client terminator site for this request, that NDC site returns the requested data to the client site.

Thus, the network of digital computers, through the NDCs operating in each of the NDC sites in the network, may project images of a stored dataset from an NDC server terminator site to a plurality of client sites in response to requests to access such dataset transmitted from the client sites to NDC client terminator sites. Furthermore, each NDC includes routines called channel daemons that operate in the background in each NDC site. The channel daemons use historical data about accesses to the datasets, that the NDCs store in the channels, to pre-fetch data from the NDC server terminator site to the NDC client terminator site in an attempt to minimize any delay between the receipt of a request to access data from the client site and the response to that request by the NDC client terminator site.

In addition to projecting images of a stored dataset, the NDCs detect a condition for a dataset, called a concurrent write sharing (“CWS”) condition, whenever two or more client sites concurrently access a dataset, and one or more of the client sites attempts to write the dataset. If a CWS condition occurs, one of the NDC sites declares itself to be a consistency control site (“CCS”) for the dataset, and imposes restrictions on the operation of other NDC sites upstream from the CCS. The operating restrictions that the CCS imposes upon the upstream NDC sites guarantee client sites throughout the network of digital computers the same level of file consistency the client sites would have if all the client sites operated on the same computer. That is, the operating conditions that the CCS imposes ensure that modifications made to a dataset by one client site are reflected in the subsequent images of that dataset projected to other client sites no matter how far the client site modifying the dataset is from the client site that subsequently requests to access the dataset.

These and other features, objects and advantages will be understood or apparent to those of ordinary skill in the art from the following detailed description of the preferred embodiment as illustrated in the various drawing figures.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram depicting a networked, multi-processor digital computer system that includes an NDC server terminator site, an NDC client terminator site, and a plurality of intermediate NDC sites, each NDC site in the networked computer system operating to permit the NDC client terminator site to access data stored at the NDC server terminator site;

FIG. 2 is a block diagram that provides another way of illustrating the networked, multi-processor digital computer system of FIG. 1;

FIG. 3 is a block diagram depicting a structure of the NDC included in each NDC site of FIG. 1 including the NDC's buffers;

FIG. 4, made up of FIGS. 4A and 4B, is a computer program listing written in the C programming language setting forth a data structure of a channel and of a subchannel included in the channel that are used by the NDC of FIG. 3;

FIG. 5 is a table written in the C programming language that specifies the values of various flags used by the channel illustrated in FIG. 4;

FIG. 6 is a table written in the C programming language that defines the values of various flags used in specifying the state of channels;

FIG. 7 is a block diagram illustrating projected images of a single dataset being transferred through the NDC site depicted in FIG. <b>3</b> and illustrating the storage of various segments of the dataset in the NDC buffers;

FIG. 8 is a block diagram depicting a channel and a plurality of subchannels operating to access various segments of a dataset that have been projected into the NDC buffers illustrated in FIGS. 3 and 7;

FIG. 9 is a table written in the C programming language defining the message type codes for the various different Data Transfer Protocol (“DTP”) messages that can be transmitted between NDC sites;

FIG. 10, made up of FIGS. 10A and 10B, is a definition written in the C programming language of the data structure for DTP messages;

FIG. 11, made up of FIGS. 11A, <b>11</b>B, <b>11</b>C, <b>11</b>D, <b>11</b>E, <b>11</b>F, <b>11</b>G, <b>11</b>H, <b>11</b>I, are definitions written in the C programming language for various data substructures incorporated into the structures of FIGS. 4 and 10;

FIG. 12 is a definition written in the C programming language of the data structure that is used in chaining together DTP messages;

FIG. 13, made up of FIGS. 13A and 13B, is a definition written in the C programming language for a data structure that contains the channel's metadata;

FIG. 14 is a definition written in the C programming language setting forth the structure of an upstream site structure that is used by the NDC of FIGS. 3 and 7 for storing information about the activity of upstream NDC sites in accessing a dataset stored at the NDC server terminator site;

FIG. 15 is a block diagram illustrating a tree of NDC sites including an NDC server terminator site having a stored file that may be accessed from a plurality of NDC client terminator sites; and

FIG. 16 is a block diagram illustrating the application of the NDC within a file server employing a network of digital computers.

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 is a block diagram depicting a networked, multi-processor digital computer system referred to by the general reference character <b>20</b>. The digital computer system <b>20</b> includes a Network Distributed Cache (“NDC®”) server site <b>22</b>, an NDC client site <b>24</b>, and a plurality of intermediate NDC sites <b>26</b>A and <b>26</b>B. Each of the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B in the digital computer system <b>20</b> includes a processor and RAM, neither of which are illustrated in FIG. <b>1</b>. Furthermore, the NDC server site <b>22</b> includes a hard disk <b>32</b> for storing data that may be accessed by the client site <b>24</b>. The NDC client site <b>24</b> and the intermediate NDC site <b>26</b>B both include their own respective hard disks <b>34</b> and <b>36</b>. A client workstation <b>42</b> communicates with the NDC client site <b>24</b> via an Ethernet Local Area Network (“LAN”) <b>44</b> in accordance with a network protocol such as that of the NFS systems identified above.

Each of the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B in the networked computer system <b>20</b> includes an NDC <b>50</b>, an enlarged version of which is depicted for intermediate site <b>26</b>A. The NDCs <b>50</b> in each of the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B include a set of computer programs and a data cache located in the RAM of the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B. The NDCs <b>50</b> together with Data Transfer Protocol (“DTP®”) messages <b>52</b>, illustrated in FIG. 1 by the lines joining pairs of NDCs <b>50</b>, provide a data communication network by which the client workstation <b>42</b> may access data on the hard disk <b>32</b> via the NDC sites <b>24</b>, <b>26</b>B, <b>26</b>A and <b>22</b>.

The NDCs <b>50</b> operate on a data structure called a “dataset.” Datasets are named sequences of bytes of data that are addressed by:

a server-id that identifies the NDC server site where source data is located, such as NDC server site <b>22</b>; and

a dataset-id that identifies a particular item of source data stored at that site, usually on a hard disk, such as the hard disk <b>32</b> of the NDC server site <b>22</b>.

The dataset-id may specify a file on the hard disk <b>32</b> of the NDC server site <b>22</b>, in which case it would likely be a compound identifier (filesystem id, file id), or it may specify any other contiguous byte sequence that the NDC server site <b>22</b> is capable of interpreting and is willing to transmit to the NDC client site <b>24</b>. For example, a dataset could be ten pages from the RAM of the NDC server site <b>22</b>. Such a ten page segment from the RAM of the NDC server site <b>22</b> might itself be specified with a filesystem-id that identifies virtual memory and a file-id that denoted the starting page number within the virtual memory.

The NDC client site <b>24</b> requests access to data from the NDC server site <b>22</b> using an NDC_LOAD message specifying whether the type of activity being performed on the dataset at the NDC client site <b>24</b> is a read or a write operation. The range of data requested with an NDC_LOAD message specifies the byte sequences within the named dataset that are being accessed by the NDC client site <b>24</b>. A single request by the NDC client site <b>24</b> may specify several disparate byte sequences, with no restriction on the size of each sequence other than it be discontiguous from all other sequences specified in the same request. Thus, each request to access data by the NDC client site <b>24</b> contains a series of range specifications, each one of which is a list of offset/length pairs that identify individual contiguous byte sequences within the named dataset.

Topology of an NDC Network

An NDC network, such as that illustrated in FIG. 1 having NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B, includes:

1. all nodes in a network of processors that are configured to participate as NDC sites; and

2. the DTP messages <b>52</b> that bind together NDC sites, such as NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B.

Any node in a network of processors that possesses a megabyte or more of surplus RAM may be configured as an NDC site. NDC sites communicate with each other via the DTP messages <b>52</b> in a manner that is completely compatible with non-NDC sites.

FIG. 1 depicts a series of NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B linked together by the DTP messages <b>52</b> that form a chain connecting the client workstation <b>42</b> to the NDC server site <b>22</b>. The NDC chain may be analogized to an electrical transmission line. The transmission line of the NDC chain is terminated at both ends, i.e., by the NDC server site <b>22</b> and by the NDC client site <b>24</b>. Thus, the NDC server site <b>22</b> may be referred to as an NDC server terminator site for the NDC chain, and the NDC client site <b>24</b> may be referred to as an NDC client terminator site for the NDC chain. An NDC server terminator site <b>22</b> will always be the node in the network of processors that “owns” the source data structure. The other end of the NDC chain, the NDC client terminator site <b>24</b>, is the NDC site that receives requests from the client workstation <b>42</b> to access data on the NDC server site <b>22</b>.

Data being written to the hard disk <b>32</b> at the NDC server site <b>22</b> by the client workstation <b>42</b> flows in a “downstream” direction indicated by a downstream arrow <b>54</b>. Data being loaded by the client workstation <b>42</b> from the hard disk <b>32</b> at the NDC server site <b>22</b> is pumped “upstream” through the NDC chain in the direction indicated by an upstream arrow <b>56</b> until it reaches the NDC client site <b>24</b>. When data reaches the NDC client site <b>24</b>, it together with metadata is reformatted into a reply message in accordance with the appropriate network protocol such as NFS, and sent back to the client workstation <b>42</b>. NDC sites are frequently referred to as being either upstream or downstream of another NDC site. The downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B must be aware of the types of activities being performed at its upstream NDC sites <b>26</b>A, <b>26</b>B or <b>24</b> at all times.

In the network depicted in FIG. 1, a single request by the client workstation <b>42</b> to read data stored on the hard disk <b>32</b> is serviced in the following manner:

1. The request flows across the Ethernet LAN <b>44</b> to the NDC client site <b>24</b> which serves as a gateway to the NDC chain. Within the NDC client site <b>24</b>, an NDC client intercept routine <b>102</b>, illustrated in FIGS. 3 and 7, inspects the request. If the request is an NFS request and if the request is directed at any NDC site <b>24</b>, <b>26</b>A, <b>26</b>B, or <b>22</b> for which the NDC client site <b>24</b> is a gateway, then the request is intercepted by the NDC client intercept routine <b>102</b>.

2. The NDC client intercept routine <b>102</b> converts the NFS request into a DTP request, and then submits the request to an NDC core <b>106</b>.

3. The NDC core <b>106</b> in the NDC client site <b>24</b> receives the request and checks its NDC cache to determine if the requested data is already present there. If all data is present in the NDC cache of the NDC client site <b>24</b>, the NDC <b>50</b> will copy pointers to the data into a reply message structure and immediately respond to the calling NDC client intercept routine <b>102</b>.

4. If all the requested data isn't present in the NDC cache of the NDC client site <b>24</b>, then the NDC <b>50</b> will access any missing data elsewhere. If the NDC site <b>24</b> were a server terminator site, then the NDC <b>50</b> would access the filesystem for the hard disk <b>34</b> upon which the data would reside.

5. Since the NDC client site <b>24</b> is a client terminator site rather than a server terminator site, the NDC <b>50</b> must request the data it needs from the next downstream NDC site, i.e., intermediate NDC site <b>26</b>B in the example depicted in FIG. <b>1</b>. Under this circumstance, DTP client interface routines <b>108</b>, illustrated in FIGS. 3 and 7, are invoked to request from the intermediate NDC site <b>26</b>B whatever additional data the NDC client site <b>24</b> needs to respond to the current request.

6. A DTP server interface routine <b>104</b>, illustrated in FIGS. 3 and 7, at the downstream intermediate NDC site <b>26</b>B receives the request from the NDC <b>50</b> of the NDC client site <b>24</b> and processes it according to steps 3, 4, and 5 above. The preceding sequence repeats for each of the NDC sites <b>24</b>, <b>26</b>B, <b>26</b>A and <b>22</b> in the NDC chain until the request reaches the server terminator, i.e., NDC server site <b>22</b> in the example depicted in FIG. 1, or until the request reaches an NDC site that has all the data that is being requested of it.

7. When the NDC server terminator site <b>22</b> receives the request, its NDC <b>50</b> accesses the source data structure. If the source data structure resides on a hard disk, the appropriate file system code (UFS, DOS, etc.) is invoked to retrieve the data from the hard disk <b>32</b>.

8. When the file system code on the NDC server site <b>22</b> returns the data from the hard disk <b>32</b>, a response chain begins whereby each downstream site successively responds upstream to its client, e.g. NDC server site <b>22</b> responds to the request from intermediate NDC site <b>26</b>A, intermediate NDC site <b>26</b>A responds to the request from intermediate NDC site <b>26</b>B, etc.

9. Eventually, the response percolates up through the sites <b>22</b>, <b>26</b>A, and <b>26</b>B to the NDC client terminator site <b>24</b>.

10. The NDC <b>50</b> on the NDC client site <b>24</b> returns to the calling NDC client intercept routine <b>102</b>, which then packages the returned data and metadata into an appropriate network protocol format, such as that for an NFS reply, and sends the data and metadata back to the client workstation <b>42</b>.

The NDC client intercept routines <b>102</b> are responsible for performing all conversions required between any supported native protocol, e.g. NFS, Server Message Block (“SMB”), Novelle Netware®, etc., and the DTP messages <b>52</b> employed for communicating among the NDCs <b>50</b> making up the NDC chain. The conversion between each native protocol and the DTP messages <b>52</b> must be so thorough that client workstations, such as the client workstation <b>42</b>, are unable to distinguish any difference in operation between an NDC <b>50</b> functioning as a server to that workstation and that workstation's “native” server.

An alternative way of visualizing the operation of the NDCs <b>50</b>′ is illustrated in FIG. <b>2</b>. Those elements depicted in FIG. 2 that are common to the digital computer system <b>20</b> depicted in FIG. 1 bear the same reference numeral distinguished by a prime (“′”) designation. The NDCs <b>50</b>′ in the sites <b>22</b>′, <b>26</b>A′, <b>26</b>B′ and <b>24</b>′ provide a very high speed data conduit <b>62</b> connecting the client intercept routines <b>102</b> of the NDC client site <b>24</b>′ to file system interface routines <b>112</b> of the NDC server site <b>22</b>′, illustrated in FIGS. 3 and 7. Client workstations, using their own native protocols, may plug into the data conduit <b>62</b> at each of the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> via the NDC's client intercept routines <b>102</b> in each of the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>. Accordingly, the NDC <b>50</b> of the intermediate NDC site <b>26</b>A may interface into a Novelle Netware network <b>64</b>. Similarly, the NDC <b>50</b> of the intermediate NDC site <b>26</b>B may interface into a SMB network <b>66</b>, and into an NFS network <b>68</b>. If an NDC site <b>24</b>, <b>26</b>B, <b>26</b>A or <b>22</b> is both the client terminator site and the server terminator site for a request to access data, then the NDC data conduit <b>62</b> is contained entirely within that NDC site <b>24</b>, <b>26</b>B, <b>26</b>A or <b>22</b>.

After an NDC <b>50</b>′ intercepts a request from a client workstation on one of the networks <b>44</b>′, <b>64</b>, <b>66</b> or <b>68</b> and converts it into the DTP messages <b>52</b>′, the request travels through the data conduit <b>62</b> until all the data has been located. If a request is a client's first for a particular dataset, the DTP messages <b>52</b>′ interconnecting each pair of NDCs <b>50</b>′ form the data conduit <b>62</b> just in advance of a request's passage. If a request reaches the NDC server terminator site <b>22</b>′, the NDC <b>50</b>′ directs it to the appropriate file system on the NDC server terminator site <b>22</b>′. Each NDC site <b>22</b>′ may support several different types of file systems for hard disks attached thereto such as the hard disks <b>32</b>′, <b>34</b>′, and <b>36</b>′.

After the file system at the NDC server terminator site <b>22</b>′ returns the requested data to its NDC <b>50</b>′, the NDC <b>50</b>′ passes the reply data and metadata back up through each NDC site <b>26</b>A′ and <b>26</b>B′ until it reaches the client terminator <b>24</b>′. At the client terminator <b>24</b>′, the NDC routine originally called by the NDC client intercept routine <b>102</b> returns back to that routine. The NDC client intercept routine <b>102</b> then reformats the data and metadata into an appropriately formatted reply message and dispatches that message back to the client workstation <b>42</b>′.

Four components of the NDC <b>50</b>′ support the data conduit <b>62</b>:

The resource management mechanisms of the NDC client terminator site that measure the rate at which its client workstations consume data and also notes whether the data is being accessed sequentially. Each NDC <b>50</b>′ also measures the rate of replenishment from downstream NDC sites.

The pre-fetch mechanism that enables each of the NDC sites <b>22</b>′, <b>24</b>′, <b>26</b>A′ and <b>26</b>B′ to operate autonomously, thereby reducing network traffic substantially and enabling each NDC site to directly respond to requests from client workstations or upstream NDC sites.

The DTP message <b>52</b>′ which allows multiple data segments of any length to be transferred with a single request.

The consistency control mechanism that very efficiently monitors and maintains the integrity of all projections of data from the NDC server terminator site <b>22</b>′ to the NDC client terminator site <b>24</b>′.

NDC <b>50</b>

As depicted in FIGS. 3 and 7, the NDC <b>50</b> includes five major components:

client intercept routines <b>102</b>;

DTP server interface routines <b>104</b>;

NDC core <b>106</b>;

DTP client interface routines <b>108</b>; and

file system interface routines <b>112</b>.

Routines included in the NDC core <b>106</b> implement the function of the NDC <b>50</b>. The other routines <b>102</b>, <b>104</b>, <b>108</b> and <b>112</b> supply data to and/or receive data from the NDC core <b>106</b>. The main building block of the NDC core <b>106</b> is a data structure called a channel <b>116</b> illustrated in FIG. <b>4</b>. The NDC core <b>106</b> typically includes anywhere from 2,000 to 100,000 channels <b>116</b>, depending on the size of the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B. The RAM in each NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B that is occupied by the channels <b>116</b> is allocated to the NDC <b>50</b> upon initialization of the NDC site. Each channel <b>116</b> is a conduit for projecting images of a dataset further upstream, or, if the channel <b>116</b> for the dataset is located in the client terminator site <b>24</b>, it also provides the space into which the data images are projected. The routines of the NDC core <b>106</b>, described in greater detail below, are responsible for maintaining data images within the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B or expediting their passage through the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B.

FIG. 5 is a table written in the C programming language that specifies the values of various flags used in controlling the operation of the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>. FIG. 6 is a table written in the C programming language that lists the values of various flags used in specifying the state of channels <b>116</b>. Depending upon the operation of the NDC <b>50</b>, the values of various ones of the flags listed in FIGS. 5 and 6 will be assigned to the channels <b>116</b> or other data structures included in the NDC <b>50</b>.

FIGS. 3 and 7 illustrate the client intercept routines <b>102</b>, that are needed only at NDC sites which may receive requests for data in a protocol other than DTP, e.g., a request in NFS protocol, SMB protocol, or another protocol, are completely responsible for all conversions necessary to interface a projected dataset image to a request that has been submitted via any of the industry standard protocols supported at the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B.

NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B are always equipped with both the DTP server interface routines <b>104</b> and the DTP client interface routines <b>108</b>. NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B communicate via the DTP messages <b>52</b> which move raw data, independent not only of any protocol such as NFS, SMB, or Netware, but also of any structure other than byte sequences within an identified dataset. The DTP messages <b>52</b> enable a single request to specify multiple segments of a named set of data as the targets of a single operation. Each segment specified in a DTP request is a sequence of consecutive bytes of data of any length.

The file system interface routines <b>112</b> are included in the NDC <b>50</b> only at NDC file server sites, such as the NDC server site <b>22</b>. The file system interface routines <b>112</b> route data between the disk drives <b>32</b>A, <b>32</b>B and <b>32</b>C illustrated in FIG. <b>3</b> and the NDC data conduit <b>62</b> that extends from the NDC server terminator site <b>22</b> to the NDC client terminator site <b>24</b>.

Another illustration of the NDC <b>50</b>, depicted in FIG. 7, portrays an NDC data conduit <b>62</b> passing through an NDC site, such as the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B. The NDC data conduit <b>62</b>, stretching from the NDC server terminator site <b>22</b> to the NDC client terminator site <b>24</b>, is composed of the channels <b>116</b> at each NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B that have bound together to form an expressway for transporting data between the NDC server terminator site <b>22</b> and the NDC client terminator site <b>24</b>. Each channel <b>116</b> in the chain of NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B is capable of capturing and maintaining images of data that pass through it, unless a concurrent write sharing (“CWS”) condition exists for that data. However, whether a channel <b>116</b> opts to capture an image of data passing through the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B depends heavily upon the location of the channel <b>116</b> in the NDC data conduit <b>62</b>. There are three possible locations for a channel <b>116</b> in the NDC data conduit <b>62</b>.

First, a channel <b>116</b> may be located at the NDC client terminator site <b>24</b> in which case images of data are projected and sustained within the NDC site by the routines in the NDC core <b>106</b> with substantial assistance from the DTP client interface routines <b>108</b>. The NDC <b>50</b> at the NDC client terminator site <b>24</b> services requests from clients, such as the client workstation <b>42</b>, directly from projected images via the client intercept routines <b>102</b>. Most image projections are sustained only in client terminator sites, such as thee NDC client terminator site <b>24</b>.

Second, a channel <b>116</b> may be located at an intermediate NDC site, such as the intermediate NDC sites <b>26</b>A or <b>26</b>B, in which case images are usually projected within the NDC site only for the minimum time required for the data to traverse the NDC site. However, if a CWS condition exists for a channel <b>116</b>, the channel <b>116</b> at an intermediate NDC site <b>26</b>A or <b>26</b>B that controls the consistency of the data will capture and sustain images that otherwise would have been projected further upstream to the NDC client terminator site <b>24</b>. The NDC <b>50</b> at an intermediate NDC site <b>26</b>A or <b>26</b>B employs the DTP server interface routines <b>104</b>, the routines of the NDC core <b>106</b>, and the DTP client interface routines <b>108</b> to provide these functions.

Third, a channel <b>116</b> may be located at a server terminator, such as the NDC server terminator site <b>22</b>, in which case images are usually projected within the NDC site only for the minimum time required for the data to traverse the site. The NDC <b>50</b> at an NDC server terminator site <b>22</b> employs the DTP server interface routines <b>104</b>, the routines in the NDC core <b>106</b>, and the file system interface routines <b>112</b>. NDC server terminator sites operate in most respects similar to a intermediate NDC site. However, if the NDC server terminator site <b>22</b> lacks requested data, it invokes one of the file system interface routines <b>112</b> instead of a DTP client interface routines <b>108</b> to obtain the needed data.

If the client intercept routines <b>102</b> of the NDC <b>50</b> receives a request to access data from a client, such as the client workstation <b>42</b>, it prepares a DTP request indicated by the arrow <b>122</b> in FIG. <b>3</b>. If the DTP server interface routines <b>104</b> of the NDC <b>50</b> receives a request from an upstream NDC <b>50</b>, it prepares a DTP request indicated by the arrow <b>124</b> in FIG. <b>3</b>. DTP requests <b>122</b> and <b>124</b> are presented to the NDC core <b>106</b>. Within the NDC core <b>106</b>, the DTP request <b>122</b> or <b>124</b> cause a buffer search routine <b>126</b> to search a pool <b>128</b> of NDC buffers <b>129</b>, as indicated by the arrow <b>130</b> in FIG. 3, to determine if all the data requested by either the routines <b>102</b> or <b>104</b> is present in the NDC buffers <b>129</b> of this NDC <b>50</b>. (The channel <b>116</b> together with the NDC buffers <b>129</b> assigned to the channel <b>116</b> may be referred to collectively as the NDC cache.) If all the requested data is present in the NDC buffers <b>129</b>, the buffer search routine <b>126</b> prepares a DTP response, indicated by the arrow <b>132</b> in FIG. 3, that responds to the request <b>122</b> or <b>124</b>, and the NDC core <b>106</b> appropriately returns the DTP response <b>132</b>, containing both data and metadata, either to the client intercept routines <b>102</b> or to the DTP server interface routines <b>104</b> depending upon which routine <b>102</b> or <b>104</b> submitted the request <b>122</b> or <b>124</b>. If the client intercept routine <b>102</b> receives DTP response <b>132</b>, before the client intercept routine <b>102</b> returns the requested data and metadata to the client workstation <b>42</b> it reformats the response from DTP to the protocol in which the client workstation <b>42</b> requested access to the dataset, e.g. into NFS, SMB, Netware or any other protocol.

If all the requested data is not present in the NDC buffers <b>129</b>, then the buffer search routine <b>126</b> prepares a DTP downstream request, indicated by the arrow <b>142</b> in FIG. 3, for only that data which is not present in the NDC buffers <b>129</b>. A request director routine <b>144</b> then directs the DTP request <b>142</b> to the DTP client interface routines <b>108</b>, if this NDC <b>50</b> is not located in the NDC server terminator site <b>22</b>, or to the file system interface routines <b>112</b>, if this NDC <b>50</b> is located in the NDC server terminator site <b>22</b>. After the DTP client interface routines <b>108</b> obtains the requested data together with its metadata from a downstream NDC site <b>22</b>, <b>26</b>A, etc. or the file system interface routines <b>112</b> obtains the data from the file system of this NDC client terminator site <b>24</b>, the data is stored into the NDC buffers <b>129</b> and the buffer search routine <b>126</b> returns the data and metadata either to the client intercept routines <b>102</b> or to the DTP server interface routines <b>104</b> as described above.

Channels <b>116</b>

The NDC <b>50</b> employs channels <b>116</b> to provide a data pathway through each NDC site <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B, and to provide a structure for storing a history of patterns of accessing each dataset for each client, such as the client workstation <b>42</b>, as well as performance measurements on both clients and the NDC server terminator site <b>22</b>. Using this information, the NDC <b>50</b> is able to anticipate future demand by the client, such as the client workstation <b>42</b>, and the latencies that will be incurred on any request that must be directed downstream toward the NDC server terminator site <b>22</b>.

Channels <b>116</b> are the main data structure making up the NDC <b>50</b>. Each channel <b>116</b> enables an image of data to be projected into the site. For small datasets (144 k or less), the image will often reflect the entire dataset. For larger datasets, the image may consist of one or more partial images of the dataset. A dataset may be projected concurrently into several NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B. In all NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B, at all times, the projected image will exactly match the current state of the dataset. A channel <b>116</b> belonging to the NDC <b>50</b> at either of the intermediate NDC sites <b>26</b>A or <b>26</b>B may be referred to as an “intermediate channel.”

A channel <b>116</b> may exist within an NDC <b>50</b> without containing any projections of the data with which it is associated. This would be the normal state of a channel <b>116</b> that's participating in the CWS of data.

A CWS condition exists if multiple clients, such at the client workstation <b>42</b>, are simultaneously accessing the same dataset, and at least one of them is writing the dataset. In this mode of operation, referred to as concurrent mode, images are projected into an NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B for only a very brief period between the receipt of the reply from a downstream NDC site, e.g., the receipt by intermediate NDC site <b>26</b>B of a reply from intermediate NDC site <b>26</b>A, and the forwarding of the reply upstream, e.g. the forwarding of a reply from intermediate NDC site <b>26</b>B to NDC client terminator site <b>24</b>, or the forwarding of the reply into the client intercept routines <b>102</b>, if the site is the NDC client terminator site <b>24</b>.

Channels <b>116</b> that don't maintain a projected image of data when a CWS condition exists still serve an important function in the overall operation of the digital computer system <b>20</b>. In addition to data, each channel <b>116</b> stores other information that:

measures the rate at which the client, e.g. the client workstation <b>42</b>, consumes data;

monitors the client's access pattern, i.e. random or sequential;

measures the response latencies for downstream services such as requesting access to data from the NDC server terminator site <b>22</b>; and

monitors the activities of upstream sites to detect the presence of a CWS condition.

Thus, each channel <b>116</b> is much more than just a cache for storing an image of the dataset to which it's connected. The channel <b>116</b> contains all of the information necessary to maintain the consistency of the projected images, and to maintain high performance through the efficient allocation of resources. The channel <b>116</b> is the basic structure through which both control and data information traverse each NDC site <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B, and is therefore essential for processing any request. The following sections describe more completely the structure and use of channels <b>116</b>.

Structure of Channel

116

FIG. 4 discloses the presently preferred structure for the channel <b>116</b> in the “C” programming language. The salient features of FIG. 4 are:

each channel <b>116</b> can be linked into a hash list;

each channel <b>116</b> can be linked into a channel free list;

each channel <b>116</b> contains a considerable amount of state information, including:

the dataset handle (identifies: server, filesystem, file) for data with which the channel <b>116</b> is associated;

a cached copy of the dataset's attributes;

if the dataset is a directory, a pointer to a cached image of the directory, already formatted for transmission upstream;

an indicator specifying how far write data must be flushed downstream before responding back to the client;

pointers to the current request message that's being processed and any currently outstanding upstream or downstream messages that have been issued by the NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B in the process of executing the request;

a pointer to a list of NDC_UPSTREAM_SITE structures that keep track of all upstream activity;

the address of the next level downstream site; and

measurements on the channel data rate, dataset data rate, and a count of the number of requests that exactly spliced onto the end of a previous request; and

each channel <b>116</b> contains a single instance of a structure for a subchannel <b>152</b>, illustrated in FIG. 4B, which contains pointers to any NDC buffers <b>129</b>, illustrated in FIG. 3, into which any portion of the dataset is currently being projected.

Each channel <b>116</b>, including its built-in subchannel <b>152</b>, occupies about 500 bytes of RAM. The RAM occupied by any NDC buffer <b>129</b>, illustrated in FIG. 3, that hold data image projections is in addition to the amount of RAM occupied by each channel <b>116</b>. However, pointers to the NDC buffers <b>129</b> are included in the RAM occupied by each channel <b>116</b>. Also, all NDC metadata, i.e., information about the named set of data such as file attributes (attr), server name (server_pid), filesystem id (NDC_FH.fsid), and file id (NDC_FH.fid) illustrated in FIG. 4, is projected directly into the channel structure (NDC_STATS and NDC_ATTR).

The channel <b>116</b> may contain complete or partial images of a file or of a directory. The channel <b>116</b> is capable of projecting an image of a complete file from the NDC server terminator site <b>22</b> into the NDC client terminator site <b>24</b>, even if the file is very large. However, issues of shared resource management will usually preclude projecting large data images from the NDC server terminator site <b>22</b> into the NDC client terminator site <b>24</b>.

Any image of data that is projected from the NDC server terminator site <b>22</b> into the NDC client terminator site <b>24</b> is always valid and may be directly operated upon by the client workstation <b>42</b> either for reading or for writing without requesting further service from downstream NDC sites <b>26</b>B, <b>26</b>A or <b>22</b>. If the client workstation <b>42</b> modifies the data, no matter how remote the client workstation <b>42</b> may be located from the NDC server terminator site <b>22</b>, any projected image segments of the data that has just been modified at any other NDC site will be removed before processing the next request for that data at that NDC site.

Subchannels

152

A channel <b>116</b> may include one or more channel structures. A channel <b>116</b> that includes only a single channel structure, such as that illustrated in FIG. 4, is referred to as a simple channel <b>116</b>. A simple channel <b>116</b> can project a single image of limited size. However, as illustrated in FIG. 8, through the use of a subchannel <b>152</b>, a simple channel <b>116</b> may be extended thus permitting it to project from a file <b>156</b> a segment <b>158</b> of contiguous data that is larger than that which can be projected using only a simple channel <b>116</b>. A channel structure made up of a channel <b>116</b> and one or more subchannels <b>152</b>, illustrated in FIG. 8, may be referred to as a complex channel <b>116</b>. As described previously and illustrated in FIG. 8, the NDC <b>50</b> always projects images of data from a file <b>156</b> in segment <b>158</b>. Each segment <b>158</b> illustrated in FIG. 8 is a series of consecutive bytes from the file <b>156</b> specified by offset and seg_length variables stored in the structure of a subchannel <b>152</b>. Moreover, the channel <b>116</b> may also include additional subchannels <b>152</b> that project discontiguous segments <b>158</b> from the file <b>156</b>. An image projection that is larger than that accommodated by the single subchannel <b>152</b> included in a channel <b>116</b> requires that the subchannel <b>152</b> be extended thereby creating a complex channel <b>116</b>. Multiple subchannels <b>152</b> are linked via the extent pointer (*ext) <b>162</b> of the subchannel <b>152</b> to form a logical subchannel that can project an image of any size.

Multiple Image Projections

Each channel <b>116</b> may also support several different, non-overlapping image projections simultaneously. Each projection requires one logical subchannel. The next subchannel pointer (*next) <b>164</b> of each subchannel <b>152</b> links together the logical subchannels.

The ability to project multiple images of the same dataset facilitates simultaneously servicing several clients, such as the client workstation <b>42</b>. Small datasets are usually completely projected by a single channel <b>116</b>, and this single projection is shareable. If several clients, such as the client workstation <b>42</b>, access a large dataset sequentially but are each operating in different areas of the dataset, then projections are generated as required to provide local images of the segments <b>158</b> being accessed by the different client workstations such as the client workstation <b>42</b>. Furthermore, the NDC <b>50</b> may project several images, each image being of a discontiguous segment <b>158</b> from a single file, for a single client if that client is performing a significant amount of sequential processing in several different areas of a large file. Under such circumstances, each segment <b>158</b> from the file <b>156</b> would have its own projection.

If a projected image grows or shifts to such an extent that it would abut or overlap another image, the NDC <b>50</b> coalesces both images into a single segment <b>158</b>. Thus, segments <b>158</b> are always separated from each other by at least one byte of non-projected data.

Another characteristic of a channel <b>116</b> having multiple projections is that all of its subchannels <b>152</b> are ordered in increasing offset into the dataset.

The channel <b>116</b>, the subchannel <b>152</b>, and subchannel <b>152</b> extending a subchannel <b>152</b> all use the same structure that is disclosed in FIG. <b>4</b>. When the structure disclosed in FIG. 4 is used as a subchannel <b>152</b> or to extend a subchannel <b>152</b>, some fields remain unused. Although this wastes some space in RAM, it enables complex channels <b>116</b> to grow on demand without requiring three different resources and the mechanisms to allocate and control them.

Channel Free List

Channels <b>116</b> that are not in active use, even though they probably are still valid and have connections to datasets complete with projections of both data and NDC metadata, are placed on the channel free list. All channels <b>116</b> that are not being used for servicing a request are placed on the channel free list. Conversely, any channel <b>116</b> that is currently engaged in responding to a request will not be on the channel free list.

The channel free list is formed by linking all free channels together via their av_forw and av_back pointers. The channels <b>116</b> on the channel free list are ordered according to the length of time since their last usage. Whenever a channel <b>116</b> is used, it is removed from the channel free list and marked C_BUSY. After the process that claimed the channel <b>116</b> has completely finished its task, C_BUSY is cleared and the channel <b>116</b> is linked onto the end of the channel free list. Repeated use of this simple process results in the “time since last use” ordering of the channel free list.

When the NDC <b>50</b> receives a new request specifying a dataset for which there is currently no channel <b>116</b> connection, a new channel <b>116</b> is allocated and assigned to serve as the pathway to the dataset. When a new channel <b>116</b> is required, the least recently used channel <b>116</b> is removed from the head of the channel free list, marked as C_BUSY and invalid, all state associated with the prior request is discarded, and the channel <b>116</b> is re-allocated to the requesting process.

There are two caveats to the preceding procedure:

A channel <b>116</b> that has just been removed from the head of the channel free list may contain modified data or NDC metadata that must be flushed downstream to the NDC server terminator site <b>22</b>. The presence of a C_DELAYED_WRITE flag in the channel <b>116</b> indicates the existence of this condition.

A channel <b>116</b> may be a complex channel <b>116</b> which must be broken up since, initially, all channels <b>116</b> begin as simple channels <b>116</b> and may grow to become complex channels <b>116</b>.

The NDC <b>50</b> includes routines called channel daemons that perform general maintenance functions on the channel <b>116</b> that are needed to keep each NDC site <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B at a peak level of readiness. The channel daemons perform their function in background mode when the NDC <b>50</b> is not busy responding to requests to access data. The NDC <b>50</b> invokes the appropriate channel daemon whenever there are no requests to be serviced. During periods of peak load, when requests to access data are pending, the NDC <b>50</b> suspends operation of the channel daemons, and the tasks normally performed by the channel daemons are, instead, performed directly by the request processing routines themselves.

Channel daemons:

maintain the channel free list,

schedule the loading and unloading of channels <b>116</b>, and

load and unload channels <b>116</b>.

There are specialized channel daemons that perform each of these functions. A Reaper daemon routine maintains the channel free list, a Loadmaster daemon routine prioritizes the demands of competing channels <b>116</b>, and supervisor daemon routines service channels <b>116</b> that they receive from the Loadmaster daemon routine to ensure that the channels <b>116</b> are prepared to immediately respond to the next incoming request to access data.

The process of claiming a channel <b>116</b> from the channel free list occurs while the NDC <b>50</b> is servicing a request. Any time required to handle either of the two caveats identified above increases the time required to respond to the request. When there are several NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and/or <b>26</b>B between the client workstation <b>42</b> and the NDC server terminator site <b>22</b>, the delay at each site may compound until the time to respond to the request from the client workstation <b>42</b> becomes unacceptable. To minimize such delays, it is important to reduce the time spent in claiming a channel <b>116</b> from the channel free list.

To reduce the time required to claim a channel <b>116</b> from the channel free list, the NDC <b>50</b> implements the channel free list as five lists that are linked together. The five channel free lists are:

CQ_EMPTY

This is a list of channels <b>116</b> that have no NDC buffers <b>129</b> assigned. Channels <b>116</b> on this list may still contain dataset attributes that are still valid. The channels <b>116</b> are those that have been used least recently, and are, therefore, the prime candidates for re-assignment if a request to access data requires a new channel.

CQ_CLEAN

This is a list of channels <b>116</b> that have NDC buffers <b>129</b> assigned to them. BD_DIRTY_DATA may not be set on any NDC buffer <b>129</b> assigned to a channel <b>116</b> that is on this list. Channels that are full of useless data, e.g., data from a request that experienced a fatal disk read error, are marked with C_ERROR, and such channels <b>116</b> are enqueued at the front of the CQ_CLEAN list. Channels <b>116</b> that have percolated all the way up through a CQ_SERVICE list are enqueued at the back of the CQ_CLEAN list as soon as their data has been flushed downstream toward the NDC server terminator site <b>22</b>. Data within channels <b>116</b> that are on the CQ_CLEAN list is still valid, and may be used if it is requested before the channel <b>116</b> percolates its way up through the CQ_CLEAN list.

CQ_READY

This is a list of channels <b>116</b> that are ready to respond immediately to the next anticipated request to access data from the client workstation <b>42</b>. Channels <b>116</b> that are experiencing requests to access the dataset randomly, or channels <b>116</b> that are experiencing requests to access the dataset sequentially and are still able to immediately respond to the anticipated request stream to access data are usually enqueued at the back of the CQ_READY list when they are returned to the channel free list after being used either for responding to a request to access data, or for pre-fetching data.

CQ_SERVICE

Channels <b>116</b> on the CQ_SERVICE list have been used recently, and are approaching the point where they will be unable to respond immediately to a request to access data from the client workstation <b>42</b>. Channels <b>116</b> on the CQ_SERVICE list that contain an image of data that has been modified by the client workstation <b>42</b> may contain dirty file data or metadata that needs to be flushed downstream toward the NDC server terminator site <b>22</b>. Channels <b>116</b> on the CQ_SERVICE list that contain an image of data that is being read by the client workstation <b>42</b> may need to have additional data loaded into them from downstream so they can respond immediately to future requests to access data from the client workstation <b>42</b>. Occasionally, a channel <b>116</b> on the CQ_SERVICE list may simultaneously require both flushing of dirty data downstream, and loading of additional data from downstream.

CQ_LOCKED

The channels <b>116</b> on this list are hardwired. The channels <b>116</b> and all NDC buffers <b>129</b> allocated to them are immune from LRU replacement. All intermediate channels <b>116</b> in the intermediate NDC sites <b>26</b>A and <b>26</b>B are always placed on the CQ-LOCKED list to prevent them from being pulled out from under the corresponding upstream channel(s) <b>116</b>. Hardwired channels <b>116</b> provide dataset connections which respond in a minimum amount of time. By immunizing channels <b>116</b> on the CQ_LOCKED list from LRU replacement, the channels <b>116</b> can respond swiftly to a request to access data, particularly for applications such as real-time imaging in which minimum delay times are critical.

In the following description of the present invention, the channel free list will often be referred to in the singular, and should be thought of as a single LRU list. The present invention includes the extra complexity of five free lists so channels <b>116</b> can be emptied of C_DELAYED_WRITE data, and complex channels <b>116</b> broken down into simple channels <b>116</b> by channel daemon routines running in the background.

Channels <b>116</b> on either the CQ_READY list or the CQ_SERVICE list may contain modified data that represents the current state of the file, i.e., the underlying downstream data has been superseded by modified data from the client workstation <b>42</b>. When this condition occurs, the NDC buffers <b>129</b> assigned to the channel <b>116</b> that contain the modified data are flagged as B_DELWRI and the channel <b>116</b> is flagged as C_DELAYED_WRITE.

If the NDC <b>50</b> needs a channel <b>116</b> it first checks the CQ_EMPTY list. If the CQ_EMPTY list has no channels <b>116</b>, then the NDC <b>50</b> checks the CQ_CLEAN list. A channel <b>116</b> on this list never has any C_DELAYED_WRITE data, but it might be a complex channel <b>116</b> that needs to be broken down into simple channels <b>116</b>. If the NDC <b>50</b> finds a complex channel <b>116</b> on the CQ_EMPTY list, reduces the complex channel <b>116</b> to a collection of simple channels <b>116</b>. One channel <b>116</b> is then claimed to respond to the request to access data and all remaining simple channels <b>116</b> are enqueued at the end of the CQ_EMPTY list.

If the CQ_CLEAN list is also empty, the NDC <b>50</b> searches the CQ_READY list. Because the NDC <b>50</b> is in the process of responding to a request to access data, the NDC <b>50</b> skips down the CQ_READY list and takes the most convenient channel <b>116</b>. However, the channel <b>116</b> selected by the NDC <b>50</b> in this manner must be free of C_DELAYED_WRITE data so that no modified data will be lost.

Channel Hash Lists

When the NDC <b>50</b> begins processing a new request, the first task is to connect the request to an existing channel <b>116</b>, if it exists. The channel hash lists enable this connection to be performed very quickly. The first step in the connection function that seeks to find an existing channel <b>116</b> is to add the filesystem id and file id together and then divide this sum by the number of hash buckets. The remainder produced by the division operation is used as an index into the array of hash buckets. Each bucket contains a short list of channels <b>116</b> that are connected to files whose filesystem id and file id have been hashed into the bucket's index.

Having identified a hash bucket, the next step is to search all the channels <b>116</b> on the list for this bucket for an exact match on file server address, filesystem id, and file id. If there is a channel <b>116</b> currently connected to the desired dataset, it will be on this list regardless of whether the channel <b>116</b> is on or off the channel free list at the moment. Any channel <b>116</b> currently connected to a dataset can always be located via this hash mechanism. If a search is performed and the channel <b>116</b> isn't located, then none exists.

The c_forw and c_back fields in the structure of the channel <b>116</b> disclosed in FIG. 4 are used for linking channels <b>116</b> on a hash list. When a channel <b>116</b> is removed from the channel free list and re-assigned to access a dataset, c_forw and c_back are set and the channel <b>116</b> is immediately linked onto the appropriate hash chain.

Claiming a Channel

116

Routines called ndc_get_channel( ) and ndc_channel_relse( ) make and break connections to channels <b>116</b> within an NDC site <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B.

“Claiming” a channel <b>116</b> is the process by which the NDC <b>50</b>, for the purpose of satisfying a request that it has received to access a new dataset either from a local client via the client intercept routines <b>102</b> or from another NDC site via the DTP server interface routines <b>104</b>, acquires one of the channels <b>116</b> that was allocated to the NDC <b>50</b> upon initialization of the NDC site. In claiming a channel <b>116</b>, the ndc_get_channel( ) routine removes the channel <b>116</b> from the channel free list, marks the channel <b>116</b> C_BUSY, and assigns the channel <b>116</b> to a request. Once a channel <b>116</b> has been claimed, it is busy and unavailable for use by any other request that the NDC <b>50</b> might receive before the channel <b>116</b> is released. Thus, a channel <b>116</b> is either not busy, and can be found on the channel free list, or it is busy and committed to a request that is currently being processed.

When ndc_get_channel( ) is called to claim a channel <b>116</b>, one of several situations may arise:

The channel <b>116</b> doesn't already exist, so a channel <b>116</b> is claimed from the channel free list, assigned to servicing the current request, initialized, linked into the appropriate hash chain, and its pointer returned to the caller.

The channel <b>116</b> exists and it's not busy. The channel <b>116</b> is removed from the channel free list, it's marked C_BUSY, and its pointer is returned to the caller.

The channel <b>116</b> exists and it's busy recalling or disabling image projections at all upstream sites. A NULL pointer is immediately returned to the caller telling him to “back-off” so a consistency operation may complete before the NDC <b>50</b> performs any processing on the current request. In this situation, the caller must be a DTP server interface routines <b>104</b>, since the channel <b>116</b> can only recall/disable the channels <b>116</b> at upstream NDC sites, such as the NDC sites <b>26</b>A, <b>26</b>B. or <b>24</b>.

The channel <b>116</b> exists, is busy (C_BUSY is set), and it is not in the process of recalling or disabling the upstream NDC site that issued the current request. If this condition occurs, the requesting process enters a wait state while simultaneously requesting to be reactivated as soon as the channel <b>116</b> returns to the channel free list.

The third situation occurs very rarely. Under certain circumstances, an NDC site, e.g., intermediate NDC site <b>26</b>A, must send a message to its upstream sites, e.g. NDC sites <b>26</b>B and <b>24</b>, that recalls projected images of data that have been modified by a client, e.g. the client workstation <b>42</b>, and that disables all projected images of data that are being read. Such communications are referred to as recall/disable messages. If an NDC site, e.g., intermediate NDC site <b>26</b>A, receives a request from an enabled upstream site, e.g., intermediate NDC site <b>26</b>B, that is projecting an image of data, and the request is directed at a channel <b>116</b> that is awaiting the response to a recall/disable message that has been sent to upstream sites <b>26</b>B and <b>24</b>, a deadlock situation is imminent. The request that's just been received at this NDC site, e.g., intermediate NDC site <b>26</b>A, can't be processed until the channel <b>116</b> becomes available. But, the channel <b>116</b> won't ever be freed until all sites, e.g. NDC sites <b>26</b>B and <b>24</b>, have responded to the recall/disable messages. However, the recall/disable message will never be processed at the upstream site, e.g., NDC sites <b>26</b>B and <b>24</b>, that just transmitted the new request because the channels <b>116</b> at those sites are busy waiting for the response to their outstanding requests.

To avoid such a deadlock condition, whenever an upstream request attempts to claim a channel <b>116</b> and discovers that the channel <b>116</b> is busy, additional investigation is performed. If the channel <b>116</b> is busy processing another client's downstream request, then the NDC <b>50</b> just waits until the channel <b>116</b> becomes free, after which it claims the channel <b>116</b>, and returns its pointer to the caller.

However, if the channel <b>116</b> is busy processing an upstream request, which is a request from the CCS to all upstream sites to either recall or disable their images of projected data, and if the NDC site originating the current request, i.e., the NDC site that's trying to claim the channel <b>116</b> right now, is one of those upstream sites, then ndc_get_channel( ) routine does not pause and await the release of the channel <b>116</b>. Rather, the ndc_get_channel( ) routine immediately returns a NULL pointer to instruct the caller to release its channel <b>116</b>.

When a DTP server interface routine <b>104</b> calls the ndc_get_channel( ) routine and receives a returned value of a NULL pointer back from the routine, the DTP server interface routines <b>104</b> must reject the request it received from upstream. The response is flagged with NDC_RSP_REQUEST_REJECTED to inform the upstream site that this request has been rejected. If there are several NDC sites, such as intermediate NDC site <b>26</b>B, between the NDC site that initially rejects a request and the NDC client terminator site <b>24</b>, the rejection must pass up through all the sites until the rejection reaches the client intercept routine <b>102</b> of the NDC <b>50</b> that originally received the request. Upon receiving a rejection, the client intercept routine <b>102</b> of the NDC client terminator site <b>24</b> then backs-off. In general, backing-off is a procedure in which:

a process, such as the client intercept routine <b>102</b>, is notified that a request has been rejected;

the process, such as the client intercept routine <b>102</b>, then releases its channel <b>116</b>; and

the recall/disable process claims the channel <b>116</b>, flushes or invalidates any projected images of the dataset stored in the NDC buffers <b>129</b>, and then releases the channel <b>116</b> so the original process, such as the client intercept routine <b>102</b>, can re-claim the channel <b>116</b> and finally service the client's request.

Backing-off is always performed within client intercept routines <b>102</b>, and every client intercept routine <b>102</b> must be capable of performing this function.

The client intercept routine <b>102</b> does not pass rejections from the NDC <b>50</b> back to a network client, such as the client workstation <b>42</b>. The client workstation <b>42</b> remains totally unaware of the consistency operations performed by the NDCs <b>50</b>.

Messages being passed upstream between the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> always take precedence if they collide with a message for the same dataset being passed downstream between the NDC sites <b>24</b>, <b>26</b>B, <b>26</b>A and <b>22</b>. Sending a message upstream to disable or recall projected images at all upstream sites is the first step performed by the CCS in processing a message that has just created a CWS condition. If a collision occurs between an upstream message and a downstream message, the message being passed downstream has already lost the race to the CCS by a wide margin.

As described above, in response to a request to claim a channel <b>116</b>, the ndc_get_channel( ) routine returns either:

1. a pointer to a new or old channel <b>116</b> to the calling routine after having waited a short interval if necessary; or

2. a NULL pointer to indicate that the request for a channel <b>116</b> has been rejected and the calling routine must wait and allow consistency operations to proceed.

Channel Request Processing Operations

After a channel <b>116</b> has been claimed for the purpose of processing a request, the channel <b>116</b> is committed to that request and no other request can use the channel <b>116</b> until the current request has completely finished and released the channel <b>116</b>.

Channel commitment is a process by which client requests directed at the same dataset are sequenced such that each request is fully processed before any processing begins on the next request. However, multiple NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> may simultaneously receive requests for the same dataset. That is, two or more NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> may begin processing requests for the same dataset at about the same time, and both of them may be unaware that any other NDC site is accessing the dataset. The NDC consistency mechanism handles all such cases so it appears that there is a single queue for accessing the dataset. However, due to processing and transmission delays among the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>, the order in which each client requests access to the dataset does not determine which request is processed first. Rather, the request to be processed is the first one received by the CCS as described in greater detail below. Thus, clients that are “closer” to the CCS have a slight advantage in processing priority. This slight advantage probably cannot be detected by application programs executed by the client, such as the client workstation <b>42</b>.

The concept of committing a channel <b>116</b> to a single request until the request has been satisfied is essential to the consistency control mechanism of the NDCs <b>50</b>. For the simple cases of dataset access in which there is no CWS, NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> operate autonomously, which means that the channel <b>116</b> is released as soon as the operation at the NDC site <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> completes. That is, the channel <b>116</b> at each NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, and <b>24</b> is only committed until the response has been dispatched to the requesting client.

If a CWS condition exists, all NDC sites from the NDC client terminator site <b>24</b> down to and including the CCS (which may be located at NDC site <b>26</b>B, <b>26</b>A or <b>22</b>) operate in concurrent mode. When operating in concurrent mode, channels <b>116</b> supporting a write operation must remain committed beyond the point at which they dispatch their response to the upstream NDC site. The channels <b>116</b> operating in concurrent mode at each NDC <b>50</b> remain committed until the upstream NDC site releases them by transmitting either an NDC_FLUSH or an NDC_RELEASE message. For requests from clients to read a dataset when a CWS condition does not exist, the channel <b>116</b> is released as soon as the response has been dispatched to the requesting client. Concurrent mode operations are explained more fully below.

Channel Read Operations

When a channel <b>116</b> receives a request to read a dataset, it attempts to satisfy the request directly from images already being projected within the channel <b>116</b>. If additional data is required from downstream, the channel <b>116</b> employs a mash and load technique to fetch the downstream data.

As the original client request ripples downstream through successive NDC sites <b>26</b>B, <b>26</b>A and <b>22</b>:

the DTP server interface routine <b>104</b> at each NDC site <b>26</b>B, <b>26</b>A or <b>22</b> claims a channel <b>116</b> that is committed to servicing the request;

the incoming request is mashed against the image(s) already being projected within the channel <b>116</b> at that NDC site <b>26</b>B, <b>26</b>A or <b>22</b>; and

the NDC <b>50</b> at that NDC site <b>26</b>B, <b>26</b>A or <b>22</b> generates and dispatches a request downstream that specifies only the data that must be loaded from below in order to satisfy the request.

The request propagates from NDC site to NDC site toward the NDC server terminator site <b>22</b> until either:

1. the request mashes against an image, or set of images, of all the data requested by the immediately preceding NDC site; or

2. the request reaches the NDC server terminator site <b>22</b>.

In either case, when the request reaches an NDC site having all the requested data, there exists a series of channels <b>116</b> stretching back from that NDC site to the NDC client terminator site <b>24</b>. All channels <b>116</b>, committed to the request in progress, effectively have a protective shield surrounding them. No other request to access data may penetrate this barrier at any point.

If the chain of committed channels <b>116</b> doesn't stretch all the way to the NDC server terminator site <b>22</b>, it is possible that another request for the same data might be made at an NDC site that is downstream from this chain of channels <b>116</b>. The downstream NDC site must issue a recall/disable message to all upstream NDC sites. Upon the arrival of this recall/disable message at the downstream end of the chain of channels <b>116</b>, it is queued to await the availability of the channel <b>116</b>. As soon as the channel <b>116</b> at this NDC site responds to a load request, it is freed from its upstream commitment. The channel <b>116</b> then initiates processing on the recall/disable message and forwards the recall/disable message upstream. The recall/disable message propagates much faster than a load response because the load response has to transfer data. Thus, the recall/disable message will closely follow the load response all the way back to the NDC client terminator site <b>24</b>. As soon as the client intercept routine <b>102</b> at the NDC client terminator site <b>24</b> dispatches a response to the client such as the client workstation <b>42</b>, the recall/disable message invalidates all projected images at the NDC client terminator site <b>24</b>.

Another aspect of the channel load operation is that a downstream channel <b>116</b> never begins to respond to a request until all of the requested data is cached within the channel <b>116</b>. And, when the response is finally sent, the channel <b>116</b> need not transmit all of the requested data. The response by the channel <b>116</b> at a downstream NDC sit may be flagged as a partial response indicating that more data remains to be transmitted upstream toward the NDC client terminator site <b>24</b>. Upon receiving a partial response, the upstream NDC site immediately issues a request to the downstream NDC site for the remaining data. The downstream NDC site's response to this request may be either a full or partial response. The upstream NDC site keeps requesting more data until it receives a complete response to its original request. The downstream NDC site never releases the channel <b>116</b> until it has dispatched a full response to the upstream NDC site. In this manner, the NDCs <b>50</b> respond to each request to access data from a client site, such as the client workstation <b>42</b>, as an atomic operation.

Channel Write Operations

Datasets are always written at the furthest upstream NDC site possible. The sequence of operations performed in writing a dataset is to:

load into the NDC site an image of the portion of the dataset that will be overwritten;

write to the image of the dataset projected into the NDC site; and

flush the buffers that contain modified data downstream toward the NDC server terminator site <b>22</b>.

The following sections describe the three phases of a write operation in greater detail.

Load Phase

The NDC <b>50</b> loads each block of data that is not already present in the NDC buffers <b>129</b> and that will be only partially written into the NDC buffers <b>129</b>. The blocks are loaded by calling an ndc_load( ) routine with a “func” argument of “C_WRITE” to informs the ndc_load( ) routine that it's loading data to be overwritten by a write operation. The flow of the ndc_load( ) routine invoked with the argument C_WRITE is generally the same as it is for a read request, but there are the following differences.

If this is the first write operation since the channel <b>116</b> was created, the downstream NDC site must be informed of the write activity even if all necessary data is already present in the NDC buffers <b>129</b> of this NDC <b>50</b>. If this is the first time the dataset will be written at any NDC site, the message informing the downstream NDC site that a write operation is being performed propagates all the way to the NDC server terminator site <b>22</b>. Thus, if any other client becomes active on the dataset, the CWS condition will be detected.

Blocks that will be completely overwritten don't need to be loaded upstream to the NDC site where the write operation is being performed. Under such circumstances, the ndc_load( ) routine at the NDC site, such as the NDC client terminator site <b>24</b>, can allocate empty NDC buffers <b>129</b> to receive the data being written to the dataset.

As downstream NDC sites respond to requests for loading the data needed to perform the write operation, they are informed of the purpose of the request (message flags==NDC_SITE_WRITING), and they also are informed whether the modified data will be flushed downstream through the NDC site at the conclusion of the write operation. The initial load request also specifies a “flush-level” that specifies the security required for the modified data. Each NDC site between the NDC site writing the data and the NDC server terminator site <b>22</b> compares the flush-level to its own capabilities. If any intervening NDC site is able to provide the indicated level of security for the modified data, it flags the load request it is about to issue to its downstream NDC site with NDC_FLUSH_CONTAINED. Thus, each NDC site is able to determine the earliest moment at which the channel <b>116</b> can be released from its current commitment. If the upstream NDC site is enabled for caching, then the channel <b>116</b> can be released as soon as the data has passed through the NDC site. The associated NDC_UPSTREAM_SITE structure has noted that there is write activity occurring at the upstream site. If any other client should become active on the dataset, all modified data will be recalled from above before any transactions from the new client are processed.

If two NDC sites share a common RAM through which data passes, that data does not “clear” the downstream NDC site until it has “cleared” the upstream NDC site. In this situation, the downstream NDC site must not release the channel <b>116</b> when it responds to the original request from upstream. Instead, the downstream NDC site leaves the channel <b>116</b> busy until it receives another message from the upstream NDC site informing it that the returned data has now “cleared” the upstream NDC site. This prevents the downstream NDC site from modifying or discarding data upon which the upstream NDC site is still operating.

Write Phase

After buffers in the NDC buffer pool <b>128</b> have been allocated to receive the write data, the NDC <b>50</b> performs the write operation and all NDC buffers <b>129</b> that are modified are marked as being “dirty.”

Flush Phase

After the NDC <b>50</b> completes the write operation, only one task remains to be accomplished before a response can be dispatched to client, such as the client workstation <b>42</b>. The write data that has been entrusted to this site must be secured to the level that has been requested by the client, such as the client workstation <b>42</b>, or demanded by the NDC server terminator site <b>22</b> that owns the data. That is, the NDC site at either end of each write transaction may specify the security level. The highest level specified by either end of the write transaction will prevail. Either end of a write transaction may specify any of the following security levels.

NDC_FLUSH_TO_SERVER_DISK

NDC_FLUSH_TO_SERVER_STABLE_RAM

NDC_FLUSH_TO_SITE_DISK

NDC_FLUSH_TO_SITE_STABLE_RAM

NDC_FLUSH_TO_NOWHERE

If neither the client, such as the client workstation <b>42</b>, or the NDC server terminator site <b>22</b> cares very much whether written data is occasionally lost, and both are willing to trade data security for data speed, then the flush phase may be bypassed if both ends of a write transaction specify the security level NDC_FLUSH_TO_NOWHERE. In this case, the write operation has now been completed.

However, if either end of a write transaction specifies a security level higher than NDC_FLUSH_TO_NOWHERE, an ndc_flush( ) routine will be called to flush all dirty NDC buffers <b>129</b> to an NDC site with an acceptable level of security. Note that if the level is NDC_FLUSH_TO_SITE_STABLE_RAM and the dirty data at this NDC site is already stored in stable RAM, such as battery backed RAM or FLASH RAM, from which it will not be lost in the event of a power failure, then the ndc_flush( ) routine returns immediately.

The moment the NDC <b>50</b> modifies the data, the NDC buffer <b>129</b> is tagged as dirty. If the data in a dirty NDC buffer <b>129</b> is not flushed downstream at the first opportunity, which occurs immediately before the channel <b>116</b> is released at the conclusion of the processing of the write request, then the channel <b>116</b> is flagged as C_DELAYED_WRITE.

If a CWS condition does not exist, and if both the client, such as the client workstation <b>42</b>, and the NDC server terminator site <b>22</b> aren't concerned about losing modified data, the data flows upstream to an NDC site where it remains for an extended period of time while being modified. Eventually, the client will stop accessing the dataset, and sometime after that the channel <b>116</b> will be moved from the CQ_READY list to the CQ_CLEAN list by a Flush daemon routine. When the channel <b>116</b> is moved from the CQ_READY list to the CQ_CLEAN list, any dirty NDC buffer <b>129</b> that hasn't been flushed downstream for security reasons and is still lingering about, will be flushed at this time.

Modified data in the NDC buffers <b>129</b> of an NDC <b>50</b> becomes characterized as C_DELAYED_WRITE data if it was not flushed downstream at the first opportunity upon releasing the channel <b>116</b> at the end of a write operation. Dirty data isn't C_DELAYED_WRITE data until the routine that could have flushed the data downstream has been bypassed. When such data is finally flushed downstream, the C_DELAYED_WRITE flag is removed.

If, as part of the load phase of a write request, data is pumped upstream through an NDC site that does not cache an image of the data, the channel <b>116</b> at that NDC site must not be released. Under such circumstances, the NDC site that is writing the dataset will soon be flushing data back downstream through this NDC site as the last phase of responding to a write request.

Channel Maintenance Operations

In general, file servers, such as the NDC server terminator site <b>22</b>, are often under utilized, with their processor(s) spending a significant percentage of their time waiting for work. When engaged in processing requests as described above, NDCs <b>50</b> postpone all operations that are not essential to completing the responses. At such times, each NDC <b>50</b> performs only those operations absolutely required to respond to the requests. When there are no requests awaiting processing, the NDC <b>50</b> activates channel daemons to use the processor's “idle” time for preparing for the next volley of requests that will eventually arrive. Any process of the NDC <b>50</b> involved in directly servicing a client request preempts all daemons as soon as the current daemon, if one is operating, relinquishes control.

The Reaper Daemons

The NDC <b>50</b> invokes a Reaper daemon routine as a background task whenever the number of channels <b>116</b> enqueued on the CQ_EMPTY list drops below the CQ_EMPTY_LOW_THRESHOLD. Responding to this condition, the Reaper daemon routine iteratively removes the channel <b>116</b> at the front of the CQ_CLEAN list and releases all NDC buffers <b>129</b> assigned to it. If the channel <b>116</b> removed from the front of the CQ_CLEAN list is a complex channel <b>116</b>, the Reaper daemon routine reduces it to a collection of simple channels <b>116</b>, all of which the Reaper daemon routine places at the front of the CQ_EMPTY list. At this point in the process, the channel <b>116</b> from which the Reaper daemon routine removed all the other channels <b>116</b> may still contain valid data attributes. Under such circumstances, the Reaper daemon routine enqueues the simple channel <b>116</b> at the back of the CQ_EMPTY list because a possibility still exists that the channel <b>116</b> may be claimed for responding to a request to access the same dataset before it percolates up to the front of the CQ_EMPTY list to be claimed for responding to a request to access a different dataset.

At the end of each iterative cycle of removing a channel <b>116</b> from the front of the CQ_CLEAN list and placing one or more channels <b>116</b> on the CQ_EMPTY list, the Reaper daemon routine checks to see if any new requests to access data have been received by the NDC <b>50</b>. If a new request has been received, the Reaper daemon routine relinquishes control to the foreground task that will respond to the request. The Reaper daemon routine will only resume operation when there no longer are any more pending requests to access data.

If the number of channels <b>116</b> enqueued on the CQ_EMPTY list exceeds the CQ_EMPTY_HIGH_THRESHOLD, the Reaper daemon suspends its operation and will not again resume operating until the number of channels <b>116</b> enqueued on the CQ_EMPTY list again drops below the CQ_EMPTY_LOW_THRESHOLD.

The Flush Daemon

A Flush daemon routine locates channels <b>116</b> on the CQ_LOCKED, CQ_SERVICE, or CQ_READY lists that have been flagged as C_DELAYED_WRITE, and flushes downstream toward the NDC server terminator site <b>22</b> all NDC buffers <b>129</b> assigned to such channels <b>116</b> that are flagged as B_DELWRI. After a channel <b>116</b> has been processed by the Flush daemon routine, the channel <b>116</b> is enqueued at the end of the CQ_CLEAN, the CQ_SERVICE, or the CQ_LOCKED list depending upon the flags that are set in the channel <b>116</b>.

The Loadmaster Daemon

The NDC <b>50</b> invokes a Loadmaster daemon routine whenever there are no responses pending to requests to access data. The Loadmaster daemon routine checks channels <b>116</b> enqueued on the CQ_SERVICE list and assigns them individually to Supervisor daemon routines which perform the services required by the channel <b>116</b>. After a channel <b>116</b> has been serviced, it is enqueued on the end of the CQ_READY list.

The Supervisor Daemons

The Supervisor daemon routines receive channels <b>116</b> that have been removed from the CQ_SERVICE list by the Loadmaster daemon routine, forecast future requests to access data that will be forthcoming from the client(s), such as the client workstation <b>42</b>, and generate any requests for services from downstream NDC sites that are necessary so the channel <b>116</b> can respond immediately to a request from the client to access data. After the NDC <b>50</b> receives responses from downstream NDC sites to the requests generated by the Supervisor daemon routine, the channel <b>116</b> is enqueued at the end of the CQ_READY list.

The Loader Daemon

Loader daemon routines are low level routines that perform simple asynchronous tasks needed for the operation of the NDC <b>50</b>, such as submitting a request to a downstream NDC site or to a disk subsystem, and then waiting for a response to that request.

Channel Release

After a request has been completely serviced at an NDC site <b>22</b>, <b>24</b>, <b>26</b>A, or <b>26</b>B, the channel <b>116</b> is released. The process for releasing channels <b>116</b> operates as follows:

If dirty data is being projected within the channel <b>116</b>, the NDC <b>50</b> calls the ndc_flush( ) routine to ensure that all modified data is secured to a level acceptable to both the client and the server.

If the downstream channel <b>116</b> is still committed, the NDC <b>50</b> sends it a release message and waits until a response is received. The release message may, in some instances, propagate downstream through all NDC sites until it reaches the NDC server terminator site <b>22</b>.

If one or more processes are waiting for this channel <b>116</b> or any channel <b>116</b>, all of them are scheduled to run.

Enqueue the channel <b>116</b> at the tail of the channel free list.

Reset channel flags: C_BUSY, C_WANTED, C_ASYNC, and others.

After all of the preceding operations have been performed, the channel <b>116</b> becomes available for use by any other request that has already been received or will arrive in the future.

Channel Death

Most channels <b>116</b> eventually die. The primary cause of death is invariably lack of use. As long as channels <b>116</b> are continually used, they continue to live. When a channel <b>116</b> dies, the following operations are performed:

Any dirty data that is still being retained within the channel <b>116</b> is flushed downstream toward the NDC server terminator site <b>22</b>.

If the downstream channel <b>116</b> is still committed, the NDC <b>50</b> sends it a notification that the channel <b>116</b> is in the process of dying. This notification will piggyback on any dirty data being flushed downstream. However, at this point there usually isn't any dirty data still lingering in the channel <b>116</b>. The thresholds established for the various channel daemons cause them to flush modified data downstream toward the NDC server terminator site <b>22</b> more quickly than the channel daemons reclaim channels <b>116</b>.

After receiving a response from the NDC <b>50</b> at the downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B to the decease notification, the NDC <b>50</b> releases all resources allocated to the channel <b>116</b> and the channel <b>116</b> is flagged as invalid and empty.

If the death of the channel <b>116</b> was initiated by a demand for a new channel <b>116</b>, the channel <b>116</b> is returned to the requesting process.

If the death of the channel <b>116</b> was caused by the operation of a channel daemon, the channel <b>116</b> is enqueued at the head or tail of the CQ_EMPTY free list, depending upon whether or not the attributes for the dataset stored in the channel <b>116</b> remain valid.

Only channels <b>116</b> located at the NDC client terminator site <b>24</b> ever suffer death by lack of use. Downstream channels <b>116</b> are always enqueued on the CQ_LOCKED free list when they're not busy. Channels <b>116</b> on the CQ_LOCKED free list, immune against LRU replacement, only die when notified by their last upstream channel <b>116</b> that it is dying, or when the upstream site fails to respond to status queries and is presumed to be dead.

Downstream channels <b>116</b> are the communication links that bind the channels <b>116</b> of the NDC client terminator site <b>24</b> to the NDC server terminator site <b>22</b>. Downstream channels <b>116</b> cannot be re-allocated without isolating all upstream channels <b>116</b> from consistency control operations. If an NDC site becomes isolated temporarily from the network due to a communications failure and if any other clients remaining on the network process datasets for which the isolated NDC sites have active channels <b>116</b>, after communications are restored any data modifications performed at the formerly isolated NDC site must be rejected by downstream NDC sites when the formerly isolated NDC site subsequently attempts to flush the data back downstream toward the NDC server terminator site <b>22</b>. Thus, downstream channels <b>116</b> only die when the upstream channel <b>116</b> dies or, at least, is thought to be dead.

Data image projections are sustained in downstream channels <b>116</b> only when that channel <b>116</b> has multiple upstream connections and, even then, only under certain circumstances. So, downstream channels <b>116</b> rarely retain resources of the NDC site when enqueued on the channel free list. Only the channel structure itself, approximately 500 bytes, must remain committed to providing the linkage between the upstream and downstream sites.

When projected, NDC metadata, e.g., filesystem and file attributes, is always stored directly within the channel structure. This means that idle downstream channels <b>116</b> still retain information about the dataset to which they're connected.

The three events that can trigger the death of a channel <b>116</b> are:

The channel <b>116</b> advances to the head of the channel free list and a request is made for a new channel <b>116</b>. When this occurs, after flushing any dirty data within the channel <b>116</b> at the head of the channel free list downstream toward the NDC server terminator site <b>22</b>, the channel <b>116</b> is re-allocated to support accessing a new dataset after downstream NDC sites have been properly notified that the channel <b>116</b> is dying.

The NDC <b>50</b> receives a decease notification from the last remaining upstream NDC site that is accessing the dataset. The decease notification message causes the downstream NDC site to enter the death sequence and may result in a decease notification propagating further downstream toward the NDC server terminator site <b>22</b>.

A channel usage timer indicates that there has been no activity on the channel <b>116</b> for quite a while. If the channel <b>116</b> is located at the NDC client terminator site <b>24</b>, it can just be killed at this point. If the channel <b>116</b> is located downstream from the NDC client terminator site <b>24</b>, the channel <b>116</b> must send a status query message to all its upstream connections. This status query message indicates the urgency with which the downstream NDC site wishes to kill the channel <b>116</b>. After responding to the status query message, the upstream NDC client terminator site <b>24</b> may kill its channel, but the upstream NDC client terminator site <b>24</b> need not do so. However, upstream NDC sites must respond within a reasonable interval to the status query from the downstream NDC site or the downstream NDC site will assume the upstream channel <b>116</b> has died.

NDC Inter-Site Operations

Both control and data information must be communicated between NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>. Data communicated between NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> is always one or more byte sequences of the named dataset. Control information is a bit more complicated, and can be categorized as follows:

NDC metadata is information about the named dataset such as: filesystem and file attributes, server name, filesystem id, and file id.

DTP control is information generated by and used by the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> to ensure the consistency of all delivered data and NDC metadata.

DTP control information is interwoven into the fabric of the DTP, the protocol through which both data and NDC metadata are passed between NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>.

FIG. 9 is a table written in the C programming language that lists various different types of DTP messages <b>52</b> that may be exchanged between pairs of NDC sites, such as the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, and <b>24</b>. FIG. 10 defines a data structure in the C programming language that is used in assembling any of the various different DTP messages <b>52</b> listed in FIG. <b>9</b>. FIGS. 11A through 11I define data sub-structures in the C programming language that are incorporated into the channel <b>116</b> illustrated in FIG. <b>4</b> and in the data structure for DTP messages <b>52</b> illustrated in FIG. <b>10</b>. FIG. 12 defines a structure in the C programming language that is used in forming chains of DTP messages <b>52</b> thereby permitting several DTP messages <b>52</b> to be exchanged between NDC sites as a single atomic communication.

Metadata for each channel <b>116</b> consists of all of the data stored in each channel <b>116</b> except for the data requested by a client, such as the client workstation <b>42</b>, that is stored in the NDC buffers <b>129</b>. Two data structures in each channel <b>116</b> contain the metadata that is most vital to the performance of the channel <b>116</b>. FIG. 13A defines a data structure NDC_ATTR in the C programming language that specifies information about the named set of data to which the channel <b>116</b> is attached. FIG. 13B defines a data structure NDC_STATS in the C programming language that contains information about the file system on which the dataset resides.

Described below are the various modes in which the NDC site <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B operate, and the consistency operations that must be performed between the NDC sites <b>22</b>, <b>24</b>, <b>26</b>A and <b>26</b>B.

Modes of Operation

An NDC site <b>22</b>, <b>24</b>, <b>26</b>A and/or <b>26</b>B operates in one of two modes, autonomous or concurrent.

Autonomous Mode of Channel Operation

Whenever possible, a channel <b>116</b> services a request using only locally available resources. For clients that are accessing data sequentially, the channel <b>116</b> aggressively pre-fetches or pre-buffers ahead of the client's current requests to access data. This mode of operation for channel <b>116</b> is referred to as “autonomous.” A channel <b>116</b> is said to have operated autonomously whenever it responds to a request from a client, such as the client workstation <b>42</b>, using only data and NDC metadata cached at its NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B prior to receiving the request. Datasets no larger than 144 k bytes are usually completely stored in the NDC buffers <b>129</b> at the NDC client terminator site <b>24</b>, enabling all requests to access datasets smaller than 144 k bytes to be serviced autonomously by the NDC client terminator site <b>24</b>.

NDC sites that are permitted to cache projected images of data have a potential to operate autonomously. A channel <b>116</b> located at an NDC site that is not permitted to cache projected images of data cannot operate autonomously. Channels <b>116</b> located at NDC sites that are not permitted to cache projected images of data must always transmit a request downstream to an NDC site in responding to each request from a client, such as the client workstation <b>42</b>.

Autonomous operation of channels <b>116</b> is the major cornerstone upon which very large scale distributed file systems can be built. Autonomous operation of channels <b>116</b> provide the basis for:

Quick response times. Since the channel <b>116</b> of an NDC site <b>22</b>, <b>24</b>, <b>26</b>A or <b>26</b>B that is operating autonomously doesn't need to communicate with downstream NDC sites in responding to a request to access data from a client, the client, such as the client workstation <b>42</b>, does not experience any of the delays inherent in such communication.

High bandwidth data transfers. If the NDC client terminator site <b>24</b> is located within the client workstation <b>42</b>, the data transfer rate can be extremely high (50 to 100 Mbytes/sec). A response from the channel <b>116</b> to a client's request to access data when both the channel <b>116</b> and the client operate in the same computer need only consist of a return of pointers to the data that the channel <b>116</b> had previously stored in the NDC buffers <b>129</b> of the NDC client terminator located within the client workstation <b>42</b>.

Network scalability. For the average dataset, channels <b>116</b> located in NDC sites <b>26</b>A, <b>26</b>B or <b>24</b> that operate autonomously place no load on downstream NDC sites <b>22</b>, <b>26</b>A or <b>26</b>B after the dataset has been loaded into the NDC client terminator site <b>24</b>. Downstream NDC sites <b>22</b>, <b>26</b>A or <b>26</b>B must initially supply data and NDC metadata to the channel <b>116</b> in the NDC client terminator site <b>24</b> that operates autonomously. However, once the data and NDC metadata are respectively stored in the NDC buffers <b>129</b> of the channel <b>116</b> of the NDC <b>50</b>, the client, such as the client workstation <b>42</b>, may access the data and metadata many times without requiring any further communication between the NDC client terminator site <b>24</b> and the downstream NDC sites <b>26</b>B, <b>26</b>A or <b>22</b>. If each NDC site <b>24</b>, <b>26</b>B or <b>26</b>A does not need to repetitively request data from downstream NDC sites, the networked digital computer system <b>20</b> can support a larger number of clients, such as the client workstation <b>42</b>, with an acceptable response time.

The advantages of operating in autonomous mode are so significant that every reasonable effort is made to ensure that channels <b>116</b> operate in this mode whenever possible. The inability to operate a channel <b>116</b> autonomously is always the result of a single cause, i.e., the required data and metadata isn't being projected into the local NDC site <b>26</b>A, <b>26</b>B or <b>24</b>.

When operating in autonomous mode, an NDC site <b>22</b>, <b>26</b>A, <b>26</b>B or <b>24</b> functions in a manner similar to the CCS. Whenever possible, the channels <b>116</b> of such an NDC site respond to requests to access data from a client, such as the client workstation <b>42</b>, without communicating with downstream NDC site <b>26</b>B, <b>26</b>A or <b>22</b>. If an upstream message should arrive at an NDC site <b>26</b>A, <b>26</b>B or <b>24</b> that is operating in autonomous mode while the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> is processing a request on that same channel <b>116</b>, the upstream message must wait until the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> is able to process to it. An autonomous NDC site <b>22</b>, <b>26</b>A, <b>26</b>B or <b>24</b> has every right to operate as though it is the CCS until it is notified that it can no longer function in that manner. If the upstream message is a notification that the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> may no longer function autonomously, that notice doesn't become effective until the NDC <b>50</b> processes the message.

After the client workstation <b>42</b> first requests access to data from the NDC client terminator site <b>24</b>, the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> establish their local channels <b>116</b>, and the NDC sites <b>22</b>, <b>26</b>A and <b>26</b>B load the first data into the NDC buffers <b>129</b> of the NDC client terminator site <b>24</b>, the locally projected dataset image will always be sufficient to enable autonomous request servicing unless one of the following occurs:

Access to the same dataset by another client creates a CWS condition. If this occurs, the downstream CCS only permits images to be projected into the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> during a brief instant as the projected data passes through the NDC site <b>26</b>A, <b>26</b>B or <b>24</b>.

A client, such as the client workstation <b>42</b>, requests access to data randomly, and the dataset being accessed by the client is too large to be completely cached at the NDC client terminator site <b>24</b>. Random accesses to data by a client, such as the NDC client terminator site <b>24</b>, prevents the channel <b>116</b> from anticipating future requests from the client. If a channel <b>116</b> determines that a client, such as the client workstation <b>42</b> is accessing data randomly, the channel <b>116</b> stops pre-fetching data for that client.

If neither of the preceding conditions occur, channels <b>116</b> operate autonomously, pre-fetching data in anticipation of future requests to access data from the client, such as the client workstation <b>42</b>. Depending on the current load being supported at NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>, channels <b>116</b> at NDC sites that are operating autonomously pre-fetch data either asynchronously or synchronously.

Asynchronous Pre-fetching

A channel daemon usually pre-fetches data for a channel <b>116</b> that is operating autonomously. The channel daemon keeps the image of data projected into the channel <b>116</b> just ahead of the next request to access data that the channel <b>116</b> receives from the client, such as the client workstation <b>42</b>. If the main goal of the pre-fetch mechanism was to minimize the usage of local resources, the projected image would consist of only the exact data specified in the next client request, and the image of the data would always be projected just in advance of the client's next request. However, while this may conserve the resources at the NDC client terminator site <b>24</b>, it is very wasteful of resources of the networked digital computer system <b>20</b>. It is much more efficient for the networked digital computer system <b>20</b> to employ fewer requests and transfer larger amounts of data in response to each request to load data into the NDC client terminator site <b>24</b>. However, transferring a larger amount of data will increase any delay in responding to a client request.

To minimize the delay in responding to a client request to access data, the channel <b>116</b> usually requests from the downstream NDC site <b>26</b>B, <b>26</b>A or <b>22</b> only that data which is required to respond to the current request to access data. As soon as the channel <b>116</b> receives the data, the channel <b>116</b> responds to the client, such as the client workstation <b>42</b>. As soon as the channel <b>116</b> in the NDC client terminator site <b>24</b> responds to the request from the client, the NDC <b>50</b> begins processing any other client requests that have been queued. After the NDC <b>50</b> processes all queued client requests, channel daemons may begin operating in the background. As described above, operating channel daemons continuously check all active channels <b>116</b> to determine if the channels <b>116</b> are within one request time interval of being unable to immediately respond to a request from the client, such as the client workstation <b>42</b>.

If a channel daemon detects that a channel <b>116</b> is within one request time interval of being unable to immediately respond to a request from the client, the daemon does whatever is necessary to obtain additional data from downstream NDC sites <b>26</b>B, <b>26</b>A and <b>22</b> so the image of data projected into the channel <b>116</b> stays ahead of requests to access data from the client. For a channel <b>116</b> in the NDC client terminator site <b>24</b> that is supporting read operations on datasets, the channel daemon asynchronously issues a request to the downstream NDC site <b>26</b>B requesting roughly enough data to respond to the next eight requests from the client, such as the client workstation <b>42</b>. When the data arrives from the downstream NDC site <b>26</b>B, the channel <b>116</b> stores the data in the NDC buffers <b>129</b> selected by the daemon. The NDC buffers <b>129</b> used to receive the data are frequently the ones that are already being used by the channel <b>116</b> for the current projected image of data. In this way, that portion of the image that the NDC <b>50</b> has already presented to the client is replaced by a portion of the dataset toward which requests from the client are advancing.

If a request from the client, such as the client workstation <b>42</b>, arrives while a channel daemon is refilling the channel <b>116</b>, the NDC <b>50</b> blocks the request until the downstream operation initiated by the channel daemon completes. Thus, if channel daemons successfully anticipate client requests to access data, the channel <b>116</b> continues to operate autonomously.

Synchronous Pre-Fetching

The asynchronous mode of autonomous operation shifts as much processing as possible from the foreground task of servicing requests from the client, such as the client workstation <b>42</b>, into the background task of preparing to service the next request from the client. The strategy of shifting processing from the foreground task to the background task trades off throughput for response time. Clients, such as the client workstation <b>42</b>, experience faster response times, but the NDC site <b>22</b>, <b>26</b>A, <b>26</b>B or <b>24</b> has reduced throughput capacity. This is a reasonable trade off since NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> rarely run near their throughput capacity. However, intervals in the operation of NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b> will occur that require maximum throughput rather than minimum response time. During intervals of peak demand, a normally unused synchronous mode of pre-fetching data from downstream NDC sites replaces the asynchronous mode to maximize the throughput of the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>.

The synchronous mode of operation is activated if CPU utilization at an NDC site <b>22</b>, <b>26</b>A, <b>26</b>B or <b>24</b> exceeds a pre-established threshold. In synchronous mode, the channel daemons are not activated and the routines for responding to requests to access data no longer defer to the channel daemons the loading of data into and unloading of data from the channels <b>116</b>. When the NDC <b>50</b> operates in synchronous mode, data is requested from downstream NDC sites only if the upstream NDC site is unable to respond to a request.

If a channel <b>116</b> requires additional data and the NDC <b>50</b> is operating in synchronous mode of autonomous operation, the channel <b>116</b> requests the required data from the downstream NDC site data plus additional data to increase the efficiency of loading data into the channel <b>116</b> at this site. During intervals in which the NDC <b>50</b> operates in synchronous mode, large amounts of data are fetched directly by the channel <b>116</b> each time the channel <b>116</b> discovers that additional data not present in the NDC buffers <b>129</b> of this NDC site <b>22</b>, <b>26</b>A, <b>26</b>B or <b>24</b> is required to respond to a request. By requesting large amounts of data from downstream NDC sites only when the channel <b>116</b> is unable to respond to a request to access data, the channel <b>116</b> maximizes throughput of its NDC <b>50</b>, but clients, such as the client workstation <b>42</b>, experience additional delay each time the channel <b>116</b> is compelled to request data from a downstream NDC site <b>26</b>B, <b>26</b>A or <b>22</b>.

Concurrent Mode of Channel Operation

Projected images of data occur only in channels <b>116</b> that are operating autonomously. As explained in greater detail below, autonomous channels <b>116</b> always occur at, or downstream of, a CCS or an NDC client terminator site <b>24</b> that is functioning similar to a CCS. NDC sites <b>26</b>A, <b>26</b>B or <b>24</b> upstream of the CCS, when the CCS is located in the NDC server terminator site <b>22</b>, always operate in concurrent mode. NDC sites <b>26</b>A, <b>26</b>B or <b>24</b> upstream of the CCS, when the CCS is located in the NDC server terminator site <b>22</b>, operate as an extension of the CCS site through which the image of the dataset being projected into the CCS may be viewed.

Channels <b>116</b> operating in concurrent mode sustain an image of projected data for only the briefest period, i.e., from the time the channel <b>116</b> receives the data from the downstream NDC site until the channel <b>116</b> forwards data to the next upstream NDC site or to the client, such as the client workstation <b>42</b>. Channels <b>116</b> operating in concurrent mode always request exactly the data required to satisfy the current request, never more and never less.

Consistency Control Operations

FIG. 15 depicts a tree, indicated by the general reference character <b>200</b>, of NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, <b>24</b>, <b>202</b>, <b>204</b>A, <b>204</b>B, and <b>206</b> that are connected to the file <b>156</b>. LAN <b>44</b>A connects to NDC client terminator site <b>204</b>B while LAN <b>44</b>B connects to NDC client terminator site <b>206</b>. If a CWS condition were created by a combination of the NDC site <b>24</b> and either NDC site <b>204</b>B or <b>206</b>, NDC site <b>26</b>A becomes the CCS for the file <b>156</b>. NDC site <b>26</b>A is as far as the file <b>156</b> can be projected from the NDC server terminator site <b>22</b> without requiring a distributed cache consistency mechanism.

If a CWS condition does not exist, all NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, <b>24</b>, <b>202</b>, <b>204</b>A, <b>204</b>B, and <b>206</b> may operate autonomously. The NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, <b>24</b>, <b>202</b>, <b>204</b>A, <b>204</b>B, and <b>206</b> when operating autonomously may sustain a projected image of data that may be used to support client read and write operations over an extended period of time. Autonomous sites communicate with the next downstream NDC site <b>204</b>A, <b>202</b>, <b>26</b>B, <b>26</b>A, or <b>22</b> only when the upstream NDC site <b>206</b>, <b>204</b>A, <b>204</b>B, <b>202</b>, <b>26</b>A, <b>26</b>B, or <b>24</b> requires additional data, or when modified data must be flushed downstream toward the NDC server terminator site <b>22</b>.

However, if a CWS condition arises, the first NDC site <b>26</b>A or <b>202</b> upstream of the data source, such as the hard disk <b>32</b>, that provides multiple connections to the dataset for upstream NDC sites <b>206</b>, <b>204</b>B, or <b>24</b> must assume responsibility for maintaining the consistency and integrity of all operations being performed on the dataset. The NDC site <b>26</b>A or <b>202</b> that assumes this responsibility is located furthest from the source of the data, such as the hard disk <b>32</b>, through which must pass all requests to access the dataset from current clients, such as the client workstation <b>42</b>. Thus, if a CWS condition were created by a combination of the NDC site <b>24</b> and either NDC site <b>204</b>B or <b>206</b>, NDC site <b>26</b>A would become the CCS for the file <b>156</b>.

If one of the NDC sites <b>26</b>A or <b>202</b> declares itself to be the CCS for the dataset, the NDC site <b>26</b>A or <b>202</b>:

1. recalls the image of the dataset that has been modified from the upstream NDC client terminator site <b>206</b>, <b>204</b>B, or <b>24</b> so that its image of the data contains all the modifications; and

2. disables all other upstream projections of the data that were in use by NDC sites to support read operations on the dataset.

After completing these operations, the CCS is now the most distant NDC site into which images of the dataset will be projected. Upstream NDC sites must now operate in concurrent mode, forwarding any requests they receive to access the dataset to the CCS for processing. The CCS processes requests to access the dataset in the order they are received, and ensures completion of each request before beginning to process a succeeding request to access the dataset.

Detecting CWS

Each of the NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, <b>24</b><b>202</b>, <b>204</b>A, <b>204</b>B, and <b>206</b> independently records whether a request to access a dataset will or will not modify the dataset. As an NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b>, or <b>204</b>A processes each request to access a dataset, it compares the requested operation with the operations that are being performed on the dataset at all other upstream NDC sites. If there are multiple upstream NDC sites accessing a dataset and any one of them is writing the dataset, then a CWS condition exists. As soon as an NDC site <b>26</b>A or <b>202</b> detects a CWS, the NDC site <b>26</b>A or <b>202</b> must declare itself to be the CCS as described above.

To permit each NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b> and <b>204</b>A to detect a CWS condition, each upstream NDC site <b>206</b>, <b>204</b>A, <b>204</b>B, <b>202</b>, <b>24</b>, <b>26</b>B, and <b>26</b>A must keep its downstream NDC site informed of types of accesses, i.e., a “read” access that will not modify the dataset or a “write” access that will modify the dataset, that are being made to the dataset at the NDC client terminator site <b>206</b>, <b>204</b>B, or <b>24</b>. Each downstream NDC site <b>204</b>A, <b>202</b>, <b>26</b>B, <b>26</b>A, and <b>22</b> must record and preserve the information provided it by its upstream NDC sites until the downstream NDC site <b>204</b>A, <b>202</b>, <b>26</b>B, <b>26</b>A, or <b>22</b> is notified of the death of the channel <b>116</b> at the upstream NDC site.

Informing Downstream NDC Sites

If a client, such as the client workstation <b>42</b>, begins accessing a dataset with a new type of access, e.g., accessing the dataset with a “write” operation when all previous accesses have been “read” operations, the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> responding to requests from the client must inform the downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B. Usually, this notification takes place automatically when the NDC site <b>26</b>A, <b>26</b>B or <b>24</b> requests access (NDC_LOAD message) to the dataset from the downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B. Since each NDC site <b>24</b>, <b>26</b>B and <b>26</b>A requests only the data that is not present in its NDC buffers <b>129</b>, the data requested by each successive NDC site <b>24</b>, <b>26</b>B or <b>26</b>A may change from that requested from it. However, the nature of the request to access the dataset doesn't change. A request from a client, such as the client workstation <b>42</b>, to the NDC client terminator site <b>24</b> to “read” a dataset remains a “read” operation as it propagates downstream from NDC site to NDC site. Similarly, a request to “write” a dataset remains a “write” as it propagates downstream.

However, if an image of a dataset has been projected in response to a request to read the dataset, and if the client then seeks to modify the dataset in an area that is wholly contained within the NDC buffers <b>129</b> of the NDC site <b>26</b>A, <b>26</b>B or <b>24</b>, then no additional data is required from downstream NDC sites <b>22</b>, <b>26</b>A or <b>26</b>B. However, if this occurs the dataset cannot be written immediately since the possibility exists that another client accessing the dataset at another NDC site might also be requesting to write the dataset. If two clients concurrently write the same dataset, there would then be two projected images of the same named set of data that, most likely, would be different!

Therefore, if a client seeks to perform a write operation on a projected image of a dataset that will overlay only data already loaded into the NDC buffers <b>129</b> of the NDC client terminator site <b>24</b> in response to requests to read the dataset, the NDC site <b>24</b> must send an inform message to downstream NDC sites <b>26</b>B, <b>26</b>A or <b>22</b>. An inform message from an upstream NDC site <b>26</b>A, <b>26</b>B or <b>24</b> requests no data from the downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B. The inform message merely informs the downstream NDC site <b>22</b>, <b>26</b>A or <b>26</b>B that write operations are now being performed on the dataset at the upstream NDC site <b>26</b>A, <b>26</b>B or <b>24</b>.

After an NDC site <b>26</b>B or <b>26</b>A is informed, either implicitly or explicitly, that a write operation is being performed at an upstream NDC site <b>26</b>B or <b>24</b>, and if the activity on this dataset at upstream NDC sites <b>26</b>B or <b>24</b> differs from the type of activity that was already being supported at the NDC site <b>26</b>A or <b>26</b>B, the NDC site <b>26</b>A or <b>26</b>B must transmit the inform message further downstream toward the NDC server terminator site <b>22</b>.

An inform message propagating downstream from NDC site to NDC site may be rejected at any NDC site. If an inform message is rejected by a downstream NDC site, the rejection must propagate upstream until it reaches the client intercept routine <b>102</b> of the NDC site that originated the request. Upon receiving the rejection of an inform message, the client intercept routine <b>102</b> backs-off and allows a recall/disable message, which has either already arrived or will arrive very shortly, to claim the channel <b>116</b> and recall or disable the image of the data currently present in the NDC buffers <b>129</b>.

Upstream Site Structures

An NDC site <b>22</b>, <b>26</b>A or <b>26</b>B receiving information about the activities occurring on a dataset at an upstream NDC site <b>26</b>A, <b>26</b>B or <b>24</b> must record and preserve the information. FIG. 14 depicts an upstream site structure <b>182</b>, that is used by NDC sites <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b> or <b>204</b>A to record and preserve information about activities occurring on a dataset at an upstream NDC site. Each NDC <b>50</b> creates upstream site structures <b>182</b> as required by invoking a memory allocation routine (such as the Unix malloc ( ) routine) to request an area in RAM of about 16 to 20 bytes. The NDC <b>50</b> returns the RAM allocated for each upstream site structure <b>182</b> to the free memory pool upon receiving a decease notification from the upstream NDC site for which the NDC <b>50</b> created the upstream site structure <b>182</b>.

If NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b>, or <b>204</b>A has multiple upstream connections to the same dataset, it will have the same number of instances of the upstream site structures <b>182</b>, one per upstream NDC site. The upstream site structures <b>182</b> are linked together using the *next element in each upstream site structure <b>182</b>. The *uss element in the channel <b>116</b> for the dataset points at the first upstream site structure <b>182</b> in the list of upstream site structures <b>182</b>. The *next entry in the last upstream site structure <b>182</b> in the list is assigned a NULL value. A NULL value is assigned to the *uss element in the channel <b>116</b> at the NDC client terminator site <b>24</b> indicating that there are no sites further upstream.

The other elements of the upstream site structure <b>182</b> are:

upstream_addr which is the address of the upstream NDC site;

current_state which is the state that this NDC site believes the upstream NDC site to be in;

actual_state which is returned by the upstream NDC site in its response to a recall/disable message; and

error which preserves an error condition occurring during a recall/disable operation until such time that the operation can be presented to the upstream NDC sites.

Channel Decease Notifications

The downstream NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b>, or <b>204</b>A must at all times be aware of the types of activities being performed at its upstream NDC sites. When channels <b>116</b> upstream from an NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b>, or <b>204</b>A are about to die, they must inform their downstream NDC site. When a channel <b>116</b> dies, it ceases whatever type of activity it had been performing.

If a downstream NDC site <b>26</b>A or <b>202</b> that is currently the CCS receives a decease notification from a channel <b>116</b> at an upstream NDC site, the current CCS may determine that the CWS condition no longer exists. When this occurs, the CCS relinquishes the CCS function and allows images of data to be re-projected into upstream NDC sites in response to requests to access data.

If a channel <b>116</b> receives a decease notification from its only upstream NDC site <b>26</b>A, <b>26</b>B, <b>24</b>, <b>202</b>, <b>204</b>A, <b>204</b>B, or <b>206</b> and there are no local clients such as the client workstation <b>42</b> accessing the dataset, the channel <b>116</b> immediately dies. In dying, each channel <b>116</b> issues its own decease notification to its downstream NDC site.

Recall/Disable Messages

If an NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b> or <b>204</b>A receives an inform message, which occurs implicitly in every communication from upstream NDC sites, the NDC site <b>22</b>, <b>26</b>A, <b>26</b>B, <b>202</b>, or <b>204</b>A checks to determine if this type of activity is already being supported at the upstream NDC site. If this type of activity is not already being supported at the upstream NDC site, then the new type of activity may have created a CWS condition.

If a NDC site <b>26</b>A or <b>202</b> determines that a CWS condition has just been created, it must immediately disable all upstream projections of the dataset and recall any data that has been modified at the upstream NDC site <b>206</b>, <b>204</b>B, or <b>24</b>. To disable all upstream projections and recall any modified data, the downstream NDC site <b>26</b>A or <b>202</b> processes its list of upstream site structures <b>182</b>, sending a disable message to each upstream NDC site <b>206</b>, <b>204</b>B, and/or <b>24</b> that is reading the dataset, or a recall message to the single upstream NDC site <b>206</b>, <b>204</b>B, or <b>24</b> that is writing the data set.

Ignoring for the time being the NDC site <b>206</b>, <b>204</b>B, or <b>24</b> whose request to access data created the CWS-condition, when an NDC site <b>202</b> or <b>26</b>A determines that it must become the CCS, there can only be one or more client workstations <b>42</b> that are reading the dataset, or a single client workstation <b>42</b> that is writing the data set. In responding to the CWS condition, the newly declared CCS either issues a single recall message to an upstream NDC site, or one or more disable messages. The manner in which a CWS condition occurs determines whether the CCS will send either a single recall message or one or more disable messages.

If one or more client workstations are accessing the dataset for reading it and a client workstation subsequently begins to write the dataset, then the newly declared CCS issues disable messages to all upstream NDC sites other than the one that created the CWS condition, and then appropriately responds to the request just created the CWS condition. If the NDC client terminator site that created the CWS condition has in its NDC buffers <b>129</b> a projected image of all the data needed for writing the dataset, then the newly declared CCS merely informs the NDC client terminator site that the projected image of the data must be flushed back to the CCS upon completion of the write operation. If the NDC client terminator site that created the CWS condition has requested additional data from downstream NDC sites because its NDC buffers <b>129</b> lack a projected image of all the data needed for writing the dataset, then the newly declared CCS does whatever is necessary to supply the NDC client terminator site with the requested data and concurrently instructs the NDC client terminator site that it must flush the projected image of the data back to the CCS upon completion of the write operation.

If a single client workstation is writing the dataset and another client workstation subsequently creates a CWS condition by accessing the dataset for any purpose, then the newly declared CCS issues a single recall message to the NDC client terminator site that has been writing the dataset, waits for the projected image of the dataset to be flushed back from the NDC client terminator site to the CCS, and then does whatever is necessary to respond to the request that created the CWS condition.

If several clients, such as the client workstation <b>42</b>, are widely distributed across a network and concurrently submit requests that will result in a CWS condition, the message from each NDC site races with messages from the other NDC site(s) to whichever NDC site will eventually become the CCS. The first message to reach the NDC site that will become the CCS is processed first and blocks the further processing of later arriving messages until it has been completely processed. All messages arriving after the first message queue up in the order of their arrival at the NDC site that will eventually become the CCS. After the first message is completely processed, these later arriving messages are processed one after another in the order of their arrival. Eventually the NDC <b>50</b> processes the message that creates the CWS condition. When the CWS condition occurs, the NDC <b>50</b> immediately dispatches the recall/disable message(s) to the upstream NDC sites. Any messages from other NDC sites that remain enqueued at the newly declared CCS are processed in order, and each is rejected because the channel <b>116</b> is busy recalling or disabling the NDC sites that issued these messages.

Responding to a CWS condition does not necessarily require two different types of messages, i.e., a disable message and a recall message. A single type of message that commanded upstream NDC sites to disable their caches, and flush dirty data back to the CCS as part of the disable process at the upstream NDC sites would suffice. However, using two distinct message types allows the upstream NDC sites to confirm their agreement on the current state of their channels <b>116</b>.

Upstream and Downstream Messages

Recall and disable messages are referred to as “upstream” messages, because they flow upstream from the NDC site that transmits them. The status query is another type of upstream message. Except for decease notifications, all other requests are initiated by real clients, such as the client workstation <b>42</b>, and always flow downstream. Such messages may be generically referred to as “downstream” messages.

If there are multiple upstream NDC sites, several recall/disable messages are all transmitted asynchronously at about the same time. The process generating these messages then blocks the processing of additional messages for the channel <b>116</b> at this NDC site until all upstream NDC sites have responded or until the time interval allowed for a response expires. If an NDC site fails to respond within the time allowed, a timeout error is recorded in the appropriate upstream site structure <b>182</b>. If later an upstream channel <b>116</b> for which a timeout error has been recorded attempts to re-establish communication with the downstream channel <b>116</b>, it will be notified that it has been disconnected from the dataset. If clients along a path were only reading a dataset, it is likely that they may continue processing the dataset without being notified of the disruption. However, if one of the clients has modified an image that is stored within the NDC buffers <b>129</b> at an NDC site that has been disconnected from the network perhaps due to a communication failure, and the dataset's modification time indicates that the dataset has been modified since service was interrupted, then if an attempt is made to flush the modified data back toward the NDC server terminator site <b>22</b>, the flush request must be rejected. The rejection of the flush request must propagate to all upstream NDC sites, and cause an error message to be presented to the client, such as the client workstation <b>42</b>.

In addition to communication failures, other types of errors are also possible during a recall/disable operation. Any errors that occur along an upstream path during a recall/disable operation are stored in the appropriate upstream site structure <b>182</b>, and are presented to downstream NDC sites later. Errors that occur outside of the direct connection between the client, such as the client workstation <b>42</b>, and the NDC server terminator site <b>22</b> cannot affect the result of operations performed on the dataset by the client at the NDC client terminator site <b>24</b>. Upstream errors are processed the next time NDC sites along the path experiencing the error request access to the dataset.

The RLCCS Mechanism

To guarantee dataset consistency while simultaneously providing very good response times to requests from clients, such as the client workstation <b>42</b>, the present invention implements a concept called ReLocatable Consistency Control Sites (“RLCCS”). Under RLCCS, the first NDC site along the path from the NDC server terminator site <b>22</b> to the NDC client terminator site <b>24</b> that detects a CWS condition becomes the dataset's CCS. If a CWS condition does not exist, there is no CCS since there is no dataset consistency issue that needs to be resolved. However, when a CWS condition arises, there can be only one NDC site responsible for maintaining the consistency between all projected images. This site will always be the first upstream NDC site that has multiple upstream connections.

RLCCS is the means by which the CCS is located in the most extended position possible to enable the maximum amount of non-distributed consistency control. RLCCS ensures that the CCS is positioned to most efficiently resolve dataset contention arising from a CWS condition.

RLCCS implements non-distributed cache consistency control strategy in a file level distributed cache. Instead of passing messages between caching sites, such as the NDC sites <b>26</b>A and <b>202</b>, to maintain a consistent projection of the data cached at the various NDC sites, each NDC site monitors the type of activity occurring at each of its upstream NDC sites and disables caching at those sites when a CWS condition occurs.

If an NDC site determines that the activity at its upstream NDC sites creates a CWS condition, the NDC site becomes the CCS for the file <b>156</b> and issues recall/disable messages to all of its upstream NDC sites. Each upstream site, upon receiving a recall/disable message, recalls or disables all of its upstream NDC sites before responding to the message from the newly established CCS. After the recall activity completes, the CCS and all NDC sites downstream of the CCS are enabled for caching, and all NDC sites upstream of the CCS operate as conduits for file data that is passing through them.

Relocation of the CCS, if it becomes necessary, is performed only when the CCS receives a request that creates a CWS condition. As described below, there are two basic methods of relocating the CCS.

Upstream Relocation of the CCS

Upstream relocation moves the CCS to an NDC site that is closer to the client, such as the client workstation <b>42</b>, than the present CCS. A DTP response to a request to access data includes a “use ticket” that accompanies data which is being passed upstream from NDC site to NDC site. The DTP use ticket may be marked as USE_ONCE or USE_MANY depending upon whether the image of the data may remain cached at an NDC site after it has been used to respond to the request that caused the data to be fetched from downstream. The DTP use ticket for an image of data is always marked as USE_MANY when it begins its journey from the NDC server terminator site to the client site. However, as the image of the data passes upstream from NDC site to NDC site, its use may be restricted to USE_ONCE at any NDC site through which it passes. Thus, when the image of the data passes through the current CCS for the file <b>156</b> the channel <b>116</b> at that NDC site changes the data's DTP use ticket from USE_MANY to USE_ONCE.

As the image of the file <b>156</b> is projected through successive NDC sites, if the DTP use ticket is marked as USE_MANY, the image of the data may remained cached within the NDC buffers <b>129</b> assigned to the channel <b>116</b> through which the image traverses the NDC site. Whether or not any data remains cached within the NDC buffers <b>129</b> assigned to the channel <b>116</b> after passing through the NDC site is determined solely by the local site. Maintaining a projected image of data at an NDC site is a resource allocation issue, and each NDC site must maintain control of its own resources. However, if the DTP use ticket is marked USE_ONCE, none of the data may remain cached within the NDC buffers <b>129</b> assigned to the channel <b>116</b> after traversing the NDC site.

Upstream relocation of the CCS due to a decease notification requires only that the current CCS recognize if it no longer has multiple upstream NDC sites engaged in CWS activities. When that occurs, the NDC site that formerly was the CCS merely stops marking the DTP use ticket USE ONCE. This change in the marking of the DTP use ticket immediately permits upstream NDC sites to begin caching any images of the file <b>156</b> that may be projected into them in the future.

However, if one of the upstream NDC sites currently has additional upstream NDC sites that are creating a CWS condition, that NDC site will declare itself to be the new CCS and begin changing the DTP use ticket from USE_MANY to USE_ONCE. In this way, the NDC <b>50</b> of the present invention facilitates relocating the CCS upstream.

Downstream Relocation of the CCS

Relocating the CCS downstream moves the CCS to an NDC site closer to the NDC server terminator site <b>22</b>. Referring to FIG. 15, if no clients are accessing the file <b>156</b> and then if a client on LAN <b>44</b>B requests access for writing the file <b>156</b> residing on the NDC server terminator site <b>22</b>, a projected image of the file <b>156</b> flows from NDC site <b>22</b>, through NDC sites <b>26</b>A, <b>202</b>, <b>204</b>A, and into NDC site <b>206</b>. The client may now read and write the projection of the file <b>156</b> present in the NDC client terminator site <b>206</b> with an unlimited number of simultaneous processes without the NDC client terminator site <b>206</b> checking with any of the downstream NDC sites <b>204</b>A, <b>202</b> or <b>26</b>A, or with the NDC server terminator site <b>22</b> before each operation. The NDC client terminator site <b>206</b> need communicate with the downstream NDC sites <b>204</b>A, <b>202</b>, <b>26</b>A and <b>22</b> only to load or unload data from the channel <b>116</b> at the NDC client terminator site <b>206</b>.

If a client on LAN <b>44</b>A connected to the NDC site <b>204</b>B begins to access the file <b>156</b> for writing it, the NDC client terminator site <b>204</b>B claims a channel <b>116</b> that then sends an NDC_LOAD message to intermediate NDC site <b>202</b>. The NDC_LOAD message from the channel <b>116</b> will indicate that NDC site <b>204</b>B is loading data that will be overlaid by a write operation. Upon processing this NDC_LOAD message, the NDC site <b>202</b> finds that a channel <b>116</b> already exists for the file <b>156</b>. The existing channel <b>116</b> identifies NDC site <b>204</b>A as a current upstream NDC site, and also indicates that the channel <b>116</b> for the file <b>156</b> is currently enabled. This combination of conditions implies that the CCS for the file <b>156</b>, if one exists, is located either at NDC site <b>204</b>A or at an NDC site upstream from NDC site <b>204</b>A. As described above, the upstream site structures <b>182</b> at the NDC site <b>202</b> not only identify all upstream NDC sites accessing the file <b>156</b>, they also indicate the type of file operations that have occurred at each NDC site accessing the file <b>156</b>. These few facts, i.e. the existence of a CWS condition and that the CCS is not currently located downstream from the NDC site <b>202</b> enable site <b>202</b> to determine that it should declare itself the CCS.

While holding off the write request from the NDC site <b>204</b>B, NDC site <b>202</b> recalls or disables all upstream NDC sites that are caching projected images of the file <b>156</b>. As described above, “disable” is sufficient for any NDC sites at which the file <b>156</b> was only being read. However, if there are any sites that have modified their image of the file <b>156</b>, their dirty data must flushed back to the new CCS, NDC site <b>202</b>. Therefore, NDC site <b>202</b> sends a recall message to NDC site <b>204</b>A.

Before NDC site <b>204</b>A responds to the recall message from NDC site <b>202</b>, NDC site <b>204</b>A transmits its own recall message upstream to NDC client terminator site <b>206</b>. After all of upstream NDC sites have responded to the recall message from NDC site <b>204</b>A, NDC site <b>204</b>A will respond back to NDC site <b>202</b>, forwarding any dirty data that had been soiled by NDC site <b>204</b>A, or by NDC sites upstream from NDC site <b>204</b>A.

After NDC site <b>204</b>A responds to the recall message from NDC site <b>202</b>, NDC site <b>202</b> can begin processing the write request from NDC site <b>204</b>B. NDC site <b>202</b> has now declared itself to be the CCS for file <b>156</b>. NDC site <b>202</b> is now in charge of sequencing all read/write operations that are requested for the file <b>156</b> by its own clients, and by clients of all upstream NDC sites, e.g. NDC sites <b>204</b>A, <b>204</b>B and <b>206</b>.

While the intermediate NDC site <b>202</b> remains the CCS with multiple connections to upstream NDC sites <b>204</b>A and <b>204</b>B at least one of which is writing the file <b>156</b>, no file data or metadata will be cached upstream of the intermediate NDC site <b>202</b>. If, after all NDC sites that were accessing the file <b>156</b> for writing have disconnected from the file <b>156</b>, the intermediate NDC site <b>202</b> as CCS still has one or more upstream NDC sites that are reading the file <b>156</b>, the CCS will relocate upstream as described above.

INDUSTRIAL APPLICABILITY

Within a networked digital computer system, file servers, workstations, gateways, bridges, and routers are all potential candidates to become an NDC site. The NDC <b>50</b> is a software module that can easily be ported to different environments. The NDC <b>50</b> requires a minimum of 250 k bytes of RAM, of which 50 k is code and the remainder is allocated for various data structures and buffers. Each channel <b>116</b> occupies approximately 500 bytes of RAM. Thus, one megabyte of RAM can accommodate about two thousand channels <b>116</b>. At current memory prices, this amount of RAM costs well under $50. As illustrated in FIG. 4, the structure for the subchannel <b>118</b> included in each channel <b>116</b> provides pointers to 18 NDC buffers <b>129</b>. In the preferred embodiment of the invention, each NDC buffer <b>129</b> stores 8 k bytes of projected data. Thus, the eighteen NDC buffers <b>129</b> associated with each channel <b>116</b> can store an image of up to 18*8 k bytes, i.e. 144 k bytes. Thus, with no additional subchannels <b>152</b>, each channel <b>116</b> can accommodate the complete projection, both of data and of NDC metadata, of any dataset of up to 144 k bytes in length.

An NDC site having only 250 k bytes RAM would be useful for only certain limited applications. Each site usually allocates anywhere from 4 to 256 megabytes of RAM for its NDC <b>50</b>. For example, a 128 megabyte NDC site that allocates 32 megabytes of RAM for NDC data structures can maintain over 50,000 simultaneous connections to data conduits <b>62</b> while also storing 96 megabytes of data image projections. Because accessing large datasets may require more than one channel <b>116</b>, the number of simultaneous dataset connections will vary depending on the mix of datasets which are currently being accessed.

With so many channels <b>116</b> packed into a single NDC site, the task of quickly connecting a new request to the channel <b>116</b> for the specified dataset, or claiming the least recently used channel <b>116</b> if there is none, might seem to be a daunting feat. However, the NDC <b>50</b> provides two mechanisms that facilitate solving this problem. The channel hash lists and the channel free list are methods of stringing together the channels <b>116</b> in such a way that any particular channel <b>116</b>, or the least recently used channel <b>116</b>, can be quickly located. Moreover, preferably the number of hash buckets allocated at each NDC site is adjusted so that, on the average, there are 4 channels <b>116</b> in each hash bucket. Limiting the number of channels <b>116</b> in each hash bucket to 4 permits quickly determining whether or not an NDC site presently has a channel <b>116</b> assigned to accessing a particular dataset.

If the NDC client terminator site <b>24</b> receives a request from the client workstation <b>42</b> to access a dataset for which the NDC client terminator site <b>24</b> is also the NDC server terminator site, and if the request seeks to access data that is not currently being projected into the NDC buffers <b>129</b> of the NDC site <b>24</b>, the delay in responding to the first request as measured at the client intercept routine <b>102</b> is approximately 25 milliseconds (about the same as for NFS). However, once the NDC <b>50</b> dispatches a response to the client workstation <b>42</b>, the site will employ intelligent, efficient, and aggressive read ahead to ensure that as long as the client workstation <b>42</b> continues to access the file sequentially, data will almost always be projected into the NDC buffers <b>129</b> of the NDC client terminator site <b>24</b> before the client workstation <b>42</b> requests to access it. By pre-fetching data in this manner, responses to most subsequent requests from the client workstation <b>42</b> can be dispatched from the NDC client terminator site <b>24</b> to the client workstation <b>42</b> within 100 microseconds from the time the NDC site <b>24</b> receives the request.

If the client workstation <b>42</b> requests to access a dataset that is at an NDC site other than the NDC client terminator site <b>24</b>, such as NDC sites <b>26</b>B, <b>26</b>A or <b>22</b>, responding to the first request from the client workstation <b>42</b> requires an additional 25 millisecond delay for each NDC site that must respond to the request. However, because the NDC client terminator site <b>24</b> attempts to pre-fetch data for the client workstation <b>42</b>, the NDC site <b>24</b> will dispatch responses to subsequent requests from the client workstation <b>42</b> in about 100 microseconds as described above.

While the presently preferred embodiment of the NDC <b>50</b> is implemented in software, it may also be implemented in firmware by storing the routines of the NDC <b>50</b> in a Read Only Memory (“ROM”). Furthermore, the operation of the NDC <b>50</b> is independent of any particular communication hardware and protocol used to implement the LAN <b>44</b>, and of the filesystem that is used for accessing the hard disks <b>32</b>, <b>34</b> and <b>36</b>. Analogously, the operation of the NDC <b>50</b> is independent of the communication hardware and communication protocol by which DTP messages <b>52</b> pass between pairs of NDC sites <b>22</b>-<b>26</b>A, <b>26</b>A-<b>26</b>B, or <b>26</b>B-<b>24</b>. The communication hardware and protocols for exchanging DTP messages <b>52</b> include backplane buses such as the VME bus, local area networks such as Ethernet, and all forms of telecommunication. Accordingly, DTP messages <b>52</b> exchanged between NDC sites may pass through gateways, including satellite data links, routers and bridges.

While the NDC <b>50</b> has been described thus far in the context of a distributed multi-processor computer system <b>20</b> in which various NDC sites, such as the sites <b>22</b>, <b>26</b>A, <b>26</b>B and <b>24</b>, are envisioned as being separated some distance from each other, the NDC <b>50</b> may also be applied effectively within a single computer system that incorporates a network of computers. FIG. 16 depicts a file server referred to by the general reference character <b>300</b>. Those elements depicted in FIG. 16 that are common to the digital computer system <b>20</b> depicted in FIG. 1 carry the same reference numeral distinguished by a double prime (“″”) designation. The file server <b>300</b> includes a host processor <b>302</b> for supervising its overall operation. Within the file server <b>300</b>, an internal bus <b>304</b>, perhaps a VME bus, couples the main host processor <b>302</b> to a pair of storage processors <b>306</b>A and <b>306</b>B. The storage processors <b>306</b>A-B control the operation of a plurality of hard disks <b>32</b>A″ through <b>32</b>F″. The internal bus <b>304</b> also couples a pair of file processors <b>312</b>A and <b>312</b>B, a pair of shared primary memories <b>314</b>A and <b>314</b>B, and a plurality of Ethernet processors <b>316</b>A through <b>316</b>D to the host processor <b>302</b>, to the storage processors <b>306</b>A-B, and to each other.

During the normal operation of the file server <b>300</b> without the incorporation of any NDCs <b>50</b>, the Ethernet processors <b>316</b>A-D receive requests to access data stored on the disks <b>32</b>A″ through <b>32</b>F″ from clients such as the client workstation <b>42</b> that is illustrated in FIG. <b>1</b>. The requests received by the Ethernet processors <b>316</b>A-D are transferred to one of the file processors <b>312</b>A-B. Upon receiving a request to access data, the file processor <b>312</b>A or <b>312</b>B communicates with one of the storage processors <b>306</b>A or <b>306</b>B via the internal bus <b>304</b> to effect the transfer an image of the data from the disks <b>32</b>A″ through <b>32</b>F″ into the primary memories <b>314</b>A-B. After an image of the requested data has been transferred into the primary memories <b>314</b>A-B, the Ethernet processor <b>316</b> that received the request then transmits the requested data to the client thereby responding to the request.

The file processors <b>312</b>A-B may incorporate a hard disk cache located in the primary memories <b>314</b>A-B. The presence of a hard disk cache in the file server <b>300</b> allows it to respond to some requests to access data without any communication between one of the file processors <b>312</b>A-B and one of the storage processors <b>306</b>A-B. However, even though the file server <b>300</b> includes a hard disk cache, during operation of the file server <b>300</b> responding to each request to access data received by the Ethernet processors <b>316</b>A-D necessarily involves communications between the Ethernet processors <b>316</b>A-D and the file processors <b>312</b>A-B. That is, even though data needed by the Ethernet processors <b>316</b>A-D for responding to requests is already physically present in the primary memories <b>314</b>A-B, to gain access to the data the Ethernet processors <b>316</b>A-D must first communicate with the file processors <b>312</b>A-B because the data is stored in a hard disk cache under the control of the file processors <b>312</b>A-B.

To enhance the overall performance of the file server <b>300</b>, each of the Ethernet processors <b>316</b>A-D may incorporate an NDC <b>50</b> operating as NDC client terminator site. Each NDCs <b>50</b> included in the Ethernet processors <b>316</b>A-D accesses a set of NDC buffers <b>129</b> allocated within the primary memories <b>314</b>A-B. In addition to the NDCs <b>50</b> included in the Ethernet processors <b>316</b>A-D, the file server <b>300</b> may also include other NDCs <b>50</b> operating as NDC server terminator sites in the file processors <b>312</b>A-B. The NDCs <b>50</b> in the file processors <b>312</b>A-B also access a set of NDC buffers <b>129</b> allocated within the primary memories <b>314</b>A-B.

In a file server <b>300</b> so incorporating NDCs <b>50</b>, if one of the Ethernet processors <b>316</b>A-D receives a request to access data that is already present in the NDC buffers <b>129</b> of its NDC <b>50</b>, its NDC <b>50</b> may respond immediately to the request without communicating with an NDC <b>50</b> located in one of the file processors <b>312</b>A-B. Analogously, if one of the Ethernet processors <b>316</b>A-D receives a request to access data that is not present in its NDC buffers <b>129</b> but that is present in the NDC buffers <b>129</b> of the NDCs <b>50</b> in the file processors <b>312</b>A-B, those NDCs <b>50</b> may also respond immediately to the request without accessing the hard disk cache controlled by the file processors <b>312</b>A-B. Under such circumstances, the NDC <b>50</b> operating in the file processors <b>312</b>A-B may immediately respond to a request from the NDC <b>50</b> operating in the Ethernet processors <b>316</b>A-D merely by providing it with a pointer to the location of the data within the primary memories <b>314</b>A-B. Thus, by employing NDCs <b>50</b> both in the Ethernet processors <b>316</b>A-D and in the file processors <b>312</b>A-B, data that is physically present in NDC buffers <b>129</b> located in the primary memories <b>314</b>A-B becomes available more quickly to the Ethernet processors <b>316</b>A-D for responding to requests from clients such as the client workstation <b>42</b> by eliminating any need to access the hard disk cache controlled by the file processors <b>312</b>A-B.

Although the present invention has been described in terms of the presently preferred embodiment, it is to be understood that such disclosure is purely illustrative and is not to be interpreted as limiting. Consequently, without departing from the spirit and scope of the invention, various alterations, modifications, and/or alternative applications of the invention will, no doubt, be suggested to those skilled in the art after having read the preceding disclosure. Accordingly, it is intended that the following claims be interpreted as encompassing all alterations, modifications, or alternative applications as fall within the true spirit and scope of the invention.