# Patent

## Title
Memory efficient indexing for disk-based compression

## Abstract

A network optimization device may receive a stream of data and generate a signature for a plurality of fixed length overlapping windows of the stream of data. The device may select a predetermined number of the generated signatures for each Ln-byte segment of the data stream, wherein Ln is greater than a length of each of the windows. The network device may store the selected signatures in a bucketed hash table that includes a linked-list of entries for each bucket.

## Background
This application is a continuation of U.S. application Ser. No. 11/694,355, filed Mar. 30, 2007, the disclosure of which is incorporated herein by reference.


BACKGROUND OF THE INVENTION
A. Field of the Invention
Concepts described herein relate generally to data compression, and more particularly, to a compression scheme with disk-based dictionary in a wide area network optimization device.
B. Description of Related Art
Geographically distributed entities, such as a business with multiple local offices in different locations, frequently desire to maintain a logically unified proprietary network that is accessible by all of the geographically distributed entities. To accomplish this, a wide area network (WAN) may be used to link the different locations.
Information technology managers within geographically distributed entities face the conflicting requirements of keeping costs in check while providing users with new and faster applications. This conflict is most acute on the WAN, where costs can be high and getting applications to perform well is hampered by limited bandwidth and high latency.
Solutions are known to help improve performance over the WAN portion of a network. These solutions may be based on a number of technologies, including data compression, data prefetching and caching, application-specific acceleration, and policy-based bandwidth allocation.
Data caching and compression, in particular, can be used to reduce the perceived latency (response time) of data accesses over a WAN. Compression and caching techniques may be disk-based, as opposed to semiconductor memory based, due to orders-of-magnitude larger storage capacity of typical hard disk drives.
Compression techniques using disk-based dictionary can be particularly effective in compressing large file transfers. With this type of compression technique, data may be stored on disk drives at compression devices at opposite ends of the WAN. When a block of data that has been previously sent is again received by the compression device, the compression device does not need to send the actual block of data. Instead, it may simply send a reference to the block of data to the device on the other end of the WAN.
In order to perform dictionary-based compression efficiently, some form of index is usually constructed and maintained by the compression devices. Efficiently constructing and using such an index can be important to maximizing the effectiveness of the compression device.
SUMMARY
One aspect is directed to a method comprising receiving a stream of data; generating a signature for a plurality of fixed length overlapping windows of the stream of data; selecting a predetermined number of the generated signatures for each Ln length segment of the data stream, wherein Ln is greater than the length of each of the windows; and storing the selected signatures in a bucketed hash table that includes a linked-list of entries in each bucket of the hash table.
Another aspect is directed to a network device. The network device may include one or more disk drives and logic to store data to the one or more disk drives. The network device maintains a lookup table that stores signatures that are used to determine when a block of data has been previously processed by the network device and compress the block of data when the data is transmitted over a network. The lookup table may include a bucketed hash table where each bucket in the hash table is structured as a linked-list of entries and corresponds to an index of the hash table, each of the entries including a signature of a block of data and an identifier indicating where on the one or more disk drives the block of data is stored.
Yet another aspect is directed to a method performed in a first network device. The method may include generating a signature for a block of data in a data stream; matching the generated signature to signatures stored in a bucketed hash table in which hash table collisions are stored in a linked-list structure, the matching including comparing the signature to a plurality of previously stored signatures in a bucket of the hash table that corresponds to the generated signature; matching the block of data to a previously stored block of data when a match of the signature is detected in the bucketed hash table; and transmitting a reference to the block of data to a second network device when a match is detected in the bucketed hash table and the block of data is matched to the previously stored block of data.



BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, explain the invention. In the drawings,
FIG. 1 is a diagram of an exemplary system;
FIG. 2 is a block diagram of an exemplary device shown in FIG. 1;
FIG. 3 is a diagram illustrating data compression over a wide area network;
FIG. 4 is a diagram conceptually illustrating exemplary elements of a network optimization device;
FIG. 5 is a flow chart illustrating exemplary operations for building or maintaining a lookup table;
FIGS. 6 and 7 are diagrams conceptually illustrating certain of the operations shown in the flow chart of FIG. 5;
FIG. 8 is a diagram illustrating an exemplary implementation of the lookup table shown in FIG. 4; and
FIG. 9 is a flowchart illustrating exemplary operations for compressing data over a wide area network.



