The present invention relates to methods for transmitting data from a first device to a second device, and receiving data at a second device transmitted by the first device.

Computers are commonplace in modern society and are now used in a wide variety of different applications in business and leisure environments. It is well known that computers can be connected to a computer network so as to facilitate communication between computers. Computer networks take a wide variety of different forms, including local area networks operating within a single building and wide area networks which interconnect computers which are located in geographically dispersed locations. Many computers are now connected to the Internet, which is a very large multi-national network allowing communication between computers in different countries.

It is known that a server connected to a computer network may operate as a web server by storing a number of files in the Hypertext Markup Language (HTML) format referred to as web pages. Client computers can request particular files from the web server, thereby allowing a large number of computers to access information stored on the web server. The use of web servers in this way is particularly widespread on the Internet which allows a large number of users to access a large number of web pages provided by different web servers. Web servers are, however, also used in other computer network applications, for example on local area networks so as to provide a convenient mechanism for the sharing of information within an organisation in which the local area network is located.

Computer networks inevitably have limited bandwidth. That is, at any one time, a limited quantity of information can pass between computers connected to the computer network via the computer network. The limited bandwidth provided by a computer network may lead to a number of problems, in particular delays in providing requested data from one computer to another computer via the computer network. Such delays inhibit usability and are therefore undesirable and should, where possible, be avoided. In order to mitigate the problems caused by bandwidth limitations, various methods have been proposed to compress data prior to transmission. Such methods have enjoyed varying success.

i It is an object of some embodiments of the present invention to provide a method for transmitting data between devices connected to a computer network.

According to a first aspect of the present invention, there is provided a method for providing data from a first device to a second device. The method comprises determining whether initial data comprises predetermined data. If said initial data comprises said predetermined data, said initial data is modified by replacing said predetermined data with an identifier of said predetermined data, and the modified data is transmitted.

In this way, the first aspect of the invention allows data to be processed so as to replace predetermined data with an identifier associated with that predetermined data. Where the identifier of the predetermined data is of shorter length than the predetermined data itself, it can be seen that the method provided by the first aspect of the invention reduces the quantity of data that is provided from the first device to the second device.

The method may be carried out at the first device.

Determining whether said initial data comprises predetermined data may comprise determining whether said initial data comprises a data item stored in a dictionary storing a plurality of data items, each data item having an associated identifier. In such a case, replacing the predetermined data with an identifier may comprise replacing the data item in the initial data with the identifier of that data item stored in the dictionary.

A plurality of dictionaries may be stored, each dictionary being associated with one or more second devices. In such a case determining whether said initial data comprises predetermined data may comprise determining a second device to which the data is to be transmitted and determining whether said received data comprises a data item stored in a dictionary associated with the determined second device. Each of the plurality of dictionaries may correspond to a dictionary stored at the one or more associated second devices.

The method may further comprise identifying commonly occurring data in the initial data and updating one or more dictionaries based upon the commonly occurring data. Data representing an updated dictionary may be transmitted to the or each second device. For example, update data may be transmitted to the or each second device, the update data being usable to update a dictionary stored at the or each second device to generate the updated dictionary.

The initial data may comprise a plurality of initial data items. The initial data items may take the form of blocks of data values (e.g. blocks of bytes).

The dictionary may be created based upon said initial data items. For example, the dictionary may be created to include commonly occurring ones of said initial data items.

The dictionary may comprise an ordered list of data items. The initial data items may be processed by determining whether a particular one of said initial data items is included in said dictionary. If said particular one of said initial data items is included in said dictionary, said particular one of said initial data items may be moved forward in said ordered list (if said particular one of said initial data items is not already at the head of the list). If said particular one of said initial data items is not included in said dictionary, said particular one of said initial data items may be added to said dictionary at the tail of said ordered list. When said particular one of said initial data items is added to said dictionary, a data item previously at the tail of said ordered list may be deleted from said ordered list.

The use of a dictionary having the form of an ordered list in this way ensures that commonly occurring initial data items are positioned towards the head of the list, while least commonly occurring data items are positioned towards the tail of the list. Where the dictionary has a maximum size, and data items are deleted from the tail of list, it can be seen that data items selected for deletion are those which occur least frequently.

