US20030204529A1 - File caching method and apparatus - Google Patents
File caching method and apparatus Download PDFInfo
- Publication number
- US20030204529A1 US20030204529A1 US10/128,916 US12891602A US2003204529A1 US 20030204529 A1 US20030204529 A1 US 20030204529A1 US 12891602 A US12891602 A US 12891602A US 2003204529 A1 US2003204529 A1 US 2003204529A1
- Authority
- US
- United States
- Prior art keywords
- file
- server
- files
- client
- cryptographically secure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
Definitions
- a problem with file caching over networks such as the Internet is that files are sometimes needlessly re-transmitted from a central-repository file server to one or more peripheral file caching servers.
- Unnecessary file re-transmission usually occurs when a single file has two or more names by which it can be requested or stored.
- a client computer's request for a copy of the file to a file caching server using one name can cause the file caching server to needlessly request the file from a central file server if the file caching server already has a copy of the requested file, albeit under a different name or version.
- a further problem with data caching is the time wasted to needlessly retrieve files from the file server 24 to the file caching server 10 when one or more of the clients 14 require resources from the file server 24 which might already be available on the file caching server 10 , especially when using a slow speed or limited bandwidth connection 22 between computer systems.
- the requested item might be retrievable using different file names, web page URLs, or other identifiers resulting in unnecessary file transfers between the file server 24 and the caching server 10 .
- Another problem with prior art file storage is the redundant storage under different file names of files that contain identical data. This can particularly be a problem in the context of file storage associated with the backup of files from many computers. In this context, a large number of computers may have files identical to the files on many of the other computers. A file storage device used for file backup of many computers may therefore store many copies of identical files having different names.
- FIG. 1 is a simplified block diagram of a data caching network and a web caching network.
- FIG. 2 is a simplified depiction of an exemplary file storage system using unique cryptographically secure file identifiers according to an embodiment of the present invention.
- FIG. 3 is a flow chart of a method for retrieving and saving files to and from a file caching server using cryptographically secure file identifiers according to an embodiment of the present invention.
- FIG. 4 is a flow chart of a method for caching files utilizing a cryptographically secure file identifier according to an embodiment of the present invention.
- FIG. 1 depicts a data network 100 that can be used for caching (i.e. storing for other computers) data or files.
- a data or “file” caching server 10 stores various types of data files in a file cache device 12 and makes cached files available to client computers 14 via a network 16 , such as a local area or wide area network (LAN or WAN respectively). Requests to a file server 24 from a client 16 are frequently handled by a file caching server 10 —although transparently to the client 16 .
- the file caching server 10 act as an image or functionally duplicate copy of the file server 24 , improving the apparent responsiveness of the server 24 .
- a web proxy 18 that has a web page cache 20 by which web pages stored in the cache memory device 20 can be made available to the various client computers 14 also via the network 16 .
- the file caching server 10 is operatively coupled to a file server 24 via a connection 22 that typically has slow data transfer rates (slow connection) or limited data transfer quantity (low available bandwidth) relative to the bandwidth of the LAN 16 or relative to the aggregate bandwidth of the client computer 14 connections to the file caching server 10 .
- the connection 22 between the file caching server 10 and the file server 24 may be implemented by way of a dialup connection the maximum data rate is typically less than 56 kbps.
- the file caching server 10 makes the contents of the file server 24 that is of interest to one or more of the client computers 14 , physically or electrically close to the client computers 14 thereby reducing the time required to transfer a file from the file cache 12 to one or more of the client computers 14 .
- the file transfer time via the connection 22 can be reduced or eliminated.
- the file caching server 10 appears to the client computers 14 to be the server 24 albeit it is a mirror image of the file server 24 the contents of which can be more quickly or more rapidly accessed by the client computers 14 .
- the web proxy server 18 serves as a more-readily accessible web resource than the web servers a and b, 26 and 28 respectively both of which are made logically available via the web proxy 18 and the communications it has with the servers 26 and 28 via the Internet 30 .
- FIG. 2 shows a simplified depiction of an exemplary file storage and retrieval system 200 which reduces unnecessary file transfers.
- Three client computers 14 (identified as 14 -A; 14 -B; and 14 -C) are operatively coupled to a file caching server 34 via a data network 30 .
- the network 30 can be embodied as a local area network (LAN), a wide area network (WAN) or the Internet as well as a slow speed/limited bandwidth dialup connection.
- LAN local area network
- WAN wide area network
- the Internet as well as a slow speed/limited bandwidth dialup connection.
- the file caching server 34 includes a central processing unit (CPU) 38 which executes program instructions by which files sent to the file caching server 34 from another file server 36 , can be stored within, and retrieved from the CPU's associated memory 40 .
- Memory 40 can be embodied as semiconductor memory such as static or dynamic random access memory (RAM) as well as magnetic disk media or optical storage devices such as CR-ROM.
- a file caching server is a dedicated network server or service within a server that caches files in order to speed up access to, and delivery of, information that has already been retrieved by a previous user.
- the file caching server 34 acts as a virtual copy or image of the main or central file server 36 .
- a single, central file server 36 might become overwhelmed with file save and file retrieval requests.
- Much (but not all) of the information stored on the file central file server 36 is also stored on the file caching server 34 in storage media that is preferably directly accessible to the file caching server 34 , e.g., by the file caching server accessing its own local mass storage, RAM, or other storage media, without having to obtain access permission from another computer.
- the file caching server 34 facilitates the distribution of files stored within the central file server 36 and the storage of files to the central file server 36 by way of copies of those same files kept within the file caching server memory 40 .
- files stored within the file caching server 34 can be more readily identified, accessed and retrieved by using cryptographically secure checksum file identifiers that are uniquely calculated from the actual contents of a data file that is retrievably stored within, or retrieved from the memory 40 of the file caching server 34 .
- Cryptographically secure checksums can also be used to unambiguously identify files even when a file is assigned several different names or other identifiers.
- Cryptographically secure checksums are calculated using the actual contents of a file. They can be calculated from even very large files and can be several hundreds of bytes in length, or more. They are characterized by their ability to uniquely identify a particular file using the actual file contents, which are processed according to an algorithm to yield a numerical index, the value of which is uniquely established by the file's contents. Stated alternatively, the contents of a particular file will yield the same particular cryptographically secure checksum regardless of the name assigned to the particular file. Furthermore, the chances that two different sets of file data could produce the same cryptographically secure checksum is almost nil.
- Files stored within the memory 40 of the file caching server 36 are organized by using the cryptographically secure checksum as a data entry in a data lookup table 42 , the entries of which correlate a single cryptographically secure checksum 44 to a file's contents 48 stored within the memory 40 .
- a cryptographically secure checksum 44 in the data lookup table 46 is indexed by (also considered as being pointed to or correlated with) one or more copies of a cryptographically secure checksum 50 stored in a file name lookup table 48 .
- the file name lookup table 48 is a list of file names 52 , 54 and their corresponding (or correlated with) cryptographically secure checksums 50 , 52 arranged in the table 48 such that a particular file 48 (in the data lookup table 46 ) for which a checksum 50 has been calculated might have two or more file names 52 and 54 in the filename lookup table 48 both of which are different names of the same file but which point to the same cryptographic checksum.
- file name identified by reference numeral 52 and a different file name identified by reference numeral 54 both correspond to the same checksum values 50 .
- the checksum identified by reference numeral 50 in the data lookup table 46 is an index or pointer to a particular file 48 stored in memory.
- the corresponding cryptographically secure checksum 50 uniquely identifies and locates the data 48 within the memory 40 of the server 34 as listed in the data lookup table 40 .
- the file caching server 34 can identify whether the file named “ONE” is available by examination of the file name lookup table 48 .
- the central file server 36 can first determine if the file named “FIVE” is resident on the central file server 36 by searching a list of stored file names and, if resident, determining that “FIVE” has a cryptographically secure checksum equal to “123456.” By returning the cryptographically secure checksum for the file named “FIVE” to the file caching server 34 , the file caching server 34 can then determine if it has already stored a file with the cryptographically secure checksum of “123456” and if so, return that file to the requesting client.
- the file caching server 34 can search the list of cryptographically secure checksums 52 and determine if an identical cryptographically secure checksum exists. If another file is stored with the same cryptographically secure checksum, albeit under a different name, the file caching server 34 can assume with a very high degree of certainty that the file with the cryptographically secure checksum of “123456” is identical to the FIVE file and that it corresponds to data 48 already stored in memory.
- a cryptographically secure checksum uniquely identifies a file by its contents
- the presence of a cryptographically secure checksum in a list of stored files unambiguously confirms that a requested file with a particular cryptographically secure checksum and a stored file having the same cryptographically secure check sum, are in fact, the same, even though they are of different names.
- the file caching server 34 can thereafter return to the requesting client computer 14 -A, the data 48 identified by the cryptographically secure checksum “123456.” A duplicative file transfer of the file named “FIVE” from the server 36 can be avoided.
- the methodology disclosed above has other applications.
- Using cryptographically secure checksums to identify files and to determine whether a file is resident on a computer can yield practical benefits in reducing unnecessary file transfers in many file transfer applications, such as on-line printing, which is a web-based service in which online print service providers (i.e., on-line print shops) accept print jobs from a customer and render printed output to the customer.
- the print job is sent from a customer to a print services provider via file transfers that occur via the Internet.
- the print service provider computer is analogous to the aforementioned main file server and the customer's client computer is analogous to the file caching server.
- a print job for an on-line print service provider can consist of several different files that a customer using a computer identified by reference numeral 14 -A for example, needs to send to a print service provider's computer embodied as the server identified by reference numeral 34 .
- a Quark document is an example of a document that can have multiple associated files such as font files, text files and graphics files. (The term “associated files” should be construed to mean files that are separate but related to each other in that all of the files are related to a particular print job.) All of the associated files are needed by the print service provider 34 to generate a printed document.
- the customer of an online print service provider (i.e., computer 14 -A for example) sends several different files of a Quark print job to the on-line print services provider 34 , but subsequently changes one or more of the files using either the client computer 14 -A or some other computer, which then transfers the file to computer 14 -A, the number of files that need to be resent to the server 34 can be quickly identified and only the modified files re-sent to the server 34 .
- the customer's client computer 14 -A can compute a checksum for each file to be sent. After the checksums are calculated, the Quark print job files can be transmitted to the print service provider 34 for processing the print job.
- the printer that would generate any printed output is not shown but those of skill in the art will recognize that the printer would be electrically coupled to the server 34 so as to be able to generate output.
- the Quark print job files can include font files, graphic or image files and text files.
- the customer's client computer 14 -A i.e., a “client” 14 -A to the print service providers “sever” computer 34
- the client computer 14 -A can ask the server 34 for the checksums of the print job files that the server 34 already has from any previous file transmissions.
- the client 14 -A By the client's 14 -A comparison of the cryptographically secure checksums (i.e., “checksums”) of print job files that are returned by the server, to the most-recently calculated checksums of print job files on the client 14 -A, the client 14 -A can identify the print job files on the server 34 that do not match the print job files on the server 34 and then send to the server 34 only the print job files on the client 14 -A, the checksums of which do not match the checksums of files stored on the server.
- checksums the cryptographically secure checksums
- Print job files for customers can be stored on the print services provider server for future use. If a customer returns to an on-line print service provider for more print services at a later date, or if a new customer submits a print job, the files from a previous print job might be re-useable in a new print job.
- the customer's client computer can calculate the cryptographically secure checksums of the print job and send those checksums to the server to allow the server to determine if it already has any of the checksums stored.
- the client can interrogate the server for the presence of files having particular checksums. Files on the server that have cryptographically secure checksums matching the checksums of a print job to be sent to the server can be determined to exist on the server and do not need to be re-transmitted to the server by the client.
- FIG. 3 depicts the steps of a method for managing the retrieval and storage of data files on a file caching server 34 depicted in FIG. 2.
- a file request message to the file caching server ( 34 in FIG. 2) is received from a client computer (e.g., 14 in FIG. 2) via a network, such as the Internet.
- the file-request step 302 is directed to a file caching server (i.e. a computer) whereat files are stored and from which files can be retrieved.
- a file caching server i.e. a computer
- Such a computer or network of computers where files are stored and from which they can be retrieved is also considered to be a “data resource” in that data can be obtained from and sent to such a device as needed.
- the file request step 302 could be either a request to store a file or retrieve a file.
- step 304 a determination is made of the file request message from the client computer 14 to determine whether or not it is a retrieval request 306 or a file save instruction 308 .
- step 310 is executed whereat the data resource uses the name or names of the file(s) requested as an index into a file name lookup table, such as the file name lookup table 48 depicted in FIG. 2.
- the data resource determines whether the named, requested file or files exist in the file name lookup table 48 . If the requested-file name does not exist in the filename lookup table, at step 314 an appropriate response is returned to the client computer indicating that: no file exists with the requested-file name. The file is retrieved from another server, the checksum is calculated and added it to the table before returning the requested file to the client.
- step 318 the cryptographically secure checksum 52 which corresponds to the file name located in the file name lookup table 48 is used in the data lookup table 46 to locate the data to be retrieved 46 .
- the file is retrieved from memory 40 and transmitted as part of step 320 to the requestor (e.g. a client 14 ) of the particular file.
- Program execution stops at step 316 .
- step 304 if the file request was a request to save (a “save file” request) or to store a file 308 at the file server 34 , the name of the file to be saved or stored is tested against existing file names in the file name lookup table 48 as part of step 322 . Using any appropriate sorting algorithm, the name of the file to be stored is searched for in the file lookup table 48 . If in step 324 it is determined that the name already exists, in step 326 the data resource (i.e. the computer) computes the cryptographically secure checksum of the data file received at step 302 and determines if that same cryptographically secure checksum is already stored within the file name lookup table 48 in step 328 . If it is determined that the cryptographically secure checksum does not already exist in memory, the recently-calculated cryptographically secure checksum is stored at step 330 in the data lookup table 48 along with the file name.
- the data resource i.e. the computer
- step 333 If the cryptographically secure checksum already exists in the file name lookup table, program control proceeds to step 333 where the file name received at step 302 is stored in the file name lookup table 48 along with the previously-calculated checksum. At step 333 the contents of the file name lookup table 48 are tested to determine if a different file name exists in the file name lookup table 48 with outdated cryptographically secure checksum 52 . At step 324 , if no file name exists with a different cryptographically secure checksum, that checksum and the associated file data is removed from the data lookup table 48 in step 324 . At the conclusion of either step 322 or the completion of step 324 program control is discontinued at step 316 as shown.
- step 324 if it is determined that the file named to be stored in memory does not exist at step 324 , the checksum of the data or file to be stored is calculated at step 338 using the file contents that were received at the data resource for storage. Once that checksum is computed at step 338 , a determination is made at step 340 whether or not the checksum exists in the data lookup table. If the computed cryptographically secure checksum does not exist, i.e. in the file name lookup table 48 , at step 342 the recently-calculated cryptographically secure checksum is stored with the data file that was used to calculate the cryptographically secure checksum in the lookup table 46 . The file name and the cryptographically secure checksum are stored in the file name lookup table 48 at step 344 . At step 340 , if the calculated checksum is determined to be within the data lookup table 46 , program control proceeds to step 344 .
- FIG. 4 depicts the steps of a method 400 for retrieving a cached data object from a data resource, such as the file caching server 34 depicted in FIG. 2.
- the method 400 begins with receipt of a request for an object, such as a data file in step 402 .
- a data resource such as the file caching server 34 receives a request for a file or object in step 402
- the method first performs a test for the presence of a (uniform resource identifier or “URI” at least part of which will be stored in the file caching server 34 filename lookup table 48 .
- the URI can be considered to be a combination of a file name and a server 36 (in FIG. 2) where the file name is expected to reside. The URI therefore approximates the file name being requested by a client computer for example.
- the data resource determines whether or not the requested URI is in the file name lookup table. If it is determined that the URI is not resident in the file name lookup table, in step 406 the data resource requests from its remote server 36 a cryptographically secure checksum corresponding to the URI that was requested from the data resource in step 402 , and receives the response from the remote server 36 .
- the data resource that was requested in step 402 for a particular object determines whether or not the remote server from which the object was requested supports file retrieval and storage using cryptographically secure checksum identifiers of objects. If the remote server supports cryptographic file storage and retrieval, at step 409 the object checksum is provided, and in step 410 the file caching server or other data resource determines whether the cryptographically secure checksum received as a response from the remote server in step is within the data lookup table 46 of the local server 34 . If it is determined that the cryptographically secure checksum is already in the data lookup table 46 , the data resource inserts that URI and checksum into its URI lookup table 48 at step 412 .
- the requested object or file is returned to the data requestor at step 414 with program execution ending at step 416 .
- the data resource or file caching server 34 uses the URI of the object requested in step 402 to request from the remote server a copy of the requested object in step 418 .
- the object data is provided.
- the requested object which for purposes of step 420 was delivered to the data resource by the remote server, has its cryptographically secure checksum calculated in step 420 .
- the data resource determines whether or not the calculated checksum is in the data resource data lookup table 46 . If it is determined that that checksum is in the data lookup table 46 program control transfer to step 412 after which the calculated checksum and the URI are used to return the requested object to the requestor in step 414 .
- step 412 if the calculated checksum is in the data lookup table 46 , step 412 is executed where the file name lookup table is updated. If the calculated checksum is not in the data lookup table 46 , the decision of step 422 is to “cache it” in memory in step 424 . The calculated checksum and data, already retrieved from the remote server is used to update the data lookup table 46 in step 427 . Program control then progresses from step 427 to step 412 where, as set forth above, the file name lookup table is updated with the calculated checksum and the URI as set forth above.
- the URI or file name in the file name lookup table 48 is used at step 428 to retrieve an object from the data resource or file caching server 34 .
- a method for managing data file storage in a data network comprises using cryptographically secure checksums as file identifiers.
- the presence or absence of a cryptographically secure checksum as a file identifier in a data resource, such as a file caching server operates as a shorthand method for determining the presence or absence of a requested file. If such a file identifier is present in a list or table against which one or more file names may be indexed, it is possible to search for either the cryptographically secure checksum or a file name.
- That cryptographically secure checksum operates as an index or identifier for the data from which the cryptographically secure checksum was calculated.
- two separate lists can be maintained. One list or table of file names and corresponding checksums can be used to quickly identify the presence or absence of files by their file names.
- a second table or list of just the cryptographically secure checksums as an index to the files from which those checksums were calculated can be used to quickly determine whether or not the file that yielded such a checksum is present. By quickly searching a list of such checksums, a request for a file by checksum can quickly yield a determination of whether or not the file is resident in the data resource.
- the request directed to a file caching server can avoid unnecessary file transfers from a remote server if the requested file is already resident on the caching server as evidenced by a cryptographically secure checksum that uniquely identifies the requested file as being resident in that server.
- the caching server can request from the remote server the checksum of the requested files and thereby determine if those checksums are the same as those in its already-stored tables.
- This method for managing data storage in a data network may be extended to more sophisticated cache management and data storage through techniques well known by those skilled in the art, such as write-aware data caching, and the storage and transmission of differences between versions of files as well as differences between two files having difference names.
- write-aware data caching and the storage and transmission of differences between versions of files as well as differences between two files having difference names.
Abstract
Description
- A problem with file caching over networks such as the Internet is that files are sometimes needlessly re-transmitted from a central-repository file server to one or more peripheral file caching servers. Unnecessary file re-transmission usually occurs when a single file has two or more names by which it can be requested or stored. A client computer's request for a copy of the file to a file caching server using one name can cause the file caching server to needlessly request the file from a central file server if the file caching server already has a copy of the requested file, albeit under a different name or version.
- A further problem with data caching is the time wasted to needlessly retrieve files from the
file server 24 to thefile caching server 10 when one or more of theclients 14 require resources from thefile server 24 which might already be available on thefile caching server 10, especially when using a slow speed orlimited bandwidth connection 22 between computer systems. When a file, web page or other data object is requested from thefile server 24 the requested item might be retrievable using different file names, web page URLs, or other identifiers resulting in unnecessary file transfers between thefile server 24 and thecaching server 10. - Another problem with prior art file storage is the redundant storage under different file names of files that contain identical data. This can particularly be a problem in the context of file storage associated with the backup of files from many computers. In this context, a large number of computers may have files identical to the files on many of the other computers. A file storage device used for file backup of many computers may therefore store many copies of identical files having different names.
- FIG. 1 is a simplified block diagram of a data caching network and a web caching network.
- FIG. 2 is a simplified depiction of an exemplary file storage system using unique cryptographically secure file identifiers according to an embodiment of the present invention.
- FIG. 3 is a flow chart of a method for retrieving and saving files to and from a file caching server using cryptographically secure file identifiers according to an embodiment of the present invention.
- FIG. 4 is a flow chart of a method for caching files utilizing a cryptographically secure file identifier according to an embodiment of the present invention.
- FIG. 1 depicts a
data network 100 that can be used for caching (i.e. storing for other computers) data or files. A data or “file”caching server 10 stores various types of data files in afile cache device 12 and makes cached files available toclient computers 14 via anetwork 16, such as a local area or wide area network (LAN or WAN respectively). Requests to afile server 24 from aclient 16 are frequently handled by afile caching server 10—although transparently to theclient 16. Thefile caching server 10 act as an image or functionally duplicate copy of thefile server 24, improving the apparent responsiveness of theserver 24. Also shown in FIG. 1 is aweb proxy 18 that has aweb page cache 20 by which web pages stored in thecache memory device 20 can be made available to thevarious client computers 14 also via thenetwork 16. - The
file caching server 10 is operatively coupled to afile server 24 via aconnection 22 that typically has slow data transfer rates (slow connection) or limited data transfer quantity (low available bandwidth) relative to the bandwidth of theLAN 16 or relative to the aggregate bandwidth of theclient computer 14 connections to thefile caching server 10. Theconnection 22 between thefile caching server 10 and thefile server 24 may be implemented by way of a dialup connection the maximum data rate is typically less than 56 kbps. - The
file caching server 10 makes the contents of thefile server 24 that is of interest to one or more of theclient computers 14, physically or electrically close to theclient computers 14 thereby reducing the time required to transfer a file from thefile cache 12 to one or more of theclient computers 14. Stated alternatively, by maintaining a copy of one or more files normally stored on thefile server 24 in afile caching server 10, the file transfer time via theconnection 22 can be reduced or eliminated. Instead, thefile caching server 10 appears to theclient computers 14 to be theserver 24 albeit it is a mirror image of thefile server 24 the contents of which can be more quickly or more rapidly accessed by theclient computers 14. Theweb proxy server 18 serves as a more-readily accessible web resource than the web servers a and b, 26 and 28 respectively both of which are made logically available via theweb proxy 18 and the communications it has with theservers - In data networks, including LANs, WANs as well as the Internet, unnecessary file transfers between computers can be avoided if it can be determined that a file requested from a server is already resident in or available on a caching server. Determining whether a file is resident on a computer, such as a server, can be ascertained by both a file name, such as a string of alphanumeric characters, and a numerical file identifier that uniquely identifies files. By using cryptographically secure checksums as numerical file identifiers, a file caching server that receives a request for a particular file or files can quickly determine if the file or files are available locally, simply by detecting the presence or absence of the cryptographically secure checksum used to identify the requested file or files. The Checksums are stored in the lookup tables46 and 48 in FIG. 1 and referenced in
blocks - FIG. 2 shows a simplified depiction of an exemplary file storage and
retrieval system 200 which reduces unnecessary file transfers. Three client computers 14 (identified as 14-A; 14-B; and 14-C) are operatively coupled to afile caching server 34 via adata network 30. Thenetwork 30 can be embodied as a local area network (LAN), a wide area network (WAN) or the Internet as well as a slow speed/limited bandwidth dialup connection. - The
file caching server 34 includes a central processing unit (CPU) 38 which executes program instructions by which files sent to thefile caching server 34 from anotherfile server 36, can be stored within, and retrieved from the CPU's associatedmemory 40.Memory 40 can be embodied as semiconductor memory such as static or dynamic random access memory (RAM) as well as magnetic disk media or optical storage devices such as CR-ROM. - A file caching server is a dedicated network server or service within a server that caches files in order to speed up access to, and delivery of, information that has already been retrieved by a previous user. The
file caching server 34 acts as a virtual copy or image of the main orcentral file server 36. In a data network, a single,central file server 36 might become overwhelmed with file save and file retrieval requests. Much (but not all) of the information stored on the filecentral file server 36 is also stored on thefile caching server 34 in storage media that is preferably directly accessible to thefile caching server 34, e.g., by the file caching server accessing its own local mass storage, RAM, or other storage media, without having to obtain access permission from another computer. As is well-known in the art, the existence and operation of thefile caching server 34 is usually transparent toclient computers 14. The file caching server facilitates the distribution of files stored within thecentral file server 36 and the storage of files to thecentral file server 36 by way of copies of those same files kept within the filecaching server memory 40. - Instead of using file names, (where a “file name” may be considered to be any string or combination of alphabetic or numeric characters, the combination of which is not calculated from or determined by a file's content) to identify files, files stored within the
file caching server 34 can be more readily identified, accessed and retrieved by using cryptographically secure checksum file identifiers that are uniquely calculated from the actual contents of a data file that is retrievably stored within, or retrieved from thememory 40 of thefile caching server 34. Cryptographically secure checksums can also be used to unambiguously identify files even when a file is assigned several different names or other identifiers. - Cryptographically secure checksums are calculated using the actual contents of a file. They can be calculated from even very large files and can be several hundreds of bytes in length, or more. They are characterized by their ability to uniquely identify a particular file using the actual file contents, which are processed according to an algorithm to yield a numerical index, the value of which is uniquely established by the file's contents. Stated alternatively, the contents of a particular file will yield the same particular cryptographically secure checksum regardless of the name assigned to the particular file. Furthermore, the chances that two different sets of file data could produce the same cryptographically secure checksum is almost nil.
- Files stored within the
memory 40 of thefile caching server 36 are organized by using the cryptographically secure checksum as a data entry in a data lookup table 42, the entries of which correlate a single cryptographically secure checksum 44 to a file'scontents 48 stored within thememory 40. - A cryptographically secure checksum44 in the data lookup table 46 is indexed by (also considered as being pointed to or correlated with) one or more copies of a cryptographically
secure checksum 50 stored in a file name lookup table 48. The file name lookup table 48 is a list offile names secure checksums checksum 50 has been calculated might have two ormore file names - From an inspection of the file lookup table48 and the data lookup table 46, it can be seen that file name identified by
reference numeral 52 and a different file name identified byreference numeral 54 both correspond to thesame checksum values 50. The checksum identified byreference numeral 50 in the data lookup table 46 is an index or pointer to aparticular file 48 stored in memory. - If it is desired to retrieve a particular file by file name, and if that file name is resident in lookup table48, the corresponding cryptographically
secure checksum 50 uniquely identifies and locates thedata 48 within thememory 40 of theserver 34 as listed in the data lookup table 40. By way of example, if a client computer, 14-A for instance, requests a copy of the file named “ONE,” thefile caching server 34 can identify whether the file named “ONE” is available by examination of the file name lookup table 48. If a client computer requests a file named “FIVE,” an inspection of the filename lookup table 48 reveals that no such file name exists in the table, suggesting that thefile caching server 34 needs to request the file from itscentral file server 36—a process that takes time and data network resources. - Instead of the
file caching server 34 immediately requesting a download of the file “FIVE,” thecentral file server 36 can first determine if the file named “FIVE” is resident on thecentral file server 36 by searching a list of stored file names and, if resident, determining that “FIVE” has a cryptographically secure checksum equal to “123456.” By returning the cryptographically secure checksum for the file named “FIVE” to thefile caching server 34, thefile caching server 34 can then determine if it has already stored a file with the cryptographically secure checksum of “123456” and if so, return that file to the requesting client. - Upon the file caching server's34 receipt of the cryptographically secure checksum of “123456” from the
central file server 36, thefile caching server 34 can search the list of cryptographicallysecure checksums 52 and determine if an identical cryptographically secure checksum exists. If another file is stored with the same cryptographically secure checksum, albeit under a different name, thefile caching server 34 can assume with a very high degree of certainty that the file with the cryptographically secure checksum of “123456” is identical to the FIVE file and that it corresponds todata 48 already stored in memory. Because a cryptographically secure checksum uniquely identifies a file by its contents, the presence of a cryptographically secure checksum in a list of stored files unambiguously confirms that a requested file with a particular cryptographically secure checksum and a stored file having the same cryptographically secure check sum, are in fact, the same, even though they are of different names. Thefile caching server 34 can thereafter return to the requesting client computer 14-A, thedata 48 identified by the cryptographically secure checksum “123456.” A duplicative file transfer of the file named “FIVE” from theserver 36 can be avoided. - In addition to detecting when a file caching server should request a copy from, or store a file to a main file server, the methodology disclosed above has other applications. Using cryptographically secure checksums to identify files and to determine whether a file is resident on a computer can yield practical benefits in reducing unnecessary file transfers in many file transfer applications, such as on-line printing, which is a web-based service in which online print service providers (i.e., on-line print shops) accept print jobs from a customer and render printed output to the customer. The print job is sent from a customer to a print services provider via file transfers that occur via the Internet. In an application like on-line printing, the print service provider computer is analogous to the aforementioned main file server and the customer's client computer is analogous to the file caching server.
- With respect to the computers depicted in FIG. 2, a print job for an on-line print service provider can consist of several different files that a customer using a computer identified by reference numeral14-A for example, needs to send to a print service provider's computer embodied as the server identified by
reference numeral 34. A Quark document is an example of a document that can have multiple associated files such as font files, text files and graphics files. (The term “associated files” should be construed to mean files that are separate but related to each other in that all of the files are related to a particular print job.) All of the associated files are needed by theprint service provider 34 to generate a printed document. If the customer of an online print service provider, (i.e., computer 14-A for example) sends several different files of a Quark print job to the on-lineprint services provider 34, but subsequently changes one or more of the files using either the client computer 14-A or some other computer, which then transfers the file to computer 14-A, the number of files that need to be resent to theserver 34 can be quickly identified and only the modified files re-sent to theserver 34. - In the foregoing example, before sending the Quark print job files to the on-line
print service provider 34, the customer's client computer 14-A can compute a checksum for each file to be sent. After the checksums are calculated, the Quark print job files can be transmitted to theprint service provider 34 for processing the print job. (The printer that would generate any printed output is not shown but those of skill in the art will recognize that the printer would be electrically coupled to theserver 34 so as to be able to generate output.) The Quark print job files can include font files, graphic or image files and text files. If after transmitting the print job files to theserver 34, the customer 14-A changes a text file for instance, unnecessary file transfers of the font files and graphics files can be avoided by using the cryptographically secure checksums to identify the particular files that need to be resent to theprint service provider 34. - When one or more files of a multi-file print job is changed, the customer's client computer14-A (i.e., a “client” 14-A to the print service providers “sever” computer 34) can recalculate checksums for the files of the print job. After doing so, the client computer 14-A can ask the
server 34 for the checksums of the print job files that theserver 34 already has from any previous file transmissions. By the client's 14-A comparison of the cryptographically secure checksums (i.e., “checksums”) of print job files that are returned by the server, to the most-recently calculated checksums of print job files on the client 14-A, the client 14-A can identify the print job files on theserver 34 that do not match the print job files on theserver 34 and then send to theserver 34 only the print job files on the client 14-A, the checksums of which do not match the checksums of files stored on the server. - Print job files for customers can be stored on the print services provider server for future use. If a customer returns to an on-line print service provider for more print services at a later date, or if a new customer submits a print job, the files from a previous print job might be re-useable in a new print job. Before a client sends files of a print job to the print services provider's server computer, the customer's client computer can calculate the cryptographically secure checksums of the print job and send those checksums to the server to allow the server to determine if it already has any of the checksums stored. Alternatively, the client can interrogate the server for the presence of files having particular checksums. Files on the server that have cryptographically secure checksums matching the checksums of a print job to be sent to the server can be determined to exist on the server and do not need to be re-transmitted to the server by the client.
- While the foregoing example is with regard to on-line printing, those of ordinary skill in the art will recognize the method can be applied to any other technology or service requiring file transfers.
- FIG. 3 depicts the steps of a method for managing the retrieval and storage of data files on a
file caching server 34 depicted in FIG. 2. Atstep 302, a file request message to the file caching server (34 in FIG. 2) is received from a client computer (e.g., 14 in FIG. 2) via a network, such as the Internet. In the context of themethod 300 shown in FIG. 3, the file-request step 302 is directed to a file caching server (i.e. a computer) whereat files are stored and from which files can be retrieved. Such a computer or network of computers where files are stored and from which they can be retrieved is also considered to be a “data resource” in that data can be obtained from and sent to such a device as needed. - In the most general application of the method depicted in FIG. 3, the
file request step 302 could be either a request to store a file or retrieve a file. In step 304 a determination is made of the file request message from theclient computer 14 to determine whether or not it is aretrieval request 306 or a file saveinstruction 308. - In the case where a file request is a
retrieval request 306, (i.e. a request to the data resource to send a particular file or files)step 310 is executed whereat the data resource uses the name or names of the file(s) requested as an index into a file name lookup table, such as the file name lookup table 48 depicted in FIG. 2. - Using any appropriate sorting algorithm, at
step 312, the data resource (a file caching server) determines whether the named, requested file or files exist in the file name lookup table 48. If the requested-file name does not exist in the filename lookup table, atstep 314 an appropriate response is returned to the client computer indicating that: no file exists with the requested-file name. The file is retrieved from another server, the checksum is calculated and added it to the table before returning the requested file to the client. - If the requested-file name is determined to exist in the file name lookup table48, and for which a cryptographically-secure checksum will therefore exist, at
step 318 the cryptographicallysecure checksum 52 which corresponds to the file name located in the file name lookup table 48 is used in the data lookup table 46 to locate the data to be retrieved 46. Instep 320, the file is retrieved frommemory 40 and transmitted as part ofstep 320 to the requestor (e.g. a client 14) of the particular file. Program execution stops atstep 316. - Returning to step304, if the file request was a request to save (a “save file” request) or to store a
file 308 at thefile server 34, the name of the file to be saved or stored is tested against existing file names in the file name lookup table 48 as part ofstep 322. Using any appropriate sorting algorithm, the name of the file to be stored is searched for in the file lookup table 48. If instep 324 it is determined that the name already exists, instep 326 the data resource (i.e. the computer) computes the cryptographically secure checksum of the data file received atstep 302 and determines if that same cryptographically secure checksum is already stored within the file name lookup table 48 instep 328. If it is determined that the cryptographically secure checksum does not already exist in memory, the recently-calculated cryptographically secure checksum is stored atstep 330 in the data lookup table 48 along with the file name. - If the cryptographically secure checksum already exists in the file name lookup table, program control proceeds to step333 where the file name received at
step 302 is stored in the file name lookup table 48 along with the previously-calculated checksum. Atstep 333 the contents of the file name lookup table 48 are tested to determine if a different file name exists in the file name lookup table 48 with outdated cryptographicallysecure checksum 52. Atstep 324, if no file name exists with a different cryptographically secure checksum, that checksum and the associated file data is removed from the data lookup table 48 instep 324. At the conclusion of eitherstep 322 or the completion ofstep 324 program control is discontinued atstep 316 as shown. - Returning to step324, if it is determined that the file named to be stored in memory does not exist at
step 324, the checksum of the data or file to be stored is calculated atstep 338 using the file contents that were received at the data resource for storage. Once that checksum is computed atstep 338, a determination is made atstep 340 whether or not the checksum exists in the data lookup table. If the computed cryptographically secure checksum does not exist, i.e. in the file name lookup table 48, atstep 342 the recently-calculated cryptographically secure checksum is stored with the data file that was used to calculate the cryptographically secure checksum in the lookup table 46. The file name and the cryptographically secure checksum are stored in the file name lookup table 48 atstep 344. Atstep 340, if the calculated checksum is determined to be within the data lookup table 46, program control proceeds to step 344. - FIG. 4 depicts the steps of a
method 400 for retrieving a cached data object from a data resource, such as thefile caching server 34 depicted in FIG. 2. In FIG. 4, themethod 400 begins with receipt of a request for an object, such as a data file instep 402. When a data resource such as thefile caching server 34 receives a request for a file or object instep 402, instep 404, the method first performs a test for the presence of a (uniform resource identifier or “URI” at least part of which will be stored in thefile caching server 34 filename lookup table 48. The URI can be considered to be a combination of a file name and a server 36 (in FIG. 2) where the file name is expected to reside. The URI therefore approximates the file name being requested by a client computer for example. - At
step 404, the data resource determines whether or not the requested URI is in the file name lookup table. If it is determined that the URI is not resident in the file name lookup table, instep 406 the data resource requests from its remote server 36 a cryptographically secure checksum corresponding to the URI that was requested from the data resource instep 402, and receives the response from theremote server 36. - At
step 408, the data resource that was requested instep 402 for a particular object determines whether or not the remote server from which the object was requested supports file retrieval and storage using cryptographically secure checksum identifiers of objects. If the remote server supports cryptographic file storage and retrieval, atstep 409 the object checksum is provided, and instep 410 the file caching server or other data resource determines whether the cryptographically secure checksum received as a response from the remote server in step is within the data lookup table 46 of thelocal server 34. If it is determined that the cryptographically secure checksum is already in the data lookup table 46, the data resource inserts that URI and checksum into its URI lookup table 48 atstep 412. The requested object or file is returned to the data requestor atstep 414 with program execution ending atstep 416. Returning to step 408, if it is determined that theremote server 36 does not support object requests using cryptographically secure checksums, the data resource orfile caching server 34 uses the URI of the object requested instep 402 to request from the remote server a copy of the requested object instep 418. Atstep 419, the object data is provided. Atstep 420, the requested object, which for purposes ofstep 420 was delivered to the data resource by the remote server, has its cryptographically secure checksum calculated instep 420. Atstep 422 the data resource determines whether or not the calculated checksum is in the data resource data lookup table 46. If it is determined that that checksum is in the data lookup table 46 program control transfer to step 412 after which the calculated checksum and the URI are used to return the requested object to the requestor instep 414. - At
step 422, if the calculated checksum is in the data lookup table 46,step 412 is executed where the file name lookup table is updated. If the calculated checksum is not in the data lookup table 46, the decision ofstep 422 is to “cache it” in memory instep 424. The calculated checksum and data, already retrieved from the remote server is used to update the data lookup table 46 in step 427. Program control then progresses from step 427 to step 412 where, as set forth above, the file name lookup table is updated with the calculated checksum and the URI as set forth above. - Returning to step404, if the URI is determined to be within the file name lookup table 48, the URI or file name in the file name lookup table 48 is used at
step 428 to retrieve an object from the data resource orfile caching server 34. - From the foregoing, it should be apparent that a method for managing data file storage in a data network comprises using cryptographically secure checksums as file identifiers. The presence or absence of a cryptographically secure checksum as a file identifier in a data resource, such as a file caching server, operates as a shorthand method for determining the presence or absence of a requested file. If such a file identifier is present in a list or table against which one or more file names may be indexed, it is possible to search for either the cryptographically secure checksum or a file name. If correspondence between a file name and a cryptographically secure checksum exists, that cryptographically secure checksum operates as an index or identifier for the data from which the cryptographically secure checksum was calculated. Stated alternatively, two separate lists can be maintained. One list or table of file names and corresponding checksums can be used to quickly identify the presence or absence of files by their file names. A second table or list of just the cryptographically secure checksums as an index to the files from which those checksums were calculated can be used to quickly determine whether or not the file that yielded such a checksum is present. By quickly searching a list of such checksums, a request for a file by checksum can quickly yield a determination of whether or not the file is resident in the data resource.
- If a client computer requests one or more files by name, the request directed to a file caching server can avoid unnecessary file transfers from a remote server if the requested file is already resident on the caching server as evidenced by a cryptographically secure checksum that uniquely identifies the requested file as being resident in that server. In instances where there may be ambiguity of the requested file name, the caching server can request from the remote server the checksum of the requested files and thereby determine if those checksums are the same as those in its already-stored tables.
- This method for managing data storage in a data network may be extended to more sophisticated cache management and data storage through techniques well known by those skilled in the art, such as write-aware data caching, and the storage and transmission of differences between versions of files as well as differences between two files having difference names. Those of ordinary skill in the computer science and data network arts will recognize that these and other variations can be implemented with appropriately programmed computers using stored program instructions kept within
memory 40 or other accessible storage media, and that the foregoing embodiments are within the scope of the appended claims.
Claims (31)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/128,916 US6944634B2 (en) | 2002-04-24 | 2002-04-24 | File caching method and apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/128,916 US6944634B2 (en) | 2002-04-24 | 2002-04-24 | File caching method and apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
US20030204529A1 true US20030204529A1 (en) | 2003-10-30 |
US6944634B2 US6944634B2 (en) | 2005-09-13 |
Family
ID=29248521
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/128,916 Expired - Lifetime US6944634B2 (en) | 2002-04-24 | 2002-04-24 | File caching method and apparatus |
Country Status (1)
Country | Link |
---|---|
US (1) | US6944634B2 (en) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040020389A1 (en) * | 2002-08-01 | 2004-02-05 | Holmstead Stanley Bruce | Cache memory system and method for printers |
US20060242184A1 (en) * | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Efficiently describing relationships between resources |
US20060242105A1 (en) * | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Pack URI scheme to identify and reference parts of a package |
KR100719285B1 (en) | 2005-03-30 | 2007-05-17 | (주)이스트소프트 | Distributed file management system in web storage and the method thereof |
US20070172154A1 (en) * | 2006-01-20 | 2007-07-26 | Fujitsu Limited | Data medium discrimination information database creating apparatus, data medium discrimination information database managing apparatus, computer readable recording medium recorded thereon data medium discrimination information database creating program, and data medium discriminating apparatus |
US20070256048A1 (en) * | 2006-05-01 | 2007-11-01 | Microsoft Corporation | Loading application resources |
US7542992B1 (en) * | 2005-08-01 | 2009-06-02 | Google Inc. | Assimilator using image check data |
US20110246477A1 (en) * | 2006-08-25 | 2011-10-06 | Qnx Software Systems Limited | Filesystem having a filename cache |
US20120131004A1 (en) * | 2008-08-11 | 2012-05-24 | Mcdermott Matt | Method for enhanced vehicle service |
US20120257560A1 (en) * | 2011-04-07 | 2012-10-11 | Sudharshan Srinivasan | Cellular data bandwidth optimization using social networking concepts |
US20130204961A1 (en) * | 2012-02-02 | 2013-08-08 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US20130227379A1 (en) * | 2012-02-23 | 2013-08-29 | International Business Machines Corporation | Efficient checksums for shared nothing clustered filesystems |
US20160191455A1 (en) * | 2014-12-31 | 2016-06-30 | Level 3 Communications, Llc | Network address resolution |
US9407726B1 (en) * | 2013-03-15 | 2016-08-02 | Juniper Networks, Inc. | Caching objects identified by dynamic resource identifiers |
US20160255042A1 (en) * | 2015-02-27 | 2016-09-01 | Level 3 Communications, Llc | Network address resolution |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030009522A1 (en) * | 2001-07-05 | 2003-01-09 | Rau Sadhana S. | Method for propagating teamware transactions |
CN1799051B (en) * | 2003-06-03 | 2010-05-12 | 株式会社爱可信 | Method for browsing contents using page storing file |
US7134070B2 (en) * | 2003-09-08 | 2006-11-07 | Intel Corporation | Checksum determination |
US7475281B2 (en) * | 2005-03-10 | 2009-01-06 | International Business Machines Corporation | Method for synchronizing replicas of a database |
WO2011123796A2 (en) * | 2010-04-02 | 2011-10-06 | Enzo Stancato | Apparatus and method for processing digital content |
US8943315B1 (en) * | 2011-06-08 | 2015-01-27 | Google Inc. | System and method for controlling the upload of data already accessible to a server |
US9736121B2 (en) | 2012-07-16 | 2017-08-15 | Owl Cyber Defense Solutions, Llc | File manifest filter for unidirectional transfer of files |
CN103731447B (en) * | 2012-10-11 | 2019-03-26 | 腾讯科技(深圳)有限公司 | A kind of data query method and system |
US10218586B2 (en) | 2013-01-23 | 2019-02-26 | Owl Cyber Defense Solutions, Llc | System and method for enabling the capture and securing of dynamically selected digital information |
US8776254B1 (en) | 2013-01-23 | 2014-07-08 | Owl Computing Technologies, Inc. | System and method for the secure unidirectional transfer of software and software updates |
US9306953B2 (en) | 2013-02-19 | 2016-04-05 | Owl Computing Technologies, Inc. | System and method for secure unidirectional transfer of commands to control equipment |
US9311329B2 (en) | 2014-06-05 | 2016-04-12 | Owl Computing Technologies, Inc. | System and method for modular and continuous data assurance |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5987123A (en) * | 1996-07-03 | 1999-11-16 | Sun Microsystems, Incorporated | Secure file system |
US6047356A (en) * | 1994-04-18 | 2000-04-04 | Sonic Solutions | Method of dynamically allocating network node memory's partitions for caching distributed files |
US6249866B1 (en) * | 1997-09-16 | 2001-06-19 | Microsoft Corporation | Encrypting file system and method |
US6405315B1 (en) * | 1997-09-11 | 2002-06-11 | International Business Machines Corporation | Decentralized remotely encrypted file system |
US6766352B1 (en) * | 2000-05-04 | 2004-07-20 | International Business Machines Corporation | Indicator to show that a cached file is being displayed on a client system |
-
2002
- 2002-04-24 US US10/128,916 patent/US6944634B2/en not_active Expired - Lifetime
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6047356A (en) * | 1994-04-18 | 2000-04-04 | Sonic Solutions | Method of dynamically allocating network node memory's partitions for caching distributed files |
US5987123A (en) * | 1996-07-03 | 1999-11-16 | Sun Microsystems, Incorporated | Secure file system |
US6405315B1 (en) * | 1997-09-11 | 2002-06-11 | International Business Machines Corporation | Decentralized remotely encrypted file system |
US6249866B1 (en) * | 1997-09-16 | 2001-06-19 | Microsoft Corporation | Encrypting file system and method |
US6766352B1 (en) * | 2000-05-04 | 2004-07-20 | International Business Machines Corporation | Indicator to show that a cached file is being displayed on a client system |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040020389A1 (en) * | 2002-08-01 | 2004-02-05 | Holmstead Stanley Bruce | Cache memory system and method for printers |
US7265866B2 (en) * | 2002-08-01 | 2007-09-04 | Hewlett-Packard Development Company, L.P. | Cache memory system and method for printers |
KR100719285B1 (en) | 2005-03-30 | 2007-05-17 | (주)이스트소프트 | Distributed file management system in web storage and the method thereof |
US7437367B2 (en) | 2005-04-22 | 2008-10-14 | Microsoft Corporation | Pack URI scheme to identify and reference parts of a package |
US8135750B2 (en) | 2005-04-22 | 2012-03-13 | Microsoft Corporation | Efficiently describing relationships between resources |
US20060242105A1 (en) * | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Pack URI scheme to identify and reference parts of a package |
WO2006115654A2 (en) * | 2005-04-22 | 2006-11-02 | Microsoft Corporation | Pack uri scheme to identify and reference parts of a package |
US20060242184A1 (en) * | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Efficiently describing relationships between resources |
WO2006115654A3 (en) * | 2005-04-22 | 2009-05-07 | Microsoft Corp | Pack uri scheme to identify and reference parts of a package |
US7542992B1 (en) * | 2005-08-01 | 2009-06-02 | Google Inc. | Assimilator using image check data |
US20070172154A1 (en) * | 2006-01-20 | 2007-07-26 | Fujitsu Limited | Data medium discrimination information database creating apparatus, data medium discrimination information database managing apparatus, computer readable recording medium recorded thereon data medium discrimination information database creating program, and data medium discriminating apparatus |
US20070256048A1 (en) * | 2006-05-01 | 2007-11-01 | Microsoft Corporation | Loading application resources |
US7814498B2 (en) | 2006-05-01 | 2010-10-12 | Microsoft Corporation | Loading application resources |
US20110246477A1 (en) * | 2006-08-25 | 2011-10-06 | Qnx Software Systems Limited | Filesystem having a filename cache |
US8122178B2 (en) * | 2006-08-25 | 2012-02-21 | Qnx Software Systems Limited | Filesystem having a filename cache |
US20120131004A1 (en) * | 2008-08-11 | 2012-05-24 | Mcdermott Matt | Method for enhanced vehicle service |
US8818976B2 (en) * | 2008-08-11 | 2014-08-26 | Matt McDermott | Method for enhanced vehicle service |
US20120257560A1 (en) * | 2011-04-07 | 2012-10-11 | Sudharshan Srinivasan | Cellular data bandwidth optimization using social networking concepts |
US10848587B2 (en) | 2012-02-02 | 2020-11-24 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US10356202B2 (en) | 2012-02-02 | 2019-07-16 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US9167049B2 (en) * | 2012-02-02 | 2015-10-20 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US11343351B2 (en) | 2012-02-02 | 2022-05-24 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US20130204961A1 (en) * | 2012-02-02 | 2013-08-08 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US11792276B2 (en) | 2012-02-02 | 2023-10-17 | Comcast Cable Communications, Llc | Content distribution network supporting popularity-based caching |
US9128862B2 (en) * | 2012-02-23 | 2015-09-08 | International Business Machines Corporation | Efficient checksums for shared nothing clustered filesystems |
US20130227379A1 (en) * | 2012-02-23 | 2013-08-29 | International Business Machines Corporation | Efficient checksums for shared nothing clustered filesystems |
US9407726B1 (en) * | 2013-03-15 | 2016-08-02 | Juniper Networks, Inc. | Caching objects identified by dynamic resource identifiers |
US9992296B2 (en) | 2013-03-15 | 2018-06-05 | Juniper Networks, Inc. | Caching objects identified by dynamic resource identifiers |
US10348801B2 (en) * | 2014-12-31 | 2019-07-09 | Level 3 Communications, Llc | Network address resolution |
US10057322B2 (en) * | 2014-12-31 | 2018-08-21 | Level 3 Communications, Llc | Network address resolution |
US20190327286A1 (en) * | 2014-12-31 | 2019-10-24 | Level 3 Communications, Llc | Network address resolution |
US20230388361A1 (en) * | 2014-12-31 | 2023-11-30 | Level 3 Communications, Llc | Network address resolution |
US10764355B2 (en) * | 2014-12-31 | 2020-09-01 | Level 3 Communications, Llc | Network address resolution |
US11451612B2 (en) * | 2014-12-31 | 2022-09-20 | Level 3 Communications, Llc | Network address resolution |
US20200389513A1 (en) * | 2014-12-31 | 2020-12-10 | Level 3 Communications, Llc | Network address resolution |
US11729249B2 (en) * | 2014-12-31 | 2023-08-15 | Level 3 Communications, Llc | Network address resolution |
US20160191455A1 (en) * | 2014-12-31 | 2016-06-30 | Level 3 Communications, Llc | Network address resolution |
US20230018743A1 (en) * | 2014-12-31 | 2023-01-19 | Level 3 Communications, Llc | Network address resolution |
US10715481B2 (en) * | 2015-02-27 | 2020-07-14 | Level 3 Communications, Llc | Network address resolution |
US20220191166A1 (en) * | 2015-02-27 | 2022-06-16 | Level 3 Communications, Llc | Network address resolution |
US11627108B2 (en) * | 2015-02-27 | 2023-04-11 | Level 3 Communications, Llc | Network address resolution |
US11277374B2 (en) * | 2015-02-27 | 2022-03-15 | Level 3 Communications, Llc | Network address resolution |
US10382385B2 (en) * | 2015-02-27 | 2019-08-13 | Level 3 Communications, Llc | Network address resolution |
US20160255042A1 (en) * | 2015-02-27 | 2016-09-01 | Level 3 Communications, Llc | Network address resolution |
US11929978B2 (en) * | 2015-02-27 | 2024-03-12 | Level 3 Communications, Llc | Network address resolution |
Also Published As
Publication number | Publication date |
---|---|
US6944634B2 (en) | 2005-09-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6944634B2 (en) | File caching method and apparatus | |
US11194719B2 (en) | Cache optimization | |
US8275790B2 (en) | System and method of accessing a document efficiently through multi-tier web caching | |
US8224964B1 (en) | System and method of accessing a document efficiently through multi-tier web caching | |
US6754800B2 (en) | Methods and apparatus for implementing host-based object storage schemes | |
US9219705B2 (en) | Scaling network services using DNS | |
US7587398B1 (en) | System and method of accessing a document efficiently through multi-tier web caching | |
US7565423B1 (en) | System and method of accessing a document efficiently through multi-tier web caching | |
US7530115B2 (en) | Access to content addressable data over a network | |
US7552220B2 (en) | System and method to refresh proxy cache server objects | |
EP1825376B1 (en) | Content addressed storage device configured to maintain content address mapping | |
US7647417B1 (en) | Object cacheability with ICAP | |
US20050240574A1 (en) | Pre-fetching resources based on a resource lookup query | |
US20060123121A1 (en) | System and method for service session management | |
WO1998045978A2 (en) | Method and apparatus for providing remote site administrators with user hits on mirrored web sites | |
US20070220000A1 (en) | Universal Cache | |
US20020107986A1 (en) | Methods and systems for replacing data transmission request expressions | |
EP1454268B1 (en) | Electronic file management | |
US11829345B2 (en) | Distributed data processing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT PACKARD COMPANY, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HERTLING, WILLIAM EDWARD;WHITMARSH, MICHAEL DEAN;REEL/FRAME:013021/0176 Effective date: 20020418 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., COLORAD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928 Effective date: 20030131 Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.,COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928 Effective date: 20030131 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
CC | Certificate of correction | ||
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FPAY | Fee payment |
Year of fee payment: 12 |