DETAILED DESCRIPTION
The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.
As described herein, a network optimization device may operate to increase application performance over a wide area network. The network optimization device may use disk-based compression to achieve the performance increase. The disk-based compression may be performed using an efficient indexing scheme.
Exemplary System Overview
FIG. 1 is a diagram of an exemplary system 100. System 100 may include a wide area network (WAN) 170 and one or more private networks 180-A, 180-B, and 180-C (collectively referred to as private networks 180). Private networks 180 may be geographically dispersed and different ones of private networks 180 may wish to communicate with one another over WAN 170. Private networks 180 may each, for example, be a local area network (LAN) for a branch office associated with a corporation or other entity. As another example, private networks 180-A and 180-B may be LANs for a corporate branch office and private network 180-C may be a data center for the corporation.
WAN 170 may include a public network, such as the Internet. In some implementations, WAN 170 may be implemented by privately owned or leased data lines between private networks 180, or by a combination of a public network and privately owned or leased data lines. In general, data traffic between private networks 180 through WAN 170 may be characterized by one or more of increased cost, higher latency, or lower bandwidth than data traffic within a single corporate network 180. Accordingly, network applications accessing resources between private networks 180 and across WAN 170 may tend to run less optimally than an application running locally at a private network 180.
Private networks 180 may each include a number of computing devices, such as, for example, client computing stations 110, network security device(s) 115, servers 120, and databases 125. Client computing stations 110 may include computing devices of end-users, such as desktop computers or laptops. Network security devices 115 may include, for example, firewalls or other devices relating to network security. Servers 120 may include one or more devices designed to interact with and deliver information to other devices, such as client computing stations 110. Servers 120 may, for example, serve data files or network applications to computing stations 110 over WAN 170. Servers 120 may interact with databases 125 when providing information to client computing stations 110.
In the exemplary system shown in FIG. 1, private networks 180-A and 180-B may be branch offices that include a number of client computing stations 110 and private network 180-C may function as a data center that includes a number of servers 120, which may include file servers for private networks 180-A and 180-B. One of ordinary skill in the art will recognize that the number of private networks shown in FIG. 1 (three), the elements associated with each private network and/or the functionality of each private network is exemplary.
Private networks may be associated with network optimization devices (NODs) 150-A through 150-C (collectively referred to as network optimization devices 150). As shown in FIG. 1, for example, each of private networks 180-A through 180-C is associated with a corresponding network optimization device 150-A, 150-B, and 150-C, respectively. Network optimization devices 150 may generally operate to enhance the performance of applications running over WAN 170 between various ones of private networks 180. For example, assume that a user at one of client computing stations 110 at private network 180-A would like to retrieve a file from a file server at private network 180-C. In this situation, network optimization devices 150-A and 150-C may operate to decrease the perceived latency and/or increase the perceived bandwidth of WAN 170 by providing, for example, data compression and data caching services over WAN 170. Aspects of network optimization devices 150 as they relate to disk-based data compression will be particularly described in more detail herein.
Exemplary Device Architecture
FIG. 2 is a block diagram of an exemplary device 200, which may correspond to one or more of client computing stations 110, network security device 115, a server 120, a database 125, or a network optimization device 150. Device 200 may include bus 210, processor 220, main memory 230, read only memory (ROM) 240, storage device 250, input device 260, output device 270, and communication interface 280. Bus 210 may include a path that permits communication among the elements of the device.
Processor 220 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory 230 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 220. ROM 240 may include a ROM device or another type of static storage device that may store static information and instructions for use by processor 220. Storage device 250 may include a magnetic storage medium such as a hard disk drive.
Input device 260 may include a mechanism that permits an operator to input information to the device, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device 270 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 280 may include any transceiver-like mechanism that enables the device to communicate with other devices and/or systems.
Device 200 may perform certain operations, as described in detail below. The device may perform these operations in response to processor 220 executing software instructions contained in a computer-readable medium, such as memory 230. A computer-readable medium may be defined as a physical or logical memory device.
The software instructions may be read into memory 230 from another computer-readable medium, such as data storage device 250, or from another device via communication interface 280. The software instructions contained in memory 230 may cause processor 220 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, implementations consistent with the principles of the invention are not limited to any specific combination of hardware circuitry and software.
Disk-Based Compression
Before describing the operation of network optimization devices 150 in additional detail, it will be helpful to generally describe compression over a wide area network.
FIG. 3 is a diagram illustrating data compression over a WAN to improve perceived application performance over the WAN. The data may be, for example, file data being transferred to a remote server, such as a file being transferred by a client computing station 110 to a file server 120.
Assume that client computing station 110, in private network 180-A, would like to transfer a file or a portion of a file to file server 120, in private network 180-C. The file transfer is being made across WAN 170. Network optimization devices 150-A and 150-C may operate to increase the perceived performance of file transfers for client computing station 110 by, among other things, using data compression when transferring data over WAN 170.
One form of data compression is known as symbol or dictionary based compression. With this form of data compression, pairs of network optimization devices may store patterns of data, such as patterns from previously exchanged data, as symbols in memory or on a hard disk drive. Each symbol may be associated with an identifier, such as a location on the hard disk drive. Each symbol should ideally be much longer than the corresponding identifier. When a symbol is subsequently encountered, only the identifier is sent instead of the symbol.
As an example of the operation of data compression for transmitted data, assume that client computing station 110 initiates transmission of data to file server 120, shown as arrow 310 in FIG. 3. Network optimization device 150-A may examine the data to either store new symbols or look for previously stored symbols. If network optimization device 150-A locates a previously stored symbol that is also stored at network optimization device 150-C, network optimization device 150-A may transmit the identifier for the symbol instead of the symbol to network optimization device 150-C (shown as arrow 315). Network optimization device 150-C may receive the identifier and substitute the symbol corresponding to the identifier into the data stream before transmitting the data stream to file server 120 (shown as arrow 320). In this manner, the actual data sent over WAN 170 is compressed relative to the original stream sent by client computing station 110 to file server 120.
To efficiently implement a dictionary-based compression scheme, it is desirable to be able to efficiently identify data that was previously seen or sent. In general, incoming data may be indexed to thereby allow the network optimization devices to determine when a block of data can be sent as a reference to the block of data instead of sending the actual block of data.
One existing technique for creating an index for a dictionary-based compression scheme operates on a per-data unit (e.g., a packet in a TCP/IP network) basis. In this technique, when a packet Pi is received by the network optimization device 150, the data in the packet may be stored on a hard disk drive, and a “signature” (for example, a checksum) is calculated for the packet. The signature (Si), the disk location (Oi), and the length (Li) of the packet may then be entered into a lookup table that implements the index. The packet may also be sent to the corresponding network optimization device 150, which may also store the data on a hard disk drive.
Assume that after n packets (P1, P2, . . . , Pn) have been sent between the network optimization devices, the next packet Pn+1 received by the first network optimization device is the same as Pi, (l<=j<=n), which has been previously seen by the network optimization devices. After the first network optimization device calculates Sn+1, it may use the lookup table to discover that the signature has been seen before, i.e., it is the same as Sj. From the lookup table, the first network optimization device may obtain Oj and Lj, which indicate where on the disk the packet Pj was stored. Instead of sending the whole packet Pn+1 to the other network optimization device, the first network optimization device can simply send the offset Oj and length Lj. When the other network optimization device receives the offset and length, it may read the packet from its hard disk drive and send the packet to its destination.
One drawback with a packet-based scheme, such as that described above, is that the packetization of data transfer may not stay constant even when the same data is transferred repeatedly, i.e., the number and sizes of packets can be different every time. If the packetization changes, the stored data and the constructed lookup table may become useless for compression since all subsequent incoming packets will not match what has been seen previously.
Another existing technique for creating an index for a dictionary-based compression scheme operates on a stream basis in which packetization is ignored. In this technique, incoming data may be treated as a stream and written to disk continuously. A sliding “window” of a fixed length may be applied over the stream, and for each window, a hash function may be applied to obtain a signature. For example, using a sliding window of Ld bytes, a signature may be calculated for bytes 0 to (Ld−1), bytes 1 to Ld, bytes 2 to (Ld+1), etc. To reduce the number of signatures to a manageable level, the signatures may be further sampled such that only signatures that have certain characteristics are kept, for example. Each sampled signature may then be inserted into a one-dimensional lookup table by first converting the signature to an index value. The signature and the offset on the disk corresponding to the signature may then be stored in the lookup table at the index value. In other words, the lookup table is a one-dimensional array in which succeeding signatures having the same index value overwrite previous entries in the lookup table.
One drawback with the above-described streaming technique for creating the lookup table is that index collisions (i.e., different signatures mapping to the same index value) are inevitably frequent due to the large numbers of signatures produced. For example, if the sampling mechanism on average keeps 4 signatures per 1 KB of data, than 250 GB of data may result in 1 billion signatures. If each entry in the lookup table is 12 bytes, and the size of the whole table is 2 GB, then in the best case more than 85% of the signatures will collide with existing signatures already in the lookup table. One effect of the high index collision rate is that the chance of finding an existing match becomes increasingly smaller as more data are processed (and thus more signatures are entered into the lookup table, overwriting existing ones). The result is that the compression effectiveness of this stream-based solution decreases with the “age” of the data. In other words, the technique may achieve worse compression on data that are seen further in the past. Moreover, although increasing the lookup table size can alleviate this problem, it is difficult to predict for a given history size how large the table should be. The reason is that the index collision rate depends on the actual data pattern. Another effect of the high index collision rate is that the “false positive” rate may be quite high. In other words, since most of the signatures are lost due to index collision, most of the signatures found in the incoming data packets will correspond to lookup table entries that no longer contain the original signatures. Since detecting a false positive requires actually comparing bytes in the packet to bytes on the disk, the high false positive rate may cause many unnecessary disk reads and therefore significantly lower the performance of the scheme.
Stream-Based Indexing
As will be described below, network optimization devices 150 may use a stream based indexing technique to index data for a dictionary-based compression service. The stream-based indexing technique may ignore packetization of the data but still produce a scalable and memory-efficient index.
FIG. 4 is a diagram conceptually illustrating exemplary elements of one of network optimization devices 150. Network optimization device 150 may include compression component 420, decompression component 430, lookup table 435, and hard disk drive 440.
Compression component 420 and decompression component 430 may perform dictionary-based compression and decompression of data for entities transferring data through network optimization device 150. An entity, as used herein, may refer to any distinguishable unit that uses network optimization device 150, such as a computer, a process, or a group of computers/processes. Although shown as a single component in FIG. 4, it can be appreciated that each of compression component 420 and decompression component 430 may be implemented using one or more physical or logical elements. Alternatively, compression component 420 and decompression component 430 may be combined as a single component.
Hard disk drive 440 may be used by compression component 420 and decompression component 430 in implementing the compression services. In one implementation, hard drive 440 may be implemented as a single hard disk drive. In alternate implementations, hard disk drive 440 may be a logical drive implemented as an aggregation or cluster of multiple hard disk drives. Hard drive 440 may store, for example, the previously received (historical) data from local or remote entities.
Lookup table 435 may include an index of the historical data seen by compression component 420 and decompression component 430. Lookup table 435 may be stored in, for example, relatively high speed memory, such as volatile random access memory. In an alternative implementation, lookup table 435 may be stored in hard drive 440.
FIG. 5 is a flow chart illustrating exemplary operations for building or maintaining a lookup table by compression component 420 of network optimization device 150. Compression component 420 may receive data, such as packets, from entities local to compression component 420 (act 501). The data received may be treated and processed by compression component 420 as a sequential stream of data.
Compression component 420 may calculate a signature for each “window” of data in the input stream of data (act 502). The signatures may be calculated, for example, for each Ld-byte window in the input stream (act 502). The signatures may be calculated using a sliding window in which each version of the window “slides” by one byte. That is, a signature may be calculated for bytes 0 to (Ld−1), bytes 1 to Ld, bytes 2 to (Ld+1), etc.
FIGS. 6 and 7 are diagrams conceptually illustrating certain of the operations shown in FIG. 5. Four packets are illustrated in FIG. 6 as being part of a data stream: packets 601, 602, 603, and 604 (labeled as packets P0, P1, P2, and P3). For each packet, a number of sliding windows (“W”) 610, each of length Ld bytes, may be sampled. Each window may be offset from the next window by one byte. Sliding windows 610 may be thought of as a continuous stream of windows.
For each window 610, a signature for the window may be calculated. In one implementation, the signature is a fixed length signature of length Ls, where Ls is less than Ld. Stated more formally, each signature may be calculated using the function FS(D)=S, where D is a data chunk of Ld bytes and S is the resulting Ls-byte signature. For example, FS can be a hashing function that takes Ld bytes of input and produces an output of Ls bytes. In FIG. 6, a signature (“S”) 620 for each window is shown.
Compression component 420 may “sample” the signatures to obtain a reduced number of signatures (act 503). The signatures may be reduced in number using, for example, a predetermined filter function. As an example of such a function, compression component 420 may select only the signatures whose least significant k bits have a specific value. Probabilistically, this filter, on average, may reduce the number of signatures by a factor of 2k.
An example of a sampled set of signatures 620 is shown in FIG. 7. In this example, seven signatures 730 remain after being sampled in act 503. Assume that the filter function selected was that the two least significant bits of signatures 620 have the value zero (i.e., a probabilistic 25% sampling). Accordingly, in this example, signatures 730 would correspond to those of signatures 620 that have a value of zero for each of the two least significant bits.
A fixed number of the sampled signatures may be selected for each Ln bytes of data (act 504). In one implementation, one signature may be selected for each Ln bytes of data. Ln may be chosen as a value much larger than Ld. In the example of FIG. 7, one span of bytes is illustrated as including packets 601 and 602 and a second span of Ln bytes is illustrated as including packets 603 and 604. Although, in this example, the byte spans of data were illustrated as falling on packet boundaries, the Ln-byte spans are applied to the data stream and therefore may not necessarily correspond to packet boundaries. That is, a packet may be “divided” by two different Ln-byte spans.
As is further shown in FIG. 7, one signature is selected from each of the two Ln-byte spans, illustrated as signatures 740 and 745. Each of the signatures selected in act 504 may be stored in lookup table 435 by compression component 420 (act 505). In this example, signatures 740 and 745 may be stored in lookup table 435.
FIG. 8 is a diagram illustrating an exemplary implementation of lookup table 435. In this implementation, lookup table 435 may be a bucketed or full hash table. As illustrated, hash table 800 may be able to store up to Nh entries, indexed from 0 through Nh−1. A signature S that is to be entered into hash table 800 may be converted to an index value I using a conversion function, such as a suitably chosen hash function Fh(S) that takes an input signature value and generates an index value Tin the range 0 through Nh−1. Each element in hash table 800 may be thought of as a “bucket” that stores a linked list of entries. Multiple signatures that hash to the same bucket (i.e., index value) are all stored in the linked list.
In one implementation, each entry in hash table 800 may include the signature of the data and a value indicating where on the storage device the data corresponding to the signature is located. This value may be, for example, an offset pointing to the corresponding data on disk drive 440.
As an example of building hash table 800, assume that a first signature, signature 810, hashes to index zero. This signature, along with its corresponding offset 815 is stored in hash table 800 at index zero. Assume that another, different signature 820 also hashes to index zero. A hash collision has occurred. Signature 820 and its corresponding offset 825 may also be stored at index zero by chaining signature 820 and offset 825 to signature 810 and offset 815 using a pointer. Different index values, at any particular time, may have a different number of stored signature/offset pairs. As shown in FIG. 8, for instance, index zero is shown as including two chained signature/offset pairs, index one is shown as including two chained signature/offset pairs, index two is shown as being empty, and index Nh−1 is shown as including three chained signature/offset pairs.
As discussed with respect to act 504, a fixed number of signatures for each Ln bytes may be stored in lookup table 435. The fixed number of signatures may be set at 1, for example. The specific signature to store may be determined based on predefined rules. As an example of such a set of rules, assume that compression component 420 calculates signatures S0, S1, . . . , Sj for an Ln-byte section of the input stream (acts 501-503). Which of these signatures to enter into lookup table 435 may be determined as follows:

    
    
        a. Find the smallest i (0<=i<=j) such that Si is not already in lookup table 435. If such an Si exists, enter Si into the lookup table.
        b. If all signatures S0, S1, . . . , Sj are already in lookup table 435, then enter S0 into lookup table 435, replacing the existing signature.
    
    