Each of the initial data items may have common size. For example, each of the initial data items may comprise an equal number of bytes. Each of said initial data items may be defined by a relative position in said initial data. That is, boundaries between items data items may be defined every N bytes to provide initial data items of size N bytes.

Each of said initial data items may be defined by processing data values within said initial data. Data values may be processed to determine whether a particular subset of sequentially arranged data values satisfy a predetermined criterion and a boundary between two initial data items may be defined based upon said determination.

The initial data may comprise one or more web pages.

The method may further comprise receiving a request for particular data, such that the initial data comprises a response to the received request. The request may comprise data usable to identify one of said plurality of dictionaries.

According to a second aspect of the present invention, there is provided a method for receiving data at a second device from a first device. The method comprises storing a dictionary at said second device, said dictionary comprising a plurality of data items; receiving data comprising an identifier; retrieving data from said dictionary based upon said identifier; and modifying the received data by replacing the identifier with the retrieved data.

In this way, data stored at a second device can be used to process data provided by the first device. This can allow the first device to include references to particular data in the provided data (rather than the particular data itself). This is particularly useful where the reference is of shorter length (i.e. of smaller size) than the particular data.

The data may be received in response to a request made by the second device to the first device. The request may comprise data identifying said dictionary to said first device.

The first device may store a dictionary corresponding to the dictionary stored at said second device.

Aspects of the invention can be implemented in any convenient way including by way of methods and apparatus. In particular, aspects of the invention can be implemented by appropriate computer programs and as such aspects of the invention provide such computer programs which can be carried on suitable carrier media (including tangible and non-tangible carrier media) as well as computers arranged to carry out processing in accordance with aspects of the invention. Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic illustration of a network of computers on which an embodiment of the invention is implemented;

Figure 2 is a schematic illustration of a conventional exchange between a web- browser and a web-server which carried out using the network of Figure 1;

Figure 3 is a schematic illustration of hardware components of one of the client computers of the network of Figure 1 ;

Figure 4 is a schematic illustration of software components provided on one of the client computers and one of the servers of the network of Figure 1 to implement an embodiment of the invention;

Figure 5 is a schematic illustration showing software components provided on one of the servers of the network of Figure 1 in further detail;

Figure 6 is a flowchart showing processing carried out by one of the client computers of the network of Figure 1 to request data from one of the servers of the network of Figure 1 ;

Figure 7 is an extract from an HTML request message;

Figure 8 is a flowchart showing processing carried out by one of the servers of the network of Figure 1 in response to receipt of a request message of the form shown in Figure 7;

Figure 9 is an extract from a dictionary stored by the server carrying out the processing of Figure 8;

Figure 10 is an extract from a web page to be processed by the server carrying out the processing of Figure 8;

Figure 11 is an extract from a web page after processing by the server carrying out the processing of Figure 8; Figure 12 is a flowchart showing processing carried out by one of the client computers of the network of Figure 1 in response to receipt of data;

Figure 13 is a flow chart of processing carried out by a server to update a dictionary stored by a client computer;

Figure 14 is an example patch filed used to update a dictionary stored by a client computer;

Figure 15 is an extract from a dictionary stored by a client computer after updating by the processing of Figure 13.

Figure 16 is a schematic illustration of a first method for defining blocks in a data stream; and

Figure 17 is a schematic illustration of a second alternative method for defining blocks in a data stream.

Referring first to Figure 1 , there is illustrated a network of computers. Two servers 1 ,2 are connected to the Internet 3. Three client computers 4,5,6 are also connected to the Internet 3. The client computers comprise a laptop computer 4 and two desktop computer 5, 6. It will however be appreciated that the client computers 4,5,6 can take any convenient form and simply require a means for connection to the Internet 3. The client computers 4, 5, 6 can be provided with a connection to the Internet in any suitable way, for example by connection to a local area network (not shown) which provides access to the Internet via a suitable server.

The server 1 acts as a web server and provides web pages to the client computers 4, 5, 6. In the following description, reference is made to communication between the client computer 5 and the server 1 , but it will be appreciated that communication involving the other client computers 4, 6 is analogous. Indeed, it will be appreciated that each of the client computers 4, 5, 6 can request and receive web pages from the server 1.

