`111~111~~I\I~~II'~\\l1\I~11
`07/03L9J.-'
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Date:
`
`Thomas Yohe et al.
`08/
`
`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A
`NETWORK FILE ORIENTED CACHING SYSTEM
`S-OOO14-003
`
`Applicant:
`Serial No.:
`Filed:
`For:
`
`Docket No.:
`
`Box Patent Application
`Commissioner of Patents and Trademarks
`Washington, D.C. 20231
`
`Sir:
`
`.2L
`.2L
`.2L
`
`.lL
`
`X
`
`K-
`.2L
`
`Enclosed are the following papers:
`
`Specification, abstract and c1aims,_ pages total.
`Drawings:_ sheet(s),.x.
`formal, _ informal
`Declaration and Power of Attorney X executed
`unexecuted
`A claim for priority under 35 U.S.c. 119 is hereby made
`Application No. _
`with respect to
`filed
`. A certified copy of that
`application_
`is enclosedl_ will be filed
`later.
`A claim for priority under 35 U.S.C. 120is hereby made
`with respect to u.s. Application No. 08J565 393
`filed IlJ30/95.
`Statement by inventor as to small entity status
`Enclosed herewith is a check in the amount of$ 770.
`which is calculated as follows.
`Preliminary amendment
`Information Disclosure Statement
`The inventorship for all the claims in this application are:
`
`X The same
`
`or
`
`_ Are not the same. An explanation, including the
`ownership of the various claims at the time the last
`claimed invention was made
`is submitted.
`
`
`
`MICROSOFT
`
`EXHIBIT 1006
`
`Page 1 of 49
`
`
`
`_ will be submitted .
`
`.K-
`
`An assignment
`.x, is attached
`enclosed
`_ will
`follow;
`amount of -±Q..OO
`
`of the invention
`
`to
`
`herewith
`
`is a check in the
`
`A terminal
`
`disclaimer
`
`is filed herewith
`
`and fee $55.00
`
`CLAIMS AS FILED
`
`Number
`
`filed
`
`Number Extra
`
`Rate
`I
`
`Total
`Claims
`
`(37 CPR 1.l6(cl)
`
`-20= -- X $ 22.00
`
`Independent
`(37 CFR LJ6(bl)
`Claims
`
`- 3=
`
`X $ 80.00 -
`
`dependent
`Multiple
`(37 CFR U6(dl)
`
`c1aim(s),
`
`if any
`
`$26000-
`
`Filing Fee Calculation
`
`Large Entity
`Small Entity
`
`'/70, CN
`) x.5
`
`(
`
`BasicFee
`
`37CFRI.l6(a)
`
`$770.00
`
`000
`
`000
`
`Respectfully
`
`submitted,
`
`BY~----'
`R William Graham
`Reg. No. 33,891
`
`2
`
`Page 2 of 49
`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OF.F.ICE
`
`Thomas Patrick Yohe et al.
`08/
`
`APPARATUS AND METHOD FOR INCREASED DATAACCESS
`NETWORK FILE ORIENTED CACHING SYSTEM
`8-00014-003
`
`IN A
`
`Applicant:
`Serial No.:
`Filed:
`For:
`
`Docket No.:
`
`COMMISSIONER OF PATENTS AND TRADEMARKS
`Washington, D.C. 20231
`
`eM II tJ 'f ~/ L(.J r
`"Express Mail" label number
`7 I "3 /9 7
`Date of Deposit
`
`EXPRESS MAIL CERTIFICATE
`
`JL
`JL
`
`JL
`
`Ihereby certify that the following attached:
`transmittal letter
`X-
`new application
`JL
`continuation
`divisional
`continuation-in-part
`declaration and power of attorney
`amendment
`preliminary amendment
`information disclosure statement
`response
`notice of appeal
`assignment
`petition for extension
`notification of continuation
`affidavit
`verified statement of small entity
`filing fees
`terminal disclaimer and fee
`is being deposited with the United States Postal Service "Ex
`ve
`service under 37 CFR 1.10 on the date indicated a
`Patents and Trademarks, Washington, D.C. 2023
`
`JL
`
`JL
`
`s
`
`R. William Graham
`Reg. No. 33 891
`
`Page 3 of 49
`
`
`
`Abstract of the Disclosure
`
`An apparatus
`
`for increased data access in a network includes a file server computer having
`
`a permanent
`
`storage memory, a cache verifying computer operably connected to the file server
`
`computer
`
`in a manner to form a network for rapidly transferring data,
`
`the cache verifying
`
`5
`
`computer having an operating system, a first memory and a processor with means for performing
`
`an operation on data stored in the permanent
`
`storage memory ofthe
`
`file server computer
`
`to
`
`produce a signature of the data characteristic
`
`of one of a file and directory, a remote client
`
`computer having an operating system, a first memory, a cache memory and a processor with
`
`means for performing an operation on data stored in the cache memory to produce a signature of
`
`:;::.;'10
`
`the data, a communication
`
`server operably connected to the remote client computer
`
`to the cache
`
`verifying computer and the file server computer and comparators
`
`operably associated with the
`
`,~
`
`cache verifying computer and remote client computer
`
`for comparing the signatures of data with
`
`one another
`
`to determine whether
`
`the signature of data of the remote client is valid.
`
`32
`
`Page 4 of 49
`
`
`
`APPARATUS AND METHOD FOR INCREASED DATA ACCESS IN A NETWORK FILE
`
`ORIENTED CACHING SYSTEM
`
`of U.S. Serial No. 08/565,393
`
`filed 11130/95':
`
`/'--t:~{
`.<.
`
`This is a continuation-in-part
`i
`
`Background
`
`of the Invention
`
`5
`
`Field of the Invention
`
`i:•.•••,
`
`f:~0
`~Ji~~I'd
`
`If-..?1""
`
`The present
`
`invention relates to data access in a file oriented network system, More
`
`particularly,
`
`the present
`
`invention is directed to a client-agent-server
`
`utility which increases the
`
`speed in which data in the form of files and directories
`
`are accessed across slow link
`
`communications
`
`via remote node caching and verifying.
`
`Related Art
`
`Many operating systems are equipped to handle caching and verifying of data.
`
`Traditionally,
`
`in a remote client's caching system, optimization in retrieving data is limited to
`
`prefetching,
`
`In other words, an application program in a remote client requests
`
`from a file server
`
`transmission of a predetermined
`
`number of bytes of information (e.g. x bytes) and the operating
`
`system on the client prefetches
`
`the requested data plus another number of bytes of information
`
`(e.g. x + y bytes). Thus, when the application requests the bytes,
`
`it already exists in its readily
`
`accessible memory (cache),
`
`In addition,
`
`there also exist problems with verification of directories
`
`in existing systems,
`
`It
`
`has been found, for example,
`
`that two remote clients concurrently
`
`accessing data and attempting
`
`20
`
`to verify a directory will not necessarily obtain the same data due to the fact that
`
`the data from the
`
`file server computer will not necessarily send out the data in the s,ame order to each of the remote
`
`clients, Thus,
`
`there is no clear indication whether
`
`the directory data is current
`
`Page 5 of 49
`
`
`
`In a desktop caching system, a high speed memory is used to cache data that is stored on a
`
`hard disk. While a desk-top cache program,
`
`such as Microsoft's SmartDrive is a useful
`
`tool
`
`to
`
`increase performance
`
`from the random access memory (RAM),
`
`this type of caching technique is
`
`not applicable to remote environments because of its inability to correctly handle multiple remote
`
`5
`
`clients accessing the same data files concurrently,
`
`i.e., it is likely to corrupt
`
`the data.
`
`File servers have employed caching techniques which parallel
`
`techniques of the desktop.
`
`Here,
`
`the file server deviates in protecting against multiple common data user access by
`
`implementing or providing a file locking service to clients.
`
`As shown in FIG.
`
`I, the related art includes a remote client computer having an operating
`
`system (OS) with a file system interface (FSI). Operatively connected to the FSI is a local file
`
`system (LFS) which in turn is operatively connected to a RAM based disk cacher (RBDC), disk
`
`lAc;
`
`driver (DD) and permanent
`
`storage disk (PSD). Also, operatively connected to the FSI is a
`
`network file redirector
`
`(NFR) with prefetch capability, and a network transport
`
`layer (NTL)
`
`connected to a WAN driver. Aside from the OS, there exist application programs
`
`(AP) which
`
`employs the OS via the FSI. A communication
`
`server (CS) connects
`
`to the remote client
`
`".j
`
`computer and includes a WAN driver, routing layer and LAN driver.
`
`The CS connects
`
`through a LAN link to a file server computer having an OS. The file
`
`server computer OS includes an NTL connected to a LAN driver and an FSI connected to LFS
`
`which in tum is connected to an RBDC, a DD and a PSD. Aside from the OS, there exists a file
`
`20
`
`server application which employs the OS via the FSI.
`
`The problem associated with these prior systems is their inability to provide a remote
`
`client user with greater
`
`speed of access to file server data and/or
`
`file server directories. This is
`
`2
`
`Page 6 of 49
`
`
`
`especially so because of the type of link:in which the remote client may be accessing the data
`
`through,
`
`such as a modem phone link.
`
`In the context ofthe present
`
`invention,
`
`"remote client" is
`
`defined as a user, accessing data over a relatively slow link, such as a modem phone link:. A
`
`typical modem phone link provides a transfer
`
`rate of about 28.8 kilobits ofinforrnation
`
`per
`
`5
`
`second. This is contrasted with a link: in a LAN connection which can transfer at about 10
`
`Megabits per second. These remote clients are thus greatly limited in speed of access.
`
`Summary of the Invention
`
`:3.0
`
`~~:::,..~
`;~
`
`20
`
`The present
`
`invention overcomes
`
`the above described deficiencies which exist with remote
`
`clients accessing and verifying data in files and directories
`
`from a file oriented network
`
`environment.
`
`It is an object
`
`to increase the speed in which a remote client can access data and
`
`directories.
`
`It is another object
`
`to maintain integrity of the accessed data and directory while
`
`increasing the speed in which the data is accessed.
`
`A further object
`
`is to implement an agent
`
`to act as a caching verifier between a remote
`
`client and a file server computer.
`
`Still, another object
`
`is to add intelligence to a remote client in order to reduce the overall
`
`time in which a remote client accesses data.
`
`Another object
`
`is to overcome the deficiencies of data transfer
`
`for a remote client.
`
`Other objects and advantages will be readily apparent
`
`from reading the following
`
`description and viewing the drawings.
`
`Accordingly,
`
`the present
`
`invention is directed to an apparatus
`
`for increased data access in
`
`3
`
`Page 7 of 49
`
`
`
`a network, which includes a file server computer having a permanent
`
`storage memory, a cache
`
`verifying computer operably connected to the file server computer
`
`in a manner
`
`to form a network
`
`for rapidly transferring
`
`data,
`
`the cache verifying computer having an operating system, a first
`
`memory and a processor with means for performing an operation on data stored in the permanent
`
`5
`
`storage memory of the file server computer
`
`to produce
`
`a signature of the data characteristic
`
`of
`
`one of a file and directory,
`
`a remote client computer having an operating system, a first memory, a
`
`cache memory and a processor with means for performing an operation on data stored in the
`
`cache memory to produce
`
`a signature of the data, a communication
`
`server operably connected to
`
`the remote client computer
`
`to the cache verifying computer
`
`and the file server computer
`
`and
`
`comparators
`
`operably associated with the cache verifying computer
`
`and remote client computer
`
`for comparing the signatures of data with one another
`
`to determine whether
`
`the signature of data
`
`iie
`
`'
`
`of the remote client
`
`is valid. The remote client computer
`
`includes means responsive to each
`
`comparison
`
`performed by the comparator
`
`on the data for generating and storing a validation ratio
`
`for the data in the first memory and for removing the data from the cache memory when the
`
`validation ratio drops below a predetermined
`
`value. Also,
`
`the cache verifying computer
`
`includes
`
`\~
`
`means for recognizing a LOCK request
`
`from the remote client computer
`
`and for obtaining a lock
`
`on the data from the file server computer
`
`in response to the LOCK request.
`
`Terminology
`
`"Permanent
`
`storage memory," as used herein,
`
`includes, but
`
`is not limited to, disk drive,
`
`20
`
`flash RAM or bubble memory,
`
`for example.
`
`"File oriented distributed network,"
`
`as used in the present
`
`invention, will include a
`
`network wherein the file server computer data is accessed via the following set of file system
`
`4
`
`Page 8 of 49
`
`
`
`primitives: OPEN, CREATE, READ, WRITE, SEEK, LOCK, UNLOCK, CLOSE and
`
`DIRECTORY REQUEST.
`
`"Caching" is the function of retrieving an object from a relatively high speed storage
`
`device from a list of most- recently-used
`
`objects.
`
`5
`
`"Cache" is a file which resides in permanent
`
`storage and contains the most-recently-used
`
`blocks of data read from a remote file server.
`
`"Object"
`
`is a sequence of data of variable length.
`
`"Sub-object"
`
`is a portion of an Object.
`
`"File server computer"
`
`is a computer which includes a processor with its associated
`
`memory, an operating system, and a permanent
`
`storage memory.
`
`"Reverse channel" is the means by which a response message is sent over the same
`
`network layer interface in which a request was received
`
`Brief Description of the Drawings
`
`FIG. I illustrates the block diagram configuration
`
`of the related art.
`
`FIG. 2 illustrates the block diagram configuration
`
`of the present
`
`invention.
`
`FIG. 3 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to the
`
`requests within a remote client.
`
`FIG. 4 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`OPEN/CREATE
`
`requests on remote client computer.
`
`20
`
`FIG. 5 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`OPEN/CREATE
`
`requests on cache verifying computer.
`
`FIG. 6 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to READ
`
`5
`
`Page 9 of 49
`
`
`
`requests on remote client computer.
`
`FIG. 7 illustrates a flow chart of the operations ofthe present
`
`invention corresponding
`
`to READ
`
`requests on cache verifying computer.
`
`FIG. 8 illustrates a flow chart of additional operations of the present
`
`invention corresponding
`
`to
`
`5
`
`READ requests
`
`in the cache verifying computer.
`
`FIG. 9 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to WRITE
`
`requests on remote client computer.
`
`FIG.
`
`IO illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`WRITE requests on cache verifying computer.
`
`':;10
`
`FIG. 11 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to LOCK
`
`requests on remote client computer.
`
`i#.,
`
`FIG. 12 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to LOCK
`
`requests on cache verifying computer.
`
`FIG.
`
`I3 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`CLOSE requests on remote client computer.
`
`"'.j
`
`FIG. 14 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`CLOSE requests on cache verifying computer.
`
`FIG. 15 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to
`
`DIRECTORY REQUEST on cache verifying computer.
`
`20
`
`FIG. 16 illustrates a flow chart of the operations of the present
`
`invention corresponding
`
`to a part
`
`of the operations
`
`in FIG. 15.
`
`Detailed Description of a Preferred Embodiment
`
`6
`
`Page 10 of 49
`
`
`
`In the description which follows, the representation of the present invention is in part
`
`presented in terms of program operations executed on a file oriented distributed network of
`
`computers, but may as well be applicable to distributed file oriented network systems. The
`
`operations are steps leading to a certain result Typically, these steps take the form of electrical
`
`5
`
`signals which are manipulated, stored, transmitted, combined, compared or otherwise operated
`
`upon by a particular computer in the network. For simplicity, these signals may be referred to
`
`herein as bits, bytes or data.
`
`The following description describes solutions to the problems associated with a remote
`
`client computer's ability to access specified data from a file or directory of a file server computer
`
`located on a network or world wide web. An apparatus and method are disclosed which pennit
`
`the remote client computer to reduce the time for accessing such data using a cache verifying
`
`computer coupled with a caching technique.
`
`The performance gains realized by the present invention are derived from the fact that
`
`remote clients tend to repetitively access the same data by performing file reads.
`
`If a copy of the
`
`data can be stored in the permanent storage memory of the remote client computer and also
`
`>;1
`
`verified to be current when it is subsequently retrieved, this will improve performance
`
`significantly. This is because it requires much less bandwidth to verify a block of data than it
`
`would to actually transfer a block of data.
`
`Referring now to the figures 2-15, the present invention is a network computer system 10
`
`20
`
`having at least one remote client computer 12, cache verifying computer 14, communication
`
`server 16 and file server computer 18. The cache verifying computer 14 and file server computer
`
`18 are connected via a local area network (LAN) link 20. The communication server 16 links the
`
`7
`
`Page 11 of 49
`
`
`
`remote client computer 12 to the LAN 20, which in tum permits communication with the cache
`
`verifying computer 14 and the file server computer 18.
`
`The remote client computer 12 communicates via communication link 22 to the
`
`communication server 16. The communication server 16 can be of a type such as that provided
`
`5
`
`by Cisco, 3Com, Shiva, etc., which will act as a router of traffic between the LAN 20 and
`
`communication link 22 and convert data through the LAN 20. The LAN 20 can be Ethernet or
`
`Token Ring, for example.
`
`The remote client computer 12 has an operating system (OS) 24 with a file system
`
`interface (FSI) 26. Operatively connected to the FSI 26 is a local file system (LFS) 28 which in
`
`tum is operatively connected to a RAM based disk cacher (RBDC) 30, disk driver (DD) 32 and
`
`permanent storage disk (PSD) 34. A network file redirector (NFR) 36 with prefetch data 37,
`
`operatively connects to a network transport layer (NTL) 38 which in tum is connected to a WAN
`
`driver 40. Additionally, the invention includes a network file cacher (NFC) 42 which is operably
`
`disposed between and interconnects the FSI 26 and NFR 36. The NFC 42 has operatively
`
`associated therewith a directory cacher (DC) 43 and directory signature comparator (DSC) 46.
`
`The NTL 38 operatively connects to the NFC 42. Also, the NFC 42 operatively connects
`
`to the LFS 28. The NFC 42 includes a block signature generator (BSG) 44 and hit ratio analyzer
`(HRA) 45, which will be more fully described hereinafter. Aside from the as, there exists on the
`computer 12 application programs CAP) 46 which employ the as 24 via FSI 26.
`
`20
`
`The communication server (CS) 16 includes a WAN driver 48, a LAN driver 50 and
`
`routing layer (RL) 52 operatively interconnecting the WAN driver 48 and the LAN 50 driver.
`
`The cache verifying computer 14 includes a cache verifying agent (CVA) 54 having a BSG
`
`8
`
`Page 12 of 49
`
`
`
`56 (of the type described herein), a directory signature generator
`
`(DSG) 57 and a comparator
`
`58.
`
`Also, included is an OS 60 having an FSI 62 operatively connected to CVA 54, an NFR 64
`
`operatively connected to the FSI 62, an NTL 66 operatively connected to the NFR 64 and CV A
`
`54, and a LAN driver 68 operatively connected to the NTL 66.
`
`5
`
`The file server computer
`
`18 includes an OS 70 having an FSI 72 which is operatively
`
`connected to an LFS 74 which in tum is connected to an RBDC 76, aDD 78 and a PSD 80.
`
`Also,
`
`the OS 70 includes an NTL 82 operatively connected to a LAN driver 84. A file server
`
`application (FSA) 86 exists on the computer 18 which is operably connected to both the NTL 82
`
`and FSI72.
`
`It should be noted that one skilled in the art can modify the basic network computer
`
`to
`
`accomplish the objects set forth herein and that such modifications
`
`are believed to fall within the
`
`(yj
`
`scope of the claims appended hereto. Alternatively,
`
`for example,
`
`the cache verifying agent 54
`
`could reside as part ofthe communication
`
`server 16 or as a stand alone processor with its own
`
`memory and operating system. Still, other persons
`
`skilled in the art will appreciate the verifying
`
`5
`
`agent can be implemented in other manners to accomplish the goals set forth herein.
`
`The operation of the system is as follows and as represented in FIGS. 3-15. The
`
`operations discussed hereafter assumes connections have been made among all computers
`
`12, 14
`
`and 18 and communication
`
`server 16.
`
`On the remote client computer, AP 46 makes requests
`
`from a file server wherein the NFC
`
`20
`
`42 will intercept a file system call 100 from the AP 46 and query whether
`
`the object
`
`to be acted
`
`upon is "remotely located?" 102.
`
`lfthe answer
`
`is no, the NFC 42 "instructs" 104 the LFS 2810
`
`handle the object request.
`
`If yes, the type of request
`
`is ascertained and handled accordingly as
`
`9
`
`Page 13 of 49
`
`
`
`follows.
`
`In the case of OPEN or CREATE 106 requests, the NFC 42 follows the operation under
`
`200. The NFC 42 "invokes" 202 the NFR 36 to process the request. The NFR 36 asks "whether
`
`there is a good status" 204 for the request.
`
`Ifno, NFR 36 "returns" 205 the results of the
`
`5
`
`operation to AP 46. If yes, the NFR 36 assigns a handle thereto and the NFC 42 "builds and
`
`sends" 206 an OPEN/CREA TE request to CVA 54 via NTL 38 which triggers operation 250.
`
`CVA 54 "opens" 252 a file specified in OPEN/CREATE request via FSI 62, NFR 62 and
`
`NTL 66. The CVA 54 asks "whether there is a good status on the file?" 254.
`
`If the answer is no,
`
`CVA 54 "sends" 256 the bad response back to NFC 42 in a reverse channel. If the answer is yes,
`
`CVA S4 "assigns a handle to the object" 258 and "sends" 260 a good response via a reverse
`
`channel.
`
`NFC 42 via NTL 38 "receives the response" 208 from CVA 54 and "asks for a good
`
`status?" 210.
`
`If the answer is no, the NFC 42 "returns the results ofthe original OPEN/CREATE
`
`request" 216 to AP 46. If the answer is yes, then the NFC 42 "associates 212 the handle assigned
`
`by the CVA 54 with the handle returned by the NFR 36 in operation 202. The NFC 42 "updates"
`
`214 the network file cache via LFS 28 and "returns the results obtained by NFR 36" 216 to AP 46
`
`viaFSI26.
`
`In the case of a READ 108 requests, the computer 12 follows the operation 300. Via the
`
`FSI 26 and LFS 28, the NFC 42 "determines if the requested data is in cache?" 302.
`
`If the
`
`20
`
`answer is no, a subquery becomes "is the data locked?" 304. To this subquery, if the answer is
`
`no, the NFC 42 "retrieves" 306 the data via NTL 38 from the file server computer 18 and the
`
`NFC 42 "updates" 308 the network file cache via LFS 28. Ifthe answer to the subquery is yes,
`
`IO
`
`Page 14 of 49
`
`
`
`theNFC 42 via theNTL 38 "sends" 310 a READ request to CVA 54 which triggers 380. CVA
`
`54 via the FSI 62 "reads" 382 the data from the file server computer 18. The CVA 54 "sends"
`
`384 a response back to NEC 42, wherein the data is "received" 312 and "updated" 308 as
`
`described above. The retrieved data is "returned" 314 by the NFC 42 to AP 46.
`
`5
`
`If the data is in cache, NFC 42 is triggered to "invoke" 316 the BSG 44 to generate a
`
`signature of data. NFC 42 via NFR 36 and NTL 38 "sends" 320 a VERIFY request having the
`
`first signature of data therein to CVA 54 which triggers 350.
`
`CVA 54 viaFSI 62 "reads" 352 data from the file server computer 18. CVA 54 "invokes"
`
`354 BSG 56 to generate a second signature of data. eVA S4 "invokes" 356 comparator 58 to
`
`;40
`i:G
`~~
`
`compare the first and second signatures of data and "asks whether there is a match?" 358.
`
`If the
`
`answer is no, eVA 54 "asksif data is locked?" 360. Ifno, the eVA 54 "sends" 362 back a bad
`
`response to NFe 42 via a reverse channel. If yes, CVA 54 "sends" 364 back a bad response to
`
`NFC 42 along with read data via a reverse channel. If there is a match of the signatures, eVA 54
`
`"sends" 366 a good response back to NFC 42 via NTL 66.
`
`The NFC 42 receives 322 the response from eVA 54 and asks "is the data valid?" 324. If
`
`no, NFC 42 asks "is the data locked?" 326. Ifnot
`
`locked, the NFC 42 retrieves data 306 as
`
`described above. If locked, data will have been "returned" 328 for updating per 308. If the data
`
`was valid, NFC 42 returns the data to AP 46.
`
`In the case of a WRITE 110 request, the computer 12 follows the operation 400. The
`
`20
`
`NFC 42 "asks is the data locked?" 402. If no, the NFR 36 is invoked to "write" 404 to the file
`
`server computer 18. Ifthe data is locked, NFC 42 via NTL 38 "sends" 406 a WRITE request to
`
`CVA 54 which triggers 450. CVA 54 "writes" 4S2 data to file server computer 18 via FSI 62.
`
`11
`
`Page 15 of 49
`
`
`
`CVA 54 "sends" 454 back a response to NFC 42 which "receives" 408 the response. The NFC
`
`42 "asks is the data in cache?" 410.
`
`Ifno, LFS 28 "reports status" 412 to AP 46.
`
`If yes, NFC 42
`
`"updates" 414 network cache via LFS 28 and "reports status" 412 to AP 46.
`
`In the case ofLOCKlUNLOCK 112 request, operation 500 is employed. The NFC 42
`
`5
`
`''builds'' 502 an LOCKIUNLOCK request. The NFC 42 via NTL 38 "sends" 504 the
`
`LOCKIUNLOCK request to CVA 54 which triggers operation 550. CVA 54 "sends" 552 an
`
`LOCKIUNLOCK request to the file server computer 18 via FSI 62. CVA 54 "sends" 554 a
`
`response back to NFC 42 via a reverse channel. The NFC 42 "receives" 506 the response and
`
`!,\,,'
`
`!''';
`
`",j
`
`"returns" 508 the results to AP 46.
`
`In the case of a CLOSE 114 request, operation 600 is employed. The NFC 42 "builds"
`
`602 a CLOSE request. The NFC 42 via NTL 38 "sends" 604 the CLOSE request to CVA S4
`
`which triggers operation 650. CVA 54 "performs" 652 internal processing of the request. CVA
`
`S4 "sends" 654 a response back to NFC 42. The NFC 42 "receives" 606 the response and
`
`invokes the NFR 36 to "close" 608 the file and "return" 610 the results to AP 46.
`
`In the case ofa DIRECTORY REQUEST 115, operation 700 is employed. Here, the
`
`NFC 42 "processes" 701 a first directory sub-object request.
`
`Ifthe sub-object is not a first, NFC 42 "retrieves" 703 the next directory sub-object from
`
`cache via LFS 28. NFC 42 "asks" 704 whether this is the last sub-object from cache via LFS 28?
`
`Ifno, NFC "returns" 705 a sub-object to AP 46.
`
`If yes and it is the last sub-object, NFC 42
`
`20
`
`"returns" 706 a "no more objects" status to AP 46.
`
`If the sub-object is the first directory sub-object, the NFC42 "determines" if the requested
`
`object is in cache 702.
`
`If no, the NFC 42 "sends" 710 a directory verify request to CVA 54 via
`
`12
`
`Page 16 of 49
`
`
`
`NTL 38, This triggers the steps 750 and NFC 42 waits to "receive" 711 signature from CVA 54.
`
`As seen in FIG. 16, the steps 750 are performed by the CVA 54. Particularly, the DSG 57
`
`"initializes" 751 signature of a directory. The DSG 57 "retrieves" 752 the first directory sub-
`
`object from the FS 18 via NTL 66. The DSG 57 "asks" 753 is this the last sub-object? Ifno,
`
`5
`
`DSG 57 "factors" 754 the signature of this sub-object into the overall signature of the directory.
`
`The DSG 57 then "retrieves" 755 the next sub-object from FS 18 and returns to step 753. If the
`
`last sub-object, CVA 54 "sends" 756 back signature of directory to NFC 42 at block 724 and
`
`proceeds therefrom,
`
`If yes and in cache, the NFC 42 "retrieves" 719 signature associated with this directory
`
`i~l0
`t't~,
`;r;
`
`request from cache via LFS 28. NFC 42 "sends" 720 directory verify request to CVA 54 via
`
`NTL 38, This triggers the steps 750 wherein NFC 42 waits and "receives" 721 signature from
`
`CVA 54. NFC 42 "invokes" 722 DSC 46 to compare whether signature matches the retrieved
`
`signature in 719? If yes and the signatures match, NFC 42 "returns" 723 the first sub-object from
`
`cache via LFS 28 and returns it to AP 46. If no and the signature does not match, NFC 42
`
`"invokes" 724 NFR 36 to retrieve the first directory sub-Object. NFC 42 "stores" 725 the sub-
`
`object into cache via LFS 28, NFC 42 "asks" 726 whether this is the last sub-object? If no and it
`
`is not the last sub-Object, NFC 42 invokes NFR 36 to "retrieve" the next directory SUb-objectand
`
`returns to step 725, If yes and it is the last sub-object, NFC 42 "stores" 728 the signature
`
`obtained via 721 or 711 into cache via LFS 28. NFC 42 "returns" 729 first sub-object from cache
`
`20
`
`via LFS 28 and returns the same to AP 46.
`
`By way of example, the following packet formats define this client server protocol:
`
`f(
`
`13
`
`Page 17 of 49
`
`
`
`II TYPE DEFINITIONS
`
`II
`
`BYTE =>an 8 bit value (octet) unsigned
`
`DWORD => a 16 bit value in which network byte ordering is not important
`
`5
`
`WORD => 32 bit value in which network byte ordering is not important
`
`MDWORD=> 32 bit value in which network byte ordering is important and represented
`
`using "motorola" or "big endian" format
`
`II START CONNECTION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; II always OxOO
`
`BYTE bResv; II
`
`WORD wSequenceValue; 1/
`
`liST ART CONNECTION RESPONSE
`
`typedef struct {
`
`BYlE bFunctionCode;
`
`// always Ox.80
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue // Same value as in request
`
`DWORD dConnectionHandle;
`
`II
`
`20
`
`}CVP_ START_CONNECTlON_RSP,
`
`*pCVP_START_CONNECTJON_RSP;
`
`/1 END CONNECTION REQUEST
`
`typedef struct }
`
`14
`
`Page 18 of 49
`
`
`
`BYTE bFunctioncode;
`
`Iialways OxOl
`
`BYTE bResv;
`
`II
`
`WORD wSequencevalue;
`
`II
`
`DWORD dConnectionHandle;
`
`II
`
`5
`
`/I as returned on start connection
`
`}CVP_END_CONNECTION_REQ,
`
`"CVP_END_CONNECTION_REQ;
`
`fIEND CONNECTION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`Iialways Ox81
`
`BYTE bStatus;
`
`II
`
`WORD wSequencevalue;
`
`II Same value as in request
`
`II OPEN OR CREATE Fll.E REQUEST
`
`typedef
`
`struct {
`
`BYTE bfunctioncode;
`
`II always Ox02
`
`BYTE bResv; II
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`MDWORD dFileAttributesMask;
`
`II
`
`20
`
`BYTE zFilePath[512];
`
`flnull
`
`terminated file name
`
`}CVP_OPEN_OR_CREATE]ll.E_REQ,
`
`·pCVP _OPEN_O~
`
`~REATE]ILE_REQ;
`
`IIOPEN OR OR CREATE FILE RESPONSE
`
`15
`
`Page 19 of 49
`
`
`
`typedef
`
`struct {
`
`BYTE bFunctionCode;
`
`II always Ox82
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue;
`
`II Same value as in request
`
`5
`
`DWORD dVerifiersFileHandle;
`
`II
`
`} CVP ~OPEN _ OR_CREATE ]ILE _RSP, *pCVP _OPEN_OR _CREATE ]ILE _ RSP;
`
`1/ CLOSE FILE REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`1/ always Ox03
`
`BYTE bResv;
`
`/1
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_ OR_CREATE
`
`}CVP _CLOSE ]lLE _REQ, *pCVP _CLOSE ]ILE _REQ;
`
`II CLOSE FILE RESPONSE
`
`typedef struct {
`
`:~
`
`BYTE bFunctionCode;
`
`// always Ox83
`
`BYTE bStatus;
`
`II
`
`WORD wSequenceValue;
`
`/1 Same value as in request
`
`20
`
`} CVP_CLOSE_FILE_RSP,
`
`*pCVP~CLOSE]ILE_RSP;
`
`II LOCK REGION REQUEST
`
`typedef struct {
`
`16
`
`Page 20 of 49
`
`
`
`BYTE bFunctionCode;
`
`II always Ox04
`
`BYTE bResv; //
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle; /I As returned on START_CONNECT
`
`5
`
`DWORD dVerifiersFileHandle; II As returned on OPEN_DR_CREATE
`
`MDWORD dSeekValue;
`
`Iloffset
`
`into file
`
`MDWORD dLength;
`
`Iinumber of bytes to lock
`
`}CVP_LOCK_REGION_REQ,
`
`*pCVP_LDCK_REGION_REQ;
`
`IILOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`(( always Ox84
`
`BYTE bStatus;
`
`II
`
`WORD wSequence Value; II Same value as in request
`
`DWORD
`
`dVerifiersLockHandle;
`
`} CVP_LOCK_REGION_RSP, *pCVP_LOCK_REGION_RSP;
`
`I!UNLOCK REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode; II always Ox05
`
`BYTE bResv; /1
`
`20
`
`WORD wSequenceValue;
`
`((
`
`DWORD dConnectionHandle; ((As returned on START_CONNECT
`
`DWORD dVerifiersLockHandle;
`
`// As returned LOCK REGION
`
`17
`
`Page 21 of 49
`
`
`
`} CVP_UNLOCK_REGION_REQ,
`
`*pCVP_UNLOCK_REGION_REQ;
`
`II UNLOCK REGION RESPONSE
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox85
`
`5
`
`BYTE bStatus;
`
`WORD wSequenceValue;
`
`If Same value as in request
`
`}CVP _UNLOCK_ REGION _RSP. *pCVP _UNLOCK _REGION_RSP;
`
`II VERIFY REGION REQUEST
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox06
`
`BYTE bResv;
`
`II if status is not 0xF1
`
`WORD wSequenceValue;
`
`II
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_OR_CREATE
`
`5
`
`MDWORD dSeekValue;
`
`II offset
`
`into file
`
`MDWORD dLength;
`
`Iinumber of bytes to verify
`
`BYTE Signature[8];
`
`IICRC adaptation
`
`} CVP _VERIFY _RFGION _REQ. *pCVP _ VERIFY_REGION _REQ;
`
`II VERIFY REGION RESPONSE # 1 (not
`
`locked data)
`
`20
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox86
`
`BYTE bStatus;
`
`II
`
`18
`
`Page 22 of 49
`
`
`
`WORD wSequenceValue;
`
`IISame value as in request
`
`1/
`
`1/ VERIFY REGION RESPONSE #2
`
`5
`
`1/ (if signatures did not match and region was locked)
`
`II
`
`typedef
`
`struct {
`
`BYTE bFunctionCode;
`
`II always Ox86
`
`BYTE bStatus;
`
`IIstatus = 0xF1 for this case
`
`WORD wSequenceValue;
`
`II Same value as in request
`
`MDWORD dLength;
`
`II # of bytes that follow
`
`char TheData[];
`
`/I
`
`} CVP_VERIFY_REGION_RSP,
`
`*pCVP_VERIFY_REGION_RSP;
`
`II READ REGION REQUEST
`
`II
`
`(sent only when reading from a locked region)
`
`typedef struct {
`
`BYTE bFunctionCode;
`
`II always Ox07
`
`BYTE bResv;
`
`II
`
`WORD wSequenceValue;
`
`II
`
`20
`
`DWORD dConnectionHandle;
`
`II As returned on START_CONNECT
`
`DWORD dVerifiersFileHandle;
`
`II As returned on OPEN_OR_CREATE
`
`MDWORD dSeekValue;
`
`//offset
`
`into file
`
`19
`
`Page 23 of 49
`
`
`
`WDWORD dLength;
`
`II number of bytes to read
`
`} CVP _READ _REGION_ REQ, *pCVP _