It can be appreciated that the above description for building lookup table 435 may be modified in a number of ways. For example, although sampling signatures in act 503 and selecting a fixed number of signatures in act 504 are described as two separate operations, it can be appreciated that these operations may be performed together as a single operation.
Compression component 420 may use lookup table 435 to compress data that is seen or received two or more times by compression component 420. FIG. 9 is a flowchart illustrating exemplary operations for compressing data. The operations of FIG. 9 may be performed by compression component 420 before sending the data to decompression component 430 of a corresponding network optimization device 150 on the opposite end of the WAN.
In the description that follows, assume that a particular packet, Pm, is received and that compression component 420 generates signatures S0, S1, . . . , Sp, for the packet in acts 501, 502, 503, and 504 (FIG. 5).
For each of signatures S0, S1, . . . , Sp, the corresponding index into lookup table 435 may be obtained (act 901). The index for each signature may be obtained using hashing function Fh(S). Compression component 420 may then lookup the obtained indexes in lookup table 435 (act 902). That is, compression component 420 may iterate through the signatures in the chain corresponding to the index of the signature and compare each signature in the chain from lookup table 435 to the corresponding signature until it obtains a match or reaches the end of the chain. For signatures that were determined to match (act 903, YES), the data corresponding to the signature on hard disk drive 440 (i.e., the Ld length window from hard drive 440) may be compared to the Ld-byte window of the input data to verify whether there is a match (act 904). When a match is detected (act 905, YES), compression component 420 may expand around the matching Ld-byte window to attempt to locate a larger matching chunk of data (act 906). For example, compression component 420 may determine that the entire length of input packet Pm matches.
If there were any matching chunks of data in packet Pm, compression component 420 may send these chunks of the packet to decompression component 430 of the other network optimization device 150 as the offset values that identify the beginning of the chunks on hard drive 440 and the lengths of the chunk (act 907). The other network optimization device of a pair of network optimization devices stores data from the first network optimization device to its local hard disk drive using the same techniques used by the first network optimization device. Accordingly, with respect to the stored historical data, the two network optimization devices have identical disk contents. Thus, because the disk contents on the pair of cooperating network optimization devices are identical, decompression component 430 will be able to convert the offset values and lengths to the corresponding chunks of data on the disk. For portions of packet Pm that were not matched in act 903 or 905, compression component 420 may send the original data (act 907).
Match expansion as performed in act 904 may not necessarily be limited to the boundaries of packet Pm. For example, if a signature match is expanded to the end of packet Pm, it may be likely that the sender is sending a data file that has been seen before. Therefore, when compression component 420 receives the next packet Pm+1, it may first try to continue the match after the end of packet Pm. For example, if the last byte of packet Pm matches the byte at disk offset Ok, then compression component 420 may first compare the data in packet Pm+1 with the data on hard drive 440 starting at Ok+1. If there is a match for the whole packet Pm+1, then the match can be expanded again into the next packet Pm+2, and so on. If they do not match, compression component 420 may attempt to perform the signature-based match.
The techniques discussed above for compressing and sending data over a WAN may provide a number of advantages relative to existing techniques. For example, by using a full hash table to implement lookup table 435 instead of a one dimensional array, index collisions may be eliminated. By eliminating index collisions, the age of the stored data and the chance of finding a match may be independent.
Further, because only a limited number of signatures (e.g., one signature) is generated for each Ln bytes written to disk drive 440, the size of lookup table 435 is limited to an upper bound based on the size of the history data that is stored and Ln. Accordingly, memory needed to store a particular lookup table can be easily determined and the size of the lookup table may be optimized for the available memory.
Since the techniques described above only replace signatures in lookup table 435 when data collisions occur, fewer signatures are lost than with the previous solutions. As a result, when a signature is found in lookup table 435, it is more likely that the corresponding offset actually corresponds to the correct data, i.e., the false positive rate of signature matches not corresponding to the underlying data can be greatly reduced.
CONCLUSION
A dictionary-based compression technique was described for optimizing the performance of WAN data transfer. The technique builds and uses an efficient index that is effective in locating matching historical data, which may be stored on high-capacity hard disk drives. The index can be relatively small, eliminates index collisions, and has a predictable maximum size for a given amount of stored data.
While a series of acts have been described with regard to FIGS. 5 and 9, the order of the acts may be varied in other implementations consistent with the invention. Moreover, non-dependent acts may be implemented in parallel.
It will also be apparent to one of ordinary skill in the art that aspects described herein may be implemented in many different forms of network topologies, software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects described herein is not intended to limit the scope of the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.
Further, certain portions of the invention may be implemented as “logic” or as a “component” that performs one or more functions. This logic or component may include hardware, such as an application specific integrated circuit or a field programmable gate array, software, or a combination of hardware and software.
No element, act, or instruction used in the description of the invention should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