Referring to Figure 2, a conventional exchange between the client computer 5 and the server 1 is described. More specifically the client computer 5 runs a web browser 7 which generates request messages 8 which are provided to the server 1. The request messages provided to the server 1 comprise data indicating a webpage requested by the server 1. A request message may comprise an indication of a specific complete webpage which is required or alternatively may comprise an indication of data that is to be formed into a webpage to be provided to the client computer 5. The server 1 stores a plurality of web pages 9 which can be provided to the client computer 5 on request.

The server 1 responds to a request message by generating a response 10 which is provided from the server 1 to the client computer 5 and more particularly to the web browser 7 running on the client computer 5. In this way, as is known, the client computer 5 is given a convenient mechanism for accessing data stored on the server 1 via the Internet 3 using the web browser 7.

Figure 3 shows hardware components of the client computer 5. The client computer 5 comprises a processor (CPU) 11 which is arranged to execute instructions. The client computer 5 further comprises volatile memory in the form of RAM 12 which stores both programs for execution by the CPU 11 and data for use by such programs. An I/O interface 13 provides for communication with peripheral devices such as input devices (e.g. a keyboard and mouse) and output devices (e.g. a display device such as a monitor). Non-volatile storage is provided in the form of a hard disc drive 14, and data and instructions are read from the hard disc drive 14 into the RAM 12 for use by the CPU 11. The client computer 5 further comprises a network interface 15 allowing data to be transmitted to and received from a computer network. The aforementioned components are connected together by means of a central communications bus 16 to which each of the components is connected.

Figure 4 is a schematic illustration showing software components provided on the client computer 5 and the server 1. It can be seen that as well as the webbrowser 7 the client computer 5 is provided with a plug-in 17 and a dictionary 18. The plug-in 17 operates as a component of the web browser 7 and its operation is described in further detail below. During operation, computer program code of both the web browser 7 and the plug-in 17 are stored in the RAM 11 of the client computer 5. The dictionary 18 is stored on the hard disc drive 14, although its contents may be copied to the RAM 11 for use. The server 1 stores web pages 9 as described above. Additionally, the server 1 stores a plurality of dictionaries 19, each dictionary being associated with one or more client computers with which the server 5 communicates. Web pages to be provided to the client computer 5 are processed by a compressor 20. More specifically, when a web page 9 is to be provided to the client computer 5 it is provided to the compressor 20, and based upon an identifier associated with the client computer 5 the compressor 20 selects one of the dictionaries 19. The selected dictionary contains the same data as is contained in the dictionary 18 stored by the client computer 5. The compressor 20 is arranged to process a received web page with reference to the selected dictionary, and identify within the received web page data items which are stored in the selected dictionary. When such a data item is identified in a received web page the identified data item is replaced with an identifier read from the selected dictionary, the identifier being of shorter length than the data item. In this way, the quantity of data transmitted from the server 1 to the client computer 5 to represent the webpage is reduced.

The plug-in 17 provided on the client computer 5 is arranged to read an identifier included within a received webpage and replace the identifier with the corresponding data item which is read from the dictionary 18. It will be appreciated that this requires that entries in the dictionary 18 match entries in the selected one of the dictionaries 19. Methods for ensuring consistency between the dictionary 18 and a corresponding one of the dictionaries 19 are described below.

The processing carried out by each of the client computer 5 and server 1 is described in further detail below. Figure 5 shows components of the server 1 in further detail.

It can be seen that the server 1 is provided with an intercept component 21 to which incoming requests are directed. Requests received by the intercept component 21 are directed either to the compressor 20 or a data retrieval component 22. The data retrieval component 22 is arranged to receive a request for a particular webpage or particular data and generate a response to that request. Requests may be received by the data retrieval component 22 either from the intercept component 21 or from the compressor 20. Where a request is received from the intercept component 21 , a response is provided directly to the client originating the request. Where a request is received from the compressor 20, the response is provided to the compressor 20. A monitor component 23 is arranged to monitor data included in responses provided from the data retrieval component 22 to the compressor 20 and to identify commonly occurring data sequences for the purposes of updating dictionaries as is described in further detail below. As described above, the compressor 20 is arranged to process responses generated by the data retrieval component 22 with reference to an appropriate one of the plurality of dictionaries 19 as is described in further detail below.

Processing carried out by the components shown in Figures 4 and 5 is described in further detail with reference to the flowcharts of Figures 6, 8 and 12.

Referring first to Figure 6, processing carried out by the client computer 5 in making a request to the server 1 is described. At step S1 a conventional hypertext transfer protocol (HTTP) request for a web page is generated. The request is processed by the plug-in 17, and at step S2 an identifier is added to the request, the identifier identifying the dictionary 18 to the server 1. At step S3, the plug-in 17 forwards the request to the server 1. Figure 9 shows part of an example HTTP request. It can be seen that the request comprises conventional HTTP request components together with a DBAM-DFID parameter 24 which is an identifier of the dictionary 18. The DBAM-DFID parameter 24 is added to the HTTP request by the plug-in 17.

Figure 8 shows processing of the request by the server 1. The request transmitted by the plug-in 17 (as shown in Figure 7) is received by the intercept component 21 of the server 1. The intercept component 21 first determines whether the request includes an identifier provided by the plug-in 17 at step S4. That is, the intercept component determines whether the request includes a DBAM-DFID parameter as shown in Figure 7. If this is not the case, the request can be processed in the same way as a conventional request from a web browser. As such, the request is forwarded to the data retrieval component 22 for normal processing at step S5, and the data retrieval component 22 provides a response to the request directly to the client computer 5.

If the check of step S4 determines that the request includes a DBAM-DFID parameter, processing passes to step S6 where the request is passed to the compressor 20. The compressor 20 requests data indicated in the request from the data retrieval component 22 at step S7. The requested data may comprise a specific webpage, or alternatively may indicate particular data to be included in a webpage. In either case, the data retrieval component 22 provides data to be provided to client computer 5 to the compressor 20 at step S8. At step S9 the compressor 20 identifies one of the dictionaries 19, the identification being based upon the DBAM-DFID parameter included in the request message received from the client computer 5. At step S10 the compressor 20 processes the data received from the data retrieval component 22 to determine whether the received data includes data items included in the identified one of the dictionaries 22. If this is the case, the identified data in the received data is replaced, at step S11 , with an identifier of that data which is of shorter length than the identified data. In this way, replacing the identified data with an identifier reduces the quantity of data which need be provided to the client computer 5 at step S12 to represent the data provided by the data retrieval component 22.

Figure 9 shows one of the dictionaries 19. It can be seen that the dictionary comprises a plurality of entries, each entry comprising an identifier 25 and an associated data item 26. Figure 10 shows a portion of a web page received by the compressor 20 from the data retrieval component 22. It can be seen that the portion of the webpage includes three data items 27, 28, 29 which are included in the dictionary of Figure 9, more specifically a first data item 27 in the webpage of Figure 10 corresponds to the data item having identifier 1689 in the dictionary, a second data item 28 in the webpage of Figure 10 corresponds to the data item having identifier 1687 in the dictionary and a third data item in the webpage of Figure 10 corresponds to the data item having identifier 1720 in the dictionary. The compressor 20 replaces each of the data items identified at step S10 with the corresponding identifiers at step S11 , to create the portion of the web page shown in Figure 11 which is provided to the client computer 5. It can be seen from the web page of Figure 11 that the first data item 27 has been replaced with a corresponding identifier 30, the second data item 28 has been replaced with a corresponding identifier 31 and the third data item 29 has been replaced with a corresponding identifier 32.

It can be seen from Figures 9 to 11 that the compressor reduces the quantity of data required to represent the webpage provided by the data retrieval component 22.

The processing of data received by the client computer 5 is now described with reference to Figure 12. At step S13 a response is received by the plug-in 17. The response includes the portion of the webpage shown in Figure 11 and described above. At step S14 a check is carried out to determine whether the received data includes identifiers added by the compressor 20. This check can be carried out in any convenient way. For example, data to which identifiers have been added by the compressor 20 may specify a particular MIME type (e.g. "application/x-appfast") and the determination at step S14 may therefore be based upon the MIME type of the received webpage. That is, if the MIME type is not that used by the compressor, the received data is processed in a conventional way at step S15 (that is, data is processed by a MIME handler which associated with its MIME type). Otherwise processing proceeds at step S16 as described below.

In the described case, as indicated above with reference to Figure 11 , the response does include the identifiers 30, 31 , 32 and as such the MIME type of the received web page is application/x-appfast. The webpage is therefore processed by the plugin 17 which acts as a MIME handler for the application/x-appfast MIME type.