## Claims

1. A system comprising:
a lookup table; and
a compression component to:
receive a stream of data;
generate a signature for each first fixed length portion of the stream of data;
select a signature from the generated signatures for each second fixed length portion of the stream of data, where the second fixed length portion is larger than the first fixed length portion; and
store the selected signature in the lookup table.

2. The system of claim 1, where, when selecting the signature, the compression component is further configured to:
compare the generated signatures to signatures already stored in the lookup table.

3. The system of claim 1, where the lookup table is a hash table and where the compression component is further configured to:
obtain an index for the selected signature using a hashing function; and
store each selected signature and an offset corresponding to the selected signature in the hash table at the obtained index.

4. The system of claim 3, where the compression component is further configured to:
chain a first signature and an offset corresponding to the first signature to a second signature and an offset corresponding to the second signature, by use of a pointer, when the first signature and the second signature have the same index.

5. The system of claim 1, where the compression component is further configured to:
generate a signature for each of a plurality of first fixed length overlapping portions of the stream of data.

6. The system of claim 5, where the overlapping portions are offset from one another by one byte.

7. A method, comprising:
generating a signature for each first fixed length portion of a data stream;
selecting a signature from the generated signatures for each second fixed length portion of the stream of data, where the second fixed length portion is larger than the first fixed length portion;
obtaining an index for the selected signature using a hashing function;
looking up the obtained index in a hash table;
determining if a stored signature that has the same index as the selected signature matches the selected signature;
determining if a stored block of data corresponding to the stored signature matches the block of data corresponding to the selected signature when the stored signature matches the selected signature; and
transmitting a reference to the block of data to a network device when the stored block of data matches the block of data.