At step S16 the identifiers included in the response are used as a basis for a look up in the dictionary 18 of the client computer 5, which contains the same entries as the dictionary shown in Figure 9. Data is retrieved from the dictionary 18 based upon the identifiers included in the response. Retrieved data is used to replace the identifiers included in the response so as to recreate the web page shown in Figure 10 at step S17. The reformed response can then be displayed in the usual way by the web browser 7.

It has been described above that webpages including identifiers which reference a dictionary can be identified by having a particular MIME type. Alternative methods for the identification of data including identifiers can be used. For example, all MIME handlers can be overridden and a check can then be made to determine whether the received data comprises a predetermined sequence of bytes. If the data does comprise a predetermined sequence of bytes, the data is passed to a decompressor, otherwise the data is processed as normal. Alternatively a socket interface may be overridden such that received data is processed to determine whether it includes identifiers before its MIME type is determined.

From the preceding description it can be seen that the plug-in 17 is arranged to embed an identifier (the DBAM-DFID parameter) in a request data packet, the identifier being usable to identify one of a plurality of dictionaries stored on the server 1. The compressor 20 provided on the server 1 is then arranged to interrogate the identified dictionary to determine whether a response includes data stored in the identified dictionary. Where this is the case the data stored in the dictionary is replaced in the response by an identifier which is usable by the client computer 5 in a look-up operation to obtain the relevant data from the data store on the client computer 5.

It will be appreciated that the method described above requires that the server 1 and client computer 5 carry out the processing described above with reference to the same dictionary. This is achieved by the server 1 providing the dictionary to the client computer 5. As described in further detail below, it is advantageous to update the contents of the dictionary associated with each client computer over time. Figure 13 is a flow chart showing processing carried out to provide a dictionary to a client computer and update the contents of the dictionary. At step S18 when a client computer requires a dictionary, the server obtains the dictionary at step S18 and provides the dictionary to the client computer at step S19. In use, the server periodically determines whether the dictionary should be updated at step S20 (using methods described below). If it is determined that no update is appropriate processing remains at step S20. When it is determined that an update is appropriate processing passes to step S21 where a 'patch' is created which can be used to update the dictionary stored on the client computer. The created patch is provided to the client computer at step S22. The created patch can either be provided together with a response which is provided to the client computer, or alternatively can be provided periodically or in response to a specific request from the client computer.

The patch file may be created by determining differences between a dictionary previously provided to the client and a dictionary currently held at the server. The differences can be used as a basis for creation of the patch file. Such differences can be determined by processing each of the dictionaries on a byte-by-byte basis to determine a checksum. When a difference in checksums is detected between the two processed dictionaries, it is determined that the dictionaries are themselves different and this is used as a basis for generation of the patch file.

Figure 14 shows an example 'patch' file. The 'patch' file shown in Figure 14 is arranged to replace the entry having identifier 1720 in the dictionary shown in Figure 9 with an entry having identifier 1722 which is associated with a data item:

<head><title>Hello</title></head> Applying the patch file of Figure 14 to the dictionary of Figure 9 generates the dictionary shown in Figure 15.

The patch file of Figure 14 specifies an offset at which the new data (associated with the identifier 1722) should be inserted into the patch file, thereby allowing effective specification of how the patch file should be applied to the dictionary. More specifically, <RP14333:387> within the patch file indicates that data within the patch file beginning at 14333 and having a length of 38 is to be replaced with the new data specified in the data file.

It has been explained that the patch file of Figure 14 replaces one dictionary entry with another. This is indicated by "RP" within the data file. It will be appreciated that in some cases a patch file may add an entry to the dictionary instead of replacing an existing entry, the addition being indicated by an appropriate command within the data file. The determination of whether to add an entry or replace an existing entry can be based upon a number of factors, including the current size of the dictionary, and whether the dictionary as a whole must not exceed a particular size given, for example, limitations on available storage space or restrictions on dictionary search time.

The server 1 is arranged to provide a common dictionary to all client computers arranged to access the server 1. However given that dictionaries of particular client computers may be updated at slightly different times, the server is arranged to monitor the data included in the dictionary of a particular client computer at a particular time, so as to ensure that the identifiers included in a response correspond to identifiers used in the dictionary of the respective client computer. This is achieved by uniquely identifying each dictionary using a DFID parameter. When a patch file is used to update a dictionary, the patch file specifies a new DFID parameter which is then associated with the dictionary used by the relevant client computer.

The server 1 , and more particularly the monitor component 23, is arranged to monitor the data provided by the data retrieval component 22 and identify commonly occurring data. This monitoring process is described in further detail below. Data which occurs commonly is to be included in the dictionary which is provided to the client computer 5, and newly identified commonly occurring data is therefore used as a basis for the creation of patch files. Similarly, the monitor component 23 identifies data which is no-longer commonly occurring, and such data is used to indicate data to be replaced in the patch files.

Processing carried out at the server to maintain and use the dictionaries 19 is now described in further detail.

Initially, each of the dictionaries 19 is empty. Web pages 9 received by the compressor 20 are processed in terms of blocks to identify blocks which should be added to a dictionary 19. Additionally, where a processed block corresponds to a data item already in the dictionary, the processed block is replaced by a identifier associated with the corresponding data item as has been described above.

The dictionary 19 is maintained by the monitor component 23. The dictionary 19 is implemented as an ordered list with most commonly occurring data items being positioned towards the head of the list, and least commonly occurring data items being positioned towards the tail of the list. When a block is processed which corresponds to a data item in the dictionary, that data item is moved forward one place in the list (unless the data item is already at the head of the list in which case it remains at the head of the list). When a block is processed which does not correspond to one of the data items in the dictionary, the block is added to the dictionary at the tail of the list, and the data item currently at the tail of the list is deleted from the dictionary. In this way it is ensured that most commonly occurring data items are positioned towards the head of the list. Deletion of data items from the tail of the list means that at any time the most commonly occurring data items are included in the dictionary, as least commonly occurring data items are deleted.

The preceding description has explained that web pages are processed by the compressor 20 in terms of blocks. Blocks can be defined in any convenient way. It will be appreciated that data items included in the dictionary have the same form as the blocks in which the web pages are processed, given that processed blocks are added to the dictionary as data items.

In some embodiments all blocks are of a predetermined size N. Typical sizes may be between 64 bytes and 2048 bytes although any suitable size may be used. In order to break a processed webpage into blocks, a first block is defined by the first N bytes of the webpage, a second block is defined by the N bytes following the first block and so on. It will be appreciated that in this way each byte is included in exactly one processed block. Such an approach is particularly beneficial where it is known that processed data comprises repeating byte sequences of a particular size which can be used to define blocks.

A variation to the approach described above involves defining a boundary B each N bytes, and defining a block of size N bytes starting at each boundary, thereby defining the blocks described above. However additionally, blocks are defined starting at the boundary B ± m bytes for all m ≤ n, where n<N. For example, in addition to defining a block starting at a boundary B a block is additionally defined starting at each byte (B-1) ... (B-n) and a block is also defined starting at each byte (B+1) (B+n).

It will be appreciated that defining additional blocks in this way is likely, at least in some circumstances, to increase the number of processed blocks which match a block already added to the dictionary, thereby increasing compression performance. The increase in compression performance is, however, achieved at the expense of more complex processing of a webpage. As such, it can be seen that a balance has to be struck between compression performance and processing complexity.

An alternative method for defining blocks within a processed web page is now described. A sliding window is moved across the processed webpage. For each position of the sliding window bytes within the sliding window are used to determine a hash value f. The hash value is processed with reference to an expected block size e, such that if the hash value f mod e = 0 (that is if the hash value f produces a remainder of 0 when divided by e) a block boundary is defined.

An example is shown in Figure 16. Here a data stream 33 is processed with reference to a sliding window of size 4 bytes to produce a plurality of values (f mod e) 34. Where the value (f mod e) is equal to 0, a block boundary is defined, denoted Bi B ₂ in Figure 16. In more detail, a sliding window of size 4 is applied to the data stream 33 to generate hash values f, each of which is processed with reference to an expected window size e of 8. A first four bytes 35 are processed to generate a hash value f which mod 8 has a value 1. As such no boundary is defined. A second four bytes 36 are processed to generate a hash value f which mod 8 has a value 5 and therefore, again, no boundary is defined. Four bytes 37 produce a hash value f which mod 8 has a value 0, causing the boundary Bi to be defined. Similarly, four byte values 38 produce a hash value f which mod 8 is also equal to 0, causing the boundary B ₂ to be defined. It will be appreciated that although the determination of particular values f has been described above, each sequential block of four byte values is processed in turn to generate a respective hash value f.