8. The method of claim 7, further comprising:
transmitting the block of data to the network device when the stored signature does not match the selected signature.

9. The method of claim 7, further comprising:
expanding the block of data when the stored block of data matches the block of data; and
determining if the expanded block of data matches the stored block of data.

10. The method of claim 9, further comprising:
transmitting a reference to the expanded block of data to the network device when the expanded block of data matches the stored block of data; and
transmitting the reference to the block of data to the network device when the expanded block of data does not match the stored block of data.

11. The method of claim 9, where expanding the block of data includes expanding to a new packet when the expanding the block of data expands to the end of a packet.

12. The method of claim 7, where the reference to the block of data includes an offset value that identifies a beginning of the block of data on a hard drive and a length of the block of data.

13. A method, comprising:
receiving a stream of data;
storing the stream of data on one or more hard disk drives;
generating a signature for each first fixed length portion of the stream of data;
selecting a signature from the generated signatures for each second fixed length portion of the stream of data, where the second fixed length portion is larger than the first fixed length portion; and
storing the selected signature in a hash table.

14. The method of claim 13, further comprising:
using the hash table to determine when a subsequently received block of data in the stream of data is stored on the one or more hard disk drives; and
transmitting the reference to the subsequently received block of data in place of the actual subsequently received block of data.

15. The method of claim 14, where using the hash table includes:
comparing a signature generated for the subsequently received block of data to signatures already stored in the hash table.

16. The method of claim 13, further comprising:
obtaining an index for the selected signature using a hashing function; and
storing each selected signature and an offset corresponding to the selected signature in the hash table at the obtained index.

17. The method of claim 16, further comprising:
chaining a first signature and an offset corresponding to the first signature to a second signature and an offset corresponding to the second signature, by use of a pointer, when the first signature and the second signature have the same index.

18. The method of claim 13, further comprising:
generating a signature for each of a plurality of first fixed length overlapping portions of the stream of data.

19. The method of claim 18, where the overlapping portions are offset from one another by one byte.