The hash function f can take any convenient form. In some embodiments the hash function is based upon Karp-Rabin algorithm and has the form set out in equation (1):

/, = ^ _+i y ⁿ - ⁾ + ^ _fl . _2j p ⁽ "- ²⁾ + ... + 6, (D

where: f, is the value of the hash function for an ith byte b,; n is the size of the sliding window; and p is some prime number.

Given a value for f, and value for f _l+1 can be computed using equation (2):

/^^ (f. - b^p^p + b^ (2)

Defining blocks with reference to a hash function as described above is beneficial in that a sequence of bytes producing a hash value which mod e is equal to 0 will produce such a value regardless of the offset of the sequence from the start of processed data. In this way, block boundaries are defined by the data sequence itself not by offset. Such a definition of blocks makes it more likely that matches between a data item in the dictionary and a processed block will occur.

The definition of blocks as described above may be modified to define blocks at a plurality of hierarchical levels as is now described with reference to Figure 17.

Referring to Figure 17, the data stream 33 is again shown. Again, a sliding window comprising four byte values is moved across the data stream 33 to compute hash values f. Each hash value is now considered mod a plurality of different values e _0, e _k-1 where each e _M is a multiple of e,.

Two blocks 39, 40 produce hash values f which are 0 mod e ₀ . As such, two first level boundaries B ⁰ _! and B° ₂ are defined. Two further blocks 41 , 42 produce hash values f which are 0 mod βi (but which are not 0 mod e ₀ ). Here, two second level boundaries B\ and B ¹ ₂ are defined.

Given that e ₀ is a multiple of βi it will be appreciated that a second level boundary is also defined by processing of each of the blocks 39, 40 .

In this way, a plurality of blocks are defined. In one embodiment blocks are created at six different hierarchical levels by processing hash values modulo e _{0, ,} e ₅ as follows:

e ₀ = 2048 e ₃ = 256 e _! = 1024 e ₄ = 128 e ₂ = 512 e ₅ = 64

These values of e can be used effectively where the hash function uses a sliding window of size 32 bytes. The processing described above can be carried out by computing a hash value for a particular position of the sliding window and determining whether the computed hash value mod e, is equal to 0. If this is the case, a boundary is defined, and the sliding window is moved to the next position in the data stream. Otherwise, it is determined whether the computed hash value hash e _J+1 is equal to 0 and so on.

Each of the e values indicates an expected block size. It can be seen that this is the case as, assuming that all hash values are generated equally frequently, it would be expected that a hash value mod e will be zero approximately every e bytes. That said, assuming a random distribution of hash values, it will be appreciated that block sizes will vary. As such, in some embodiments blocks are processed with reference to the dictionary if but only if they comprise a number of bytes which is between some predetermined minimum and maximum.

It will be appreciated that although various methods for the definition and processing of blocks have been described above, any suitable method can be used.

Although it has been described that the client computer 4, 5, 6 communicate with the servers 1 , 2 over the Internet 3, it will be appreciated that the clients computers 4, 5, 6 can communicate with the server 1 , 2 over any suitable network, such as, for example a local area network or wide area network. For example, one particular environment in which the methods described herein are useful is the use of web- based applications over a local or wide area network. In such environments a number of different web pages may include common components, and as such the methods described herein can be effectively used to avoid repeated transmission of the common components over the network. It will further be appreciated that the network over which the client computers 4, 5, 6 communicate with the servers 1 , 2 can be a wired or wireless network.

Although references have been made to webpages and the HTML format in the preceding description, it will be appreciated that the methods described above can be applied to any data stream. In particular, but without limitation the described techniques can be applied to image files (e.g. PNG, JPEG, GIFF etc) and document files (e.g. PDF).

Indeed, although embodiments of the invention have been described above, it will be appreciated that the described embodiments are illustrative not restrictive in character. Indeed, it will be appreciated that various modifications can be made to the described embodiments without departing from the spirit and scope of the present invention.