Efficient file-delivery technique

Abstract

To provide an efficient file delivery method and system.SOLUTION: In an environment 100, client computing devices 102(1) and 102(2) identify portions of a new version of an application that are new to the new version 112(3) and portions of the new version that are common to the new version and to a previous version of the application in such a way that the client computing devices efficiently update from the previous versions 112(1) and 112(2) to the new version.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT application claiming priority to U.S. Patent Application No. 16 / 874,234, entitled "EFFICIENT FILE-DELIVERY TECHNIQUES," filed May 14, 2020, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] As consumption of content items on electronic devices continues to increase, so too does the quantity of available content items. For example, the number of songs, movies, television programs, and games available for streaming or download has increased significantly in recent years. Some of these content items, such as video games and other applications, are regularly updated by their respective developers. Users of these games and other applications often want to download the latest versions of a particular game or application, but doing so can require significant time and network bandwidth. [Brief explanation of the drawings]

[0003] DETAILED DESCRIPTION OF THE INVENTION The detailed description is described with reference to the accompanying drawings. In each figure, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. Use of the same reference number in different figures indicates similar or identical components or features.

[0004] [Figure 1]1 is a diagram illustrating an exemplary environment including multiple client computing devices operated by respective users coupled to a remote computing system configured to provide games and other content items to the client computing devices. In some examples, the remote system receives a new version of a game or other application from a developer and, in response, identifies which parts of the new version are new, which parts were present in the previous version, and the location of each part in the new version. The remote system can then update the game or application on the client computing devices in a more efficient manner than simply sending the entire new version to those devices.

[0005] [Figure 2] 2 illustrates an exemplary scenario in which the portion generation component of the remote system of FIG. 1 generates N-byte sized portions of a first version of a file, and the portion identification component of the remote system generates data associated with each of these portions to identify the portions. The data may include a check value (e.g., a cyclic redundancy check (CRC) value), a hash value (e.g., a SHA-1 value), and / or the like.

[0006] [Figure 3]3 illustrates an exemplary scenario in which the matching portion component of the remote system of FIG. 1 analyzes a second version of a file to identify which portions of the second version were present in the first version and which portions are new to the second version. For example, the matching portion component may generate a CRC value for an N-byte-sized portion of the data to identify potential matching portions, and after finding a potential matching portion, may generate a hash value to confirm the match. If no match is found, the portion generation component may generate portions corresponding to the new data in the second version. The remote system may then generate update data including the new portions and a manifest containing recompilation instructions for generating the second version of the file using the new portions of the first and second versions.

[0007] [Figure 4] 4 illustrates an exemplary scenario in which a remote system utilizes a partial match component to identify, from a third version of a file, any N-byte-sized portion of the third version that was present in the first or second version of the file. Additionally, a dirty data identification component may be configured to identify "dirty data" from the skipped data (i.e., data for which the partial match component did not find a match) that meets one or more criteria, such as criteria indicating that the data may include a byte offset value that points to a location in the file. Additionally, the clean data identification component may identify "clean data" that does not meet the criteria, and in some examples may generate portions of clean data and data identifying the portions of clean data, similar to the illustration of FIG. 2.

[0008] [Figure 5A]5A illustrates a first scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5B] 5B illustrates a second scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5C] 5C illustrates a third scenario, which generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5D] 5D illustrates a fourth scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5E] 5E illustrates a fifth scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5F]5F illustrates a sixth scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5G] 5G illustrates a seventh scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file. [Figure 5H] 5H illustrates an eighth scenario that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data can then be stored. The identifying data can later be used to identify the same section of clean data in subsequent versions of the file.

[0009] [Figure 6A] 6A illustrates a first flow diagram of an exemplary process for generating a portion of clean data between two sections of data, including their respective byte offset values, and data identifying the clean data. Additionally, the data identifying the portion of clean data may be used to determine whether this portion of data was present in a previous version of the file. If not, the portion of clean data may be stored along with the data identifying this portion. [Figure 6B]6B illustrates a second flow diagram of an exemplary process for generating a portion of clean data between two sections of data, including their respective byte offset values, and data identifying the clean data. Additionally, the data identifying the portion of clean data may be used to determine whether this portion of data was present in a previous version of the file. If not, the portion of clean data may be stored along with the data identifying this portion.

[0010] [Figure 7] FIG. 7 illustrates a flow diagram of an exemplary process for identifying portions of data that meet one or more criteria and generating data that reside between each portion of data that meets the one or more criteria.

[0011] [Figure 8] 8 illustrates a flow diagram of an example process that includes a client computing device sending a request for an updated version of an application. The diagram also illustrates a remote system receiving the request and sending to the client computing device new portions of the new version of the application and a manifest that enables the client computing device to recompile the new version using the new portions of the new version and a previous version of the application already running on the client computing device. DETAILED DESCRIPTION OF THE INVENTION

[0012] Described herein are, among other things, techniques, devices, and systems for identifying the portions of a new version of an application that are new to the new version and the portions of the new version that are common to the new and previous versions of the application so that a client computing device may efficiently update from the previous version to the new version.

[0013] As noted above, the use of client computing devices continues to increase, as does the consumption of content items such as video games and other applications. In some instances, developers of applications such as games continue to add and modify the applications, resulting in new versions of the applications. For example, a game developer may release a first version of an application, then add content to the game and release a second version, a third version, and so on.

[0014] Often, game consumers desire to receive the latest version of a game, and therefore may send an update request for the latest version to a remote system hosting the application. However, rather than sending the entire new version of the application to a client computing device requesting the new version, the remote system may instead send only the new portions of the new version of the application, as well as a manifest file containing instructions for regenerating the new version of the application using the previous version of the application currently executed by the client computing device and the new portions of the application. These instructions may instruct the client computing device to delete some files, move some files, duplicate some files, and / or the like. As the reader will appreciate, sending the new portions of the new version of the application and the manifest, rather than the entire new version of the application, results in more efficient delivery of content to the client computing device. That is, the size of the package delivered to the client computing device may be significantly smaller than if the remote system sent the entire new version of the application, thus reducing the network bandwidth and time required for the client computing device to receive the package. Furthermore, given the relatively small recompilation time, the client computing device may run, and the end user may enjoy, the new version of the application more quickly than if the remote system sent the entire new version of the application to the client computing device.

[0015] However, to transmit the new portions and manifest file, the remote system may first analyze the new version of the application compared to the previous version of the application to identify the new portions. For example, the remote system may analyze the new version compared to the previous version to identify portions of the new version that match portions in the previous version. The remote system may consider portions of the new version that were not found to have matching portions in the previous version as new portions compared to the new version of the application. Additionally, this analysis by the remote system may result in the remote system identifying the respective locations in the new version of portions that are common to both the previous and new versions of the application. In addition to storing content associated with the new portions, the remote system may store this recompilation information. For example, if the remote system identifies that portion "A" resides at location "X" in the new version and at location "Y" in the previous version, the remote system may store as recompilation information an indication that portion "A" resides at location "X" in the new version of the application.

[0016] To perform this comparison, in some examples, the remote system utilizes one or more techniques for generating data that uniquely or relatively uniquely identifies each portion of the file. For example, the remote system may generate a cyclic redundancy check (CRC) value for each portion of the application version, a hash value for each portion of the application version, and / or the like to uniquely identify the portion. For example, the remote system may generate this data for each of multiple portions of a first version of the application, and upon receiving a second, updated version of the application, analyze the second version to determine whether these values ​​are present. If so, the remote system may determine that the corresponding portion is not new relative to the second version.

[0017] As an example, assume that an application developer provides (e.g., uploads) a first version of an application to a remote system. In response to receiving this first version, the remote system may begin by generating portions (or “chunks”) of the first version of the application and data identifying these portions. For example, the remote system may generate “N” sized portions (e.g., where N is a predefined number of bytes) starting from the beginning of the first version of the file. For example, the remote system may generate a first portion from the first “N” bytes of the first version of the file, a second portion from the second “N” bytes of the first version of the file, and so on. In some examples, the remote system may generate one megabyte (1 MB) sized portions, while in other examples, the remote system may use portions of any size.

[0018] In addition to generating each portion of the first version of the application, the remote system may generate data that uniquely or relatively uniquely identifies these portions. For example, the remote system may generate a CRC value for the first portion, a CRC value for the second portion, etc. The remote system may then store these CRC values ​​in association with the respective portions. Additionally, the remote system may generate a hash value for each respective portion, such as a hash value for the first portion, a hash value for the second portion, etc. These hash values ​​may also be stored in association with the respective portions.

[0019] Thereafter, when a client computing device requests to receive (e.g., download) the first version of the application, the remote system may transmit the entire version to the device, i.e., the remote system may transmit portions of the first version of the application to the client computing device.

[0020] However, the application developer may then create a second version of the application that may have commonality with the first version. For example, the second version of the application may include much of the same data as the first version, but may also include additional data, may omit some data from the first version, and / or the like.

[0021] Upon receiving the second version of the application, the remote system may attempt to determine the correspondence between the first and second versions. For example, the remote system may attempt to identify which portions of the second version are also present in the first version and the location of these intersections. The remaining data in the second version may include new data and may be stored as new portions, as described below. Thus, when a client computing device currently running the first version of the application requests the second version, the remote system may send the new portions of data along with a manifest file for building the second version on the client computing device using the new portions and the first version of the application.

[0022] To identify the common portion, the remote system may analyze an N-sized portion of the second version of the application, starting from the beginning of the second version. For example, the remote system may use the first N bytes of the second version of the file to generate data such as a CRC value and then compare this value to respective values ​​representing previously stored portions of the first version of the application. For example, the remote system may generate a CRC value for the first 1 MB portion of the second version of the application and compare this CRC value with the CRC values ​​of the first portion of the first version and the second portion of the second version, etc., until the remote system finds a match or there are no more CRC values ​​to compare. Upon identifying a match, in some examples, the remote system may generate additional data associated with the portion of the second version, such as a hash value (using a predefined hash function such as SHA-1) of the first 1 MB portion of the second version of the application. The remote system may then compare this first hash value with hash values ​​associated with the candidate portion of the first version of the application. That is, the remote system may compare the hash value of the portion of the second version of the application with the hash value of the portion of the first application that has a matching CRC value. If these hash values ​​match, the remote system may store an indication that this particular previously stored portion of the first version is present at the appropriate byte offset in the second version of the application (in this example, starting with the first byte of the second version).

[0023] However, if the CRC value of the first 1 MB portion of the second version does not match the CRC value of any previously stored portion, or if the hash value of the candidate portion does not match, the remote system may shift the window by a specific amount, such as one byte. The remote system may then analyze this new portion of the second version of the application (in this example, bytes 2 through 1,000,001) by computing its CRC value and comparing it with the CRC values ​​of each of the previously stored portions of the first version. Thus, the remote system may "walk through" the second version of the file using a sliding window of size N (e.g., 1 MB) moving one byte at a time. Upon identifying a matching portion, the remote system may store an indication of the starting byte offset value of the second version of the application and the previously stored portion. For example, if the remote system determines that the 1 MB window of the second version of the application starting at byte 10 represents a 1 MB portion "A" that formed part of the first version of the application, the remote system may store an indication that the second version of the application includes "portion A" at byte 10.

[0024] However, in some instances, the second version of the application file may include byte offset values ​​that point to locations within the file. That is, some files may utilize a distributed table of contents, with a portion located at the beginning of the file and additional portions located throughout the file. In some instances, these byte offset values ​​point to the location of particular assets within the file, such as the location of sounds or textures. As the reader will appreciate, the value of these byte offset values ​​may change as the location of the assets changes. Thus, while the sliding window technique described above is effective for finding N-sized portions between different versions of a file, even if the locations of these portions shift between versions, in files utilizing this type of distributed table of contents approach, the byte offset values ​​will change as the locations of the assets change, and therefore the sliding window will not identify the portion as being the same as a previously identified portion. In other words, if a byte offset value changes between versions, and this byte offset value is within an N-sized sliding window of data that the remote system is currently analyzing, then the change in this byte offset value (i.e., the location to which this table of contents structure points) will result in the analyzed portion having a unique CRC and / or hash value that the remote system has not yet seen, and therefore will result in the remote system failing to find a matching portion.

[0025] To mitigate the effects of this problem, the systems and techniques described herein may attempt to find these byte offset values ​​and, in doing so, identify a "clean" portion of data within two respective byte offset values. This section of clean data may then be stored as a portion, as well as data (e.g., a CRC value, a hash value, etc.) that uniquely identifies this clean portion of data. By doing so, a remote system may identify a matching clean portion of data from subsequent versions of the file, even if the byte offset values ​​surrounding this clean portion have changed between versions.

[0026] Continuing from the above example, assume that the remote system analyzed the first eight sliding windows (e.g., bytes 1 through 1,000,000, bytes 2 through 1,000,001, ..., bytes 8 through 1,000,007) of the second version of the application file without finding any matching portions from the first version of the application file. Given that the byte offset values ​​described above are eight bytes in size, the remote system may initiate techniques to identify potential byte offset values. To determine that an eight-byte window contains byte offset values ​​that may be marked as "dirty," the remote system may use one or more criteria. For example, the remote system may interpret the number represented by these eight bytes and determine whether the number is less than a threshold number, such as the size of the file. If the number is not less than the threshold (meaning, for example, that it may not point to the location of an asset within the file), the remote system may determine that the criterion is not met. Additionally, or alternatively, the remote system may also determine whether the number is greater than a second threshold number, such as 1 MB, to eliminate from consideration some eight-byte numbers that are likely not to represent byte offset values. In some examples, the criteria may also include the number being greater than the 8-byte window position, or greater than some predefined amount (e.g., 1 MB) less than the 8-byte window position. In yet other examples, the remote system may begin checking for byte offset values ​​(i.e., dirty data) after a predetermined position in the file, such as after the first 1 MB. Thus, one or more criteria may include whether the 8-byte window position is past this point. Of course, while this example describes an 8-byte window, it should be understood that other sized windows may be utilized in other examples.

[0027] If one or more criteria are not met, the remote system may attempt to identify byte offset values ​​to mark as dirty data by sliding an 8-byte window one byte at a time. For example, after checking for the byte offset value represented by bytes 1-8, the remote system may attempt to determine whether bytes 2-9 represent the byte offset value.

[0028] For example, assume that a remote system determines that an 8-byte window from bytes 200,000 through 200,007 represents byte offset values, i.e., "dirty" data. That is, the remote system may have determined that this 8-byte window meets one or more criteria, such as: occurring at a location within the file that is greater than a threshold; representing a number that is less than a first threshold number (e.g., the size of the file) but less than a second threshold number (e.g., 2 MB); representing a number that is less than the current position of the 8-byte window by an amount that is greater than 1 MB; and / or the like. It should also be understood that these bytes form part of "skipped data," in the sense that the 1 MB (or N-byte sized) sliding window did not identify any matches that included these bytes.

[0029] After identifying this potential byte offset value, the remote system may store a determination that the first portion of the second version of the file (corresponding to bytes 200,000 through 200,007) represents dirty data. The remote system may then define a second portion of the file that includes this first portion and at least one byte on either side of the first portion. That is, given that this first portion of the file represents a byte offset value, it is likely that adjacent bytes also contain data that may change between versions of the file. That is, the remote system may make the assumption that the byte offset value has a "blast radius" such that adjacent bytes are also "dirty" data in some instances; therefore, the second portion represents the first portion plus a blast radius on either side of the first portion, such as 256 bytes on either side of the first portion, although any other blast radius may be used, which may be the same before or after the first portion, or may be greater than or equal to the first portion. Thus, in this example, the second portion is between bytes 199,744 through 200,263, and the remote system may mark it as dirty data.

[0030] After marking this second portion as dirty data, the remote system may continue analyzing the skipped data behind a 1 MB sliding window (or other N-sized window) attempting to identify a matching portion. For example, an 8-byte sliding window may analyze an 8-byte window from 200,001 to 200,008 to determine if this window represents a byte offset value, then analyze 200,002 to 200,009, 200,003 to 200,010, etc.

[0031] Each window that does not meet the criteria for representing a byte offset value (i.e., for representing "dirty" data) may be considered "clean" data. In this example, assume that the remote system continues to analyze these 8-byte windows and marks a series of subsequent 8-byte windows as clean data. The remote system may be configured to determine when the amount of contiguous clean data is greater than a threshold amount, such as 100,000 bytes. In response to determining that a third portion of the file represents an amount of contiguous clean data greater than the threshold size, the remote system may generate a portion using skipped data prior to this third portion. For example, assume that the clean section extends from the end of the second portion at byte 200,008 and now reaches the 100,000-byte threshold (byte 300,007). Thus, the remote system may store a fourth portion of data preceding the third portion. This fourth portion may include at least the second portion (i.e., dirty data including the blast radius) and any skipped data preceding this second portion (back to the previously generated or matching portion). The remote system may therefore store this fourth portion of the data and may further generate data identifying this fourth portion, such as a CRC value, a hash value, and / or the like. The remote system may also store this identifying data in association with the fourth portion of the data when the user later attempts to identify the same data in a later version of the file. In this example, the fourth portion may have an end at the end of the second portion (bytes 200, 256) and a beginning at or before the beginning of the second portion (bytes 199, 744), depending on the beginning of the skipped data.

[0032] After generating the fourth portion of data and the data identifying the fourth portion, the remote system may continue analyzing the 8-byte window until it encounters another byte offset value. That is, the clean section of data may continue to expand until the remote system identifies an 8-byte window that meets the criteria described above. For example, assume that the remote system determines that an 8-byte window from 301,000 to 301,007 meets the criteria and therefore represents a byte offset value. Continuing with the nomenclature from above, the remote system may therefore determine that this fifth portion of data represents dirty data. Again, the remote system may define a sixth portion that includes the fifth portion and a blast radius around this fifth portion. Thus, the sixth portion may, in some examples, include bytes 299,744 and 300,263.

[0033] At this point, the remote system has therefore determined two portions of dirty data: a fourth portion (ending at byte 200,263) and a sixth portion (beginning at byte 299,744). The remote system may therefore store data associated with a seventh portion that lies between these two dirty sections of data, beginning at byte 200,264 and ending at byte 299,743. As the reader will appreciate, this seventh portion may include clean data. In addition to storing this byte range as a portion, the remote system may also generate and store data identifying this seventh portion of data, such as a CRC value, a hash value, etc.

[0034] It should be understood that after generating the seventh portion of the data and generating data identifying the seventh portion (e.g., CRC and hash values), the remote system may identify this portion in a later version of the file. For example, assume that a developer uploads a third version of a file at a later point in time and that the relevant portion of the third version is unchanged compared to the second version. The remote system may use the same analysis and, given that this portion of the data has not changed between versions, identify a portion of the data in the third version that has a CRC and hash value that matches the seventh portion of the data from the second version. Thus, for client computing devices to update from the second version to the third version, the remote system need not transmit the seventh portion, given that these devices already have this data. Instead, the remote system may store, in a manifest file associated with the update from version 2 to version 3, an indication of the offset value in the third version where the seventh portion resides.

[0035] In addition, as described above, it should be understood that if the conditions for generating a dirty data portion and a clean data portion between the dirty data are not met, the remote system may generate a data portion of a predefined size. For example, if the remote system analyzes a predefined portion of data, such as 1 MB of data, but the conditions for generating dirty and clean portions of data do not exist within that 1 MB of data, the remote system may generate the 1 MB portion and data identifying this portion, such as a CRC value and a hash value. Similarly, if the 1 MB portion is completely clean, the remote system may identify it as a 1 MB portion and data identifying this portion.

[0036] Specific implementations and embodiments of the present disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, various aspects may be embodied in many different forms and should not be construed as limited to the implementations shown herein. The present disclosure encompasses variations of the embodiments as described herein. Like numbers refer to like elements throughout.

[0037] 1 is a diagram illustrating an exemplary environment 100 including multiple client computing devices (e.g., 102(1) and 102(2), collectively "102") operated by respective users coupled to a remote computing system 104 configured to provide games and other content items to the client computing devices 102 over one or more networks 106. In some examples, the remote system receives a new version of a game or other application from an application developer's device 108 and, in response, identifies which parts of the new version are new and which parts were present in the previous version, as well as the location of each part in the new version. The remote system 104 can then update the game or application on the client computing devices 102 in a more efficient manner than simply sending the entire new version to these devices 102.

[0038] For example, Figure 1 illustrates that remote system 104 includes data store 110 that stores multiple versions of a particular application, which data store 110 may include a series of one or more files. For example, data store 110 may store various versions of a particular game or other type of application. In this example, data store 110 stores a first version 112(1) of the application, a second version 112(2) of the application, and a third version 112(3) of the application upon receiving the third version 112(3) from developer device 108. While Figure 1 illustrates various versions of one application, it should be understood that data store 110 may store any number of various versions of any number of other applications.

[0039] FIG. 1 further illustrates that, via data store 114, remote system 104 identifies and stores unique portions 116(1), ..., 116(M) (collectively "116") that make up these various versions (collectively "112") of an application. For example, upon receiving first version 112(1) of an application, remote system 104 may analyze this version to generate N-sized portions 116 of the first version and store these various portions in data store 114 (or 110). Additionally, remote system 104 may store portions 116 of different sizes (e.g., smaller than N sizes) as it receives and analyzes subsequent versions of the application, as described below. Furthermore, while FIG. 1 illustrates both data stores 110 and 114, it should be understood that in some examples, remote system 104 may store versions as portions rather than storing both portions 116 and the entire version 112.

[0040] 1 further illustrates that data storage 114 may store one or more portion identifiers 118(1),..., 118(M) (collectively "118"), each of which may correspond to a particular one of portions 116. For example, portion identifiers 118 may include any type of data that uniquely or relatively uniquely identifies one of portions 116. In one example, each of portion identifiers includes a CRC value and a hash value associated with one of the particular portions 116. These identifiers 118 may be used to later identify occurrences of the corresponding portion in subsequent versions.

[0041] 1 further illustrates that remote system 104 may include a data store 120 that may store recompilation data for reconstructing various versions 112 of an application. For example, data store 120 may store recompilation data 122(1) for recompiling a first version 112(1) of an application, recompilation data 122(2) for recompiling a first version 112(2) of an application, and recompilation data 122(3) for recompiling a first version 112(3) of an application (and receiving and analyzing a third version 112(3)). Each piece of recompilation data (collectively “122”) may include instructions for ordering the various portions 116 to generate the respective version 112 of the application. For example, the recompilation data may indicate that a particular version 112 of an application includes a first portion 116 associated with a portion identifier 118, followed by a second portion associated with a portion identifier 118, etc.

[0042] 1 illustrates that remote system 104 may include a data store 124 that stores one or more manifests for reconstructing a particular version if the client device already has a previous version stored. For example, data store 124 may include a first manifest 126(1) that enables a client computing device running first version 112(1) of an application to upgrade to second version 112(2), a second manifest 126(2) that enables a client computing device running first version 112(1) of an application to upgrade to third version 112(3) (after remote system 104 receives and analyzes third version 112(3)), and a third manifest 126(3) that enables a client computing device running first version 112(2) of an application to upgrade to third version 112(3) (after remote system 104 receives and analyzes third version 112(3)). While FIG. 1 illustrates a manifest including instructions for generating a particular version from a previous version, in other examples, each manifest may simply include instructions for generating a target version. Thus, data store 124 may store a first manifest for generating a first version of an application, a second manifest for generating a second version of the application, a third manifest for generating a third version of the application, and so on. In these examples, each manifest may indicate the parts that make up the version (e.g., as specified by hash values ​​and part sizes) and the respective positions within the version where each part resides. Thus, in some examples, a manifest may simply include respective recompilation data 122; thus, a system may include manifests in data store 124 but not recompilation data 122 in data store 120.Whether a manifest is associated with a single target version or indicates how to construct the target version from a specified version, each respective manifest file may contain instructions for generating the target version of the application using parts of the application already present on the client computing device and any new parts in the target version that are not present on the client computing device.

[0043] 1, for example, illustrates two different scenarios. First, a client device 102(1) running a first version 112(1) of an application requests that the application be updated, and a second client device 102(2) running a second version 112(2) also requests that the application be updated. In this example, remote system 104 has already received and analyzed third version 112(3). For example, and as described in further detail below, remote system 104 may compare third version 112(3) with first version 112(1) to identify portions (portion 146 in this example) that are new to the third version compared to first version 112(1), and generate manifest 126(2) that includes instructions for generating third version 112(3) using portions of the application that are common to the first and third versions (and thus already stored on client computing device 102(1)) and using new portion 146. Manifest 126(2) may instruct client device 102(1) to delete, add, move, and / or duplicate portions to generate third version 112(3) of the application on client computing device 102(1). As illustrated, in response to receiving a request to update first version 112(1) of the application on client computing device 102(1), remote system 104 may transmit portion 146 and manifest 126(2). In some examples, client computing device 102(1) may specify the current version it is running and the target version it wants to receive; in other examples, remote system 104 may update device 102(1) to the latest available version by default.

[0044] Further, remote system 104 may compare third version 112(3) with second version 112(2) to identify portions (in this example, portions 148) that are new to the third version relative to second version 112(2), and may generate manifest 126(3) that includes instructions for generating third version 112(3) using portions of the application that are common to the second and third versions (and thus already stored on client computing device 102(2)) and using new portions 148. Manifest 126(3) may instruct client device 102(2) to delete, add, move, and / or duplicate portions to generate third version 112(3) of the application on client computing device 102(2). As illustrated, in response to receiving a request to update second version 112(2) of the application on client computing device 102(2), remote system 104 may transmit portions 148 and manifest 126(3). As the reader will appreciate, by transmitting only the new portions 146 or 148 and manifest file 126(1) or 126(2), rather than the entire third version 112(3), remote system 104 and computing devices 102(1) and 102(2) can accurately and efficiently update the application. For example, the amount of data transmitted to these devices may be significantly less than if the entire version 112(3) were transmitted, thereby reducing the required network bandwidth and the time it takes for device 102(1) or 102(2) to update the application. Furthermore, while FIG. 1 and other discussions herein describe transmitting the new portions directly to the client computing device, it should be understood that in some examples, transmitting these new portions may include transmitting instructions to the client computing device to fetch the new portions, which then fetch the individual portions.For example, the system may send each URL for fetching a new portion to a client computing device, and the client computing device may send each request for a new portion to the received URL.

[0045] To update client computing device 102 in this manner, the remote system may include one or more processors 128 (e.g., central processing units (CPUs)) and memory 130. Memory 130 may include computer-readable medium 118 and components stored thereon for executing the techniques described herein. Memory 130 may include volatile and non-volatile memory, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store desired information and that can be accessed by a computing device. Memory 130 may be implemented as a computer-readable storage medium (“CRSM”), which may be any available physical medium accessible by processor 128 to execute instructions stored in memory 130. In one basic implementation, CRSM may include random access memory (“RAM”) and flash memory. In other implementations, CRSM may include, without limitation, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that can be used to store desired information that can be accessed by processor 128.

[0046] As illustrated, memory 130 may store a portion generation component 132, a portion identification (ID) component 134, a match portion component 136, a dirty data identification component 138, and a clean data identification component 140. The portion generation component 132 may be configured to generate portions of a file when a new file is received. For example, upon receiving a first version of application 112(1), the portion generation component may “walk through” the data to generate a series of N-byte-sized portions (or “chunks”) of data, which may be stored in data store 114 as portions 116. In addition, the portion identification component 134 may generate data to identify each portion, such as a CRC and a hash value, which may be stored in data store 114 as portion ID 118. In addition, upon receiving a second (or subsequent) version 112(2) of the application, the portion generation component may generate portions of data that are smaller than N bytes in size. For example, and as described in more detail below, portion generation component 132 may generate portions of "dirty" data and portions of "clean" data, which may be stored in data store 114 as portions 116. Again, portion identification component 134 may generate data to identify each portion, such as CRCs and hash values, which may be stored in data store 114 as portion IDs 118.

[0047] Meanwhile, matching portion component 136 may attempt to identify portions of the new version of the application (e.g., third version 112(3) in this example) that match portions of the previous version of the application (e.g., first version 112(1) or second version 112(2)). Upon identifying a matching portion, matching portion component 136 may store an index of the portion's identifier 118 and the offset value at which the identified portion appears in the new version. This information may be stored in the appropriate manifest 126 in data store 124.

[0048] In some examples, the match portion component “walks through” a new version of the application (e.g., third version 112(3)) starting at the beginning of the version, analyzing an N-sized window of data to determine whether it matches a previously stored portion. For example, match portion component 136 may generate a CRC value of the first N bytes of the new version of the application and compare this CRC value to a CRC value associated with a previously stored portion 116 (e.g., stored as portion ID 118). If a match is encountered with a particular portion, match portion component 136 may compare the hash value of this portion with the hash value of the particular portion (e.g., again stored as portion ID 118) that has the matching CRC value. If no CRC value match is found, or if the hash values ​​do not match, match portion component 136 may move the window forward one byte and perform the analysis again. Data behind the sliding window that is not present in the portion identified as matching the previous portion may be considered “skipped data.” In some examples, if N bytes are skipped in a contiguous manner (e.g., because no match was found using N sliding windows for these N bytes), portion generation component 132 may generate a portion from this skipped data and store it as portion 116. Again, portion ID component may generate a portion ID (e.g., a CRC and hash value) for this portion and store these as portion ID 118.

[0049] In some examples, dirty data identification component 138 and clean data identification component 140 may operate on the skipped data to identify dirty data and clean data, respectively, and these sections may be stored as portions 116. For example, dirty data identification component 138 may identify data from the skipped data that meets one or more criteria 142. In some examples, criteria 142 may include data representing byte offset values ​​that essentially comprise a table of contents structure that points to locations within a file. Thus, criteria 142 may include data that appear at locations within a file greater than a threshold location (e.g., after a particular offset) and represent numbers less than a threshold number (considering that a number greater than a possible location within a file means that the data is not a byte offset value that points to a location within a file).

[0050] In an example where the dirty data identification component 138 attempts to identify a byte offset value, the component 138 may analyze an 8-byte section of data, considering that 8 bytes is a typical length for a byte offset value. Of course, in other examples, the dirty data identification component 138 may analyze a window of any other length. In this example, upon identifying an 8-byte window that is likely to contain the byte offset value, the dirty data identification component 138 may mark the 8-byte window as dirty data. Additionally, the dirty data identification component 138 may define a "blast radius" around this 8-byte section, such as 256 bytes before and after the window. Again, the dirty data identification component 138 may mark this section of data as dirty data. For example, the dirty data identification component 138 may mark this 520-byte (256 + 8 + 256) window as dirty data.

[0051] The dirty data identification component 138 may continue analyzing the skipped data to determine whether a subsequent 8-byte window represents a byte offset value, and therefore dirty data. Meanwhile, the clean data identification component 140 may determine that skipped data not flagged as dirty by the dirty data identification component 138 represents clean data. The clean data identification component 140 may mark this data as clean. In some examples, in response to identifying a contiguous section of clean data larger than the threshold size 144, the clean data identification component may instruct the portion generation component 132 to generate a portion of data beginning at the end of the blast radius of the preceding dirty data back N bytes or the location of the previously identified or generated portion, whichever is smaller. As with the generation of other portions, the portion ID component 134 may generate a portion ID 118 for this section and store it in the data storage 114. Furthermore, in some examples, the matching portion component 136 may be configured to determine whether these portion IDs match any previously stored portion IDs 118.

[0052] After generating this portion of dirty data, the clean data identification component 140 may continue to mark subsequently analyzed skipped data as "clean" until the dirty data identification component 138 identifies a byte offset value, and therefore dirty data. After the dirty data identification component 138 identifies this 8-byte window of dirty data, the dirty data identification component 138 may again define a blast radius around this 8-byte window. After the dirty data identification component 138 does so, the clean data identification component 140 may instruct the portion generation component 132 to generate a portion of the clean data starting at the end of the blast radius of the previous dirty data and ending one byte before the start of the blast radius of the newly identified dirty data. The portion generation component 132 may store this in the data store 114 as portions 116, while the portion identification component 134 may generate portion IDs for these clean portions and store them in the data store 114 as portion IDs 118. In some examples, match portion component 136 may compare the portion ID with previously stored portion IDs to determine whether this clean data has been seen and stored before portion generation component 132 generates a clean portion. If so, rather than regenerating the portion, match portion component 136 may store an index of the previously stored portion and the current offset value in the appropriate manifest.

[0053] It should be noted that client device 102 may be implemented as any suitable type of computing device configured to run applications such as video games, productivity applications, and / or the like. Client device 102 may include, but is not limited to, a personal computer (PC), a desktop computer, a laptop computer, a mobile phone (e.g., a smartphone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., a virtual reality (VR) headset, an augmented reality (AR) headset, smart glasses, etc.), an in-vehicle (e.g., in-car) computer, a television (smart television), a set-top box (STB), a game console, a music player, a voice-controlled assistant, and / or any similar computing device. Client device 102 may communicate with remote computing system 104 through a computer network 106. Computer network 106 may represent and / or include, but is not limited to, the Internet, other types of data and / or voice networks, wired infrastructure (e.g., coaxial cable, fiber optic cable, etc.), wireless infrastructure (e.g., radio frequency (RF), cellular, satellite, etc.), and / or other connection technologies. Computing system 104, in some examples, may be part of a network-accessible computing platform that is maintained and accessible via computer network 106. Such network-accessible computing platforms may be referred to using terms such as "on-demand computing," "software as a service (SaaS)," "platform computing," "network-accessible platform," "cloud services," and "data center."

[0054] In some embodiments, the remote computing system 104 functions as or accesses a video game platform that implements a video game service for distributing (e.g., downloading, streaming, etc.) video games (or any other type of content item) to client devices, such as the client device 102. In one example, each client device may have a client application installed thereon. The installed client application may be a video game client (e.g., game software for playing a video game). A client device 102 with an installed client application may be configured to download, stream, or otherwise receive programs (e.g., video games and their content) from the remote computing system 104 over the computer network 106. To this end, any type of content distribution model may be utilized, such as a direct purchase model in which programs (e.g., video games) are individually purchased for download and execution on the client device 102, a subscription-based model, or a content distribution model in which programs are rented or leased for a certain period of time, streamed, or otherwise made available to the client device. Accordingly, each client device 102 may include one or more installed video games that can be executed by loading a client application.

[0055] Client devices 102 may be used to register with and subsequently log into a video game service. Users may create user accounts for this purpose and designate / set authentication information (e.g., passwords, PINs, biometric IDs, etc.) associated with their registered user accounts. As users interact with the video game platform (e.g., by accessing user / player profiles in their registered user accounts, playing video games on their respective client devices, etc.), the client devices transmit data to the remote computing system 104. For a given client device 102, the data transmitted to the remote computing system 104 may include, but is not limited to, user input data, video game data (e.g., the current version being run, game performance statistics uploaded to the remote system, etc.), social network messages and related activity, and identifiers (IDs) of video games being played on the client device 108. This data may be streamed in real time (or substantially real time), transmitted to the remote system 104 at defined intervals, and / or uploaded in response to events (e.g., finishing a video game).

[0056] 2 illustrates an example scenario 200 in which the portion generation component 132 generates N-byte sized portions of a first version 112(1) of a file, and the portion identification component 134 generates data associated with each of these portions to identify the portions. This data may include check values ​​(e.g., cyclic redundancy check (CRC) values), hash values ​​(e.g., SHA-1 values), and / or the like.

[0057] As illustrated, upon receiving first version 112(1) of a file, portion generation component 132 may start from the beginning of first version 112(1) and walk through first version 112(1). The portion generation component may generate N byte portions (e.g., 1 MB portions) and store these portions in data store 114. For example, portion generation component 132 may generate and store data corresponding to first portion 116(1), second portion 116(3), third portion 116(3), etc.

[0058] Portion identification component 134, in turn, may generate one or more portion IDs associated with each of these portions. For example, portion identification component 134 may generate one or more portion IDs 118(1) for first portion 116(1), one or more portion IDs 118(2) for second portion 116(2), one or more portion IDs 118(3) for third portion 116(3), etc. In some examples, these portion IDs 118 include a CRC value and a hash value for each portion.

[0059] On the other hand, in some instances, the techniques described below may be equally applicable to the capture of a first version of an application. For example, a look-ahead sliding window may be used to determine whether an N-byte-sized portion of data in the first version matches a previously seen N-byte-sized portion. Naturally, given that the data store is initially empty, no matches will initially be found to begin analysis of this first version of the file. Instead, upon generating the first portion, the first portion may be stored in the data store, along with identifying information associated with this portion, such as a CRC value and / or a hash value. However, once the data store is filled with this type of information, that information may be used to identify subsequent portions of the first version of the file. That is, given that some portions may be repeated within the first version of the file, these portions may be stored initially and later recognized as matching portions during analysis.

[0060] Additionally, while Figure 3 illustrates generating N-byte sized portions of data, in some instances, the techniques described below for generating dirty and / or clean portions of data may be equally applicable to capturing and analyzing a first version of an application. For example, rather than generating a full N-byte sized window as shown in Figure 2, in some instances, the remote system may generate smaller portions of a first version of a file similar to that illustrated in Figure 3.

[0061] 3 illustrates an example scenario 300 in which matching portion component 136 analyzes second version 112(2) of a file to identify which portions of second version 112(1) were present in the first version and which portions are new relative to second version 112(2). For example, matching portion component 136 may generate a CRC value for an N-byte-sized portion of the data to identify potential matching portions, and after finding a potential matching portion, may generate a hash value to confirm the match. If no match is found, portion generation component 132 may generate portions corresponding to the new data in the second version. Remote system 102 may then generate update data 302 that includes the new portions (e.g., portions 116(4) and 116(5)) and manifest file 126(1) that includes recompilation instructions for generating the second version of the file using the new portions of first version 112(1) and second version 112(2).

[0062] Matching portion component 136 may begin by analyzing the first N bytes of second version 112(2) to determine whether these N bytes match any N-byte portions previously stored as portions 116 in data store 114. For example, matching portion component 136 or portion ID component 134 may generate a first ID (e.g., a CRC value) of the first N bytes of the second version and compare it to the ID 118 (e.g., a CRC value) of each portion 116 stored in data store 114. If a match is found, matching portion component 136 or portion ID component 134 may generate a second ID (e.g., a hash value) of the first N bytes of the second version and compare it to the portion with the matching CRC value. If a match is found, matching portion component 136 will store an index in manifest file 126(1). However, in this example, no match is found, so the matching portion component slides the window by one byte and performs the analysis again.

[0063] As illustrated, B 0+K and B N+K Upon analyzing the N-byte window between B and B, match portion component 136 determines that this window corresponds to previously stored portion 116(1). That is, match portion component 136 generates a CRC value for this N-byte window and determines that it matches the CRC value associated with portion 116(1), generates a hash value for this window, and determines that this hash value also matches the hash value associated with portion 116(1). Thus, match portion component 136 determines that portion 116(1) corresponds to B 0+K manifest file 126(1) may store an indication that the file appears in second version 112(2) of the file beginning at

[0064] Additionally, after identifying this match, portion generation component 134 may generate portion 116(4) from the previously skipped data and store this portion 116(4) in data store. Further, portion identification component 134 may generate and store a corresponding portion ID in data store 114. Meanwhile, in some examples, dirty data identification component 138 and clean data identification component 140 operate on this skipped data, as described below with reference to FIG. 4.

[0065] FIG. 3 further illustrates that the matched portion component 136 determines whether portion 116(2) is B N+L and B 2N+L 3 illustrates that the application may identify that the data exists in the second version 112(2) of the file between the first and second versions 112(1) and 112(2). Accordingly, the match portion component 136 stores a corresponding indicator in the manifest file 126(1), while the portion generation component 132 generates a new portion 116(5) corresponding to the skipped data. As illustrated, the update 302 sent to devices updating from the first version 112(1) of the application to the second version 112(2) includes the new portions 116(4) and 116(5) and the manifest file 126(1) containing recompilation instructions that use the new portions and the first version 112(1) already stored on those devices.

[0066] 4 illustrates an example scenario 400 in which remote system 104 utilizes match portion component 136 to identify, from third version 112(3) of a file, any N-byte sized portion of third version 112(3) that was present in first version 112(1) or second version 112(2) of the file. Additionally, dirty data identification component 138 may be configured to identify “dirty data” from skipped data (i.e., data for which portion match component 136 did not find a match) that meets one or more criteria 142, such as criteria indicating that the data may include a byte offset value that points to a location in the file. Additionally, clean data identification component 140 may identify “clean data” that does not meet criteria 142 and, in some instances, may generate data identifying the clean data portion along with the clean data portion, similar to the illustration in FIG. 2.

[0067] 4 illustrates that match portion component 136 is currently analyzing an N-sized window 402 of data in application third version 112(3). Meanwhile, dirty data identification component 138 and clean data identification component 140 may analyze skipped data that is "behind" the window currently being analyzed by match portion component 136. In this illustrated example, dirty data identification component 138 first identifies a first section of dirty data 404(1) and a second section of dirty data 404(2). Clean data identification 140 then identifies a section of clean data 406 that exists between these two sections of dirty data.

[0068] 5A-5H collectively illustrate a scenario 500 that generates a portion of clean data between two sections of dirty data and data identifying the clean data. This portion of clean data and its identifying data may then be stored. The identifying data may later be used to identify the same section of clean data in subsequent versions of the file.

[0069] 5A begins illustrating this scenario, which includes determining, at "1," that a first portion 502 of the third version 112(3) meets one or more criteria for being labeled as dirty data. For example, the dirty data identification component 138 may determine that this 8-byte data section corresponds to a byte offset value that points to a location within the file if it meets the criteria 142 described above.

[0070] 5B continues this illustration, at "2," including defining a second portion 504 of the third version 112(3) that includes the first portion 502, at least one byte before the first portion, and at least one byte after the first portion. For example, the dirty data identification component 138 may define the second portion 504 to include the detected byte offset value and a surrounding blast radius.

[0071] 5C continues the illustration of the scenario, at "3," including determining that a third portion 506 of a third version 112(3), which follows the second portion 504, does not include and meet criteria 142. For example, clean data identification component 140 may determine that this third portion of data does not include a byte offset value that points to a location in the file.

[0072] 5D continues this illustration, at "4," including determining that the third portion 506 now exceeds the threshold size 508. That is, the clean data identification component 140 may determine that a section of clean data (e.g., data without a byte offset value) is larger than the threshold size 144 described above.

[0073] 5E continues the illustration of scenario 500, including, at "5," generating a fourth portion 510 of the third version 112(3) of the file at least in part in response to determining that the third portion 506 is larger than the threshold size 508. For example, the portion generation component 132 may generate the fourth portion 510, which may include the second portion 504 and one or more bytes preceding the second portion 504. Additionally, the portion ID component 134 may generate data identifying the fourth portion 510, such as a CRC value and a hash value for this portion 510.

[0074] FIG. 5F continues this illustration, including, at “6,” determining that a fifth portion 512 of the third version 112(3), which follows the third portion 506, satisfies one or more criteria 142 (e.g., includes a second byte offset value that points to a location in the first version of the file).

[0075] 5G continues the illustration of scenario 500, including, at "7," defining a sixth portion 514 of third version 112(3) that includes fifth portion 512 and at least one byte before and after fifth portion 512. For example, dirty data identification component 138 may define sixth portion 514 to include the detected byte offset value and a surrounding blast radius.

[0076] 5H concludes the illustration of scenario 500, which includes generating, at "8," a seventh portion 516 of third version 112(3) of file that resides between fourth portion 510 and sixth portion 514. For example, portion generation component 132 may generate and store seventh portion 516 in data store 114. Furthermore, portion identification component 134 may generate and store data identifying seventh portion 516 in data store 114, such as a CRC value and a hash value for this portion. In some examples, matching portion component 136 may attempt to identify a portion that corresponds to seventh portion 516 prior to operating at "8."

[0077] 6A-6B collectively illustrate a flow diagram of an exemplary process 600 for generating a portion of clean data between two sections of data, including respective byte offset values, and data identifying the clean data. Additionally, the data identifying the portion of clean data can be used to determine whether this portion of data existed in a previous version of the file. If not, the portion of clean data can be stored along with the data identifying this portion. This process, and each process described herein, is illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the software context, these blocks represent computer-executable instructions that, when executed by one or more processors, perform the referenced operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be limiting, and any number of the described blocks can be combined in any order and / or in parallel to implement a process. In some examples, computing system 104 may be configured to perform some or all of the operations, while in other examples, other devices may additionally or alternatively perform some or all of the operations.

[0078] Operation 602 represents determining that a first portion of a first version of a file includes a first byte offset value that points to a location in the first version of the file. For example, dirty data identification component 138 may determine that a first portion, such as an 8-byte section of data, meets one or more criteria for representing a byte offset value. As described above, this may include determining that the number indicated by the 8-byte value is less than a first threshold number (e.g., the size of the file) and greater than a second threshold number (e.g., 1 MB), occurs at a file location greater than the threshold location (e.g., 1 MB from the beginning of the file), and / or points to a location greater than the current location of the 8-byte window (or greater than a location less than a predetermined amount, such as 1 MB, from the current location). Of course, while several exemplary criteria are described, other criteria may be used.

[0079] Act 604 represents defining a second portion of the first version of the file, the second portion including the first portion, at least one byte before the first portion, and at least one byte after the first portion. In some examples, the dirty data identification component 138 may define a "blast radius" around the first portion. This blast radius may include, for example, 256 bytes on either or both sides of an 8-byte window. Thus, the second portion may include the first portion plus the blast radius.

[0080] Operation 606 represents determining that a third portion of the first version of the file that follows the second portion does not include a byte offset value that points to a location in the first version of the file. For example, dirty data identification component 138 may determine that this portion of data does not meet the criteria discussed above.

[0081] Operation 608 represents determining whether the third portion is larger than a threshold size. For example, the clean data identification component 140 may determine that the identified portion of clean data is larger than the threshold size 144. If not, the process 600 may return to operation 602.

[0082] However, if so, at operation 610, process 600 may include, at least in part, in response to determining that the third portion is larger than the threshold size, generating first data that identifies a fourth portion of the first version of the file that precedes the third portion, the fourth portion including at least the second portion. For example, portion identification component 134 may generate a CRC value, a hash value, and / or the like.

[0083] Operation 612 represents storing the fourth portion, and operation 614 represents storing the first data in association with the fourth portion. For example, portion generation component 132 may generate a portion of data corresponding to the fourth portion and store it in data store 114. Meanwhile, portion identification component 134 may store the first data as portion ID 116 in data store 114.

[0084] Operation 616 represents determining that a fifth portion of the first version of the file, following the third portion, includes a second byte offset value that points to a location in the first version of the file. For example, dirty data identification component 138 may determine that the fifth portion, such as an 8-byte section of data, meets one or more criteria for representing a byte offset value. Again, this may include determining that the number indicated by the 8-byte value is less than a first threshold number (e.g., the size of the file) and greater than a second threshold number (e.g., 1 MB), occurs at a file location greater than the threshold location (e.g., 1 MB from the beginning of the file), and / or points to a location greater than the current location of the 8-byte window (or greater than a location that is a predetermined amount less than the current location, such as 1 MB). Again, several example criteria are described, but other criteria may be used.

[0085] Act 618 represents defining a sixth portion of the first version of the file, including the fifth portion, at least one byte before the fifth portion, and at least one byte after the fifth portion. For example, dirty data identification component 138 may define a "blast radius" around the first portion. This blast radius may include, for example, 256 bytes on either or both sides of an 8-byte window. Thus, the sixth portion may include the fifth portion plus the blast radius.

[0086] 6B continues this illustration and includes, in operation 620, generating second data identifying a seventh portion of the first version of the file, the seventh portion being between the fourth and sixth portions. For example, portion identification component 134 may generate a CRC value, a hash value, and / or the like, of the seventh portion.

[0087] Operation 622 represents comparing the second data to third data representing the first portion of the second version of the file. For example, match portion component 136 may compare the CRC value of the seventh portion with the CRC value of the first portion of the second version of the file. If match portion component 136 determines that these values ​​match, match portion component 136 may compare the hash value of the seventh portion with the hash value of the first portion of the second version.

[0088] Operation 624 represents determining whether the second data and the third data match. In some examples, this may include determining whether both the CRC value and the hash value match. If not, process 600 proceeds to determine whether there is additional data (e.g., associated with other stored portions) to compare with the second data at operation 626. If so, process 600 may return to operation 622. For example, if the CRC values ​​do not match, match portion component 136 may determine whether the CRC values ​​match different portions of the second version, and if so, whether the hash values ​​of those portions match.

[0089] However, if there is no further additional data to compare the second data with, the operation may proceed to operation 628, which represents storing a seventh portion. For example, portion generation component 132 may generate a portion of data corresponding to the seventh portion and store it in data store 114. Meanwhile, operation 630 represents storing the second data (e.g., a CRC value and a hash value) in association with the seventh portion.

[0090] However, if the second data matches the third data, operation 632 represents storing an indicator in the manifest associated with the first version of the file indicating that the offset value associated with the beginning of the seventh portion corresponds to the third data associated with the first portion of the second version of the file. For example, the manifest may store an indicator of the hash value and size of the first portion of the second version that should reside at a particular offset, where the hash value and size serve to identify the portion.

[0091] FIG. 7 illustrates a flow diagram of an example process 700 for identifying portions of data that meet one or more criteria and generating data that reside between each portion of data that meets the one or more criteria.

[0092] Operation 702 represents determining that a first portion of a first version of a file meets one or more criteria. For example, this operation may include determining that the first portion of the first version of the file includes a byte offset value that points to a location in the first version of the file. Additionally or alternatively, this operation may include determining that the first portion of the first version of the file corresponds to a number less than a threshold number, appears at a location in the file greater than a threshold location, and / or the like. Further, in some examples, subsequent operations may further include defining a portion that includes the first portion and at least one byte before and after the first portion.

[0093] Operation 704 represents determining that a second portion of the first version of the file that follows the first portion does not satisfy one or more criteria. Operation 706 represents determining that a third portion of the first version of the file that follows the second portion satisfies one or more criteria. In some examples, the subsequent operations may further include defining a portion that includes the third portion and at least one byte before and after the third portion.

[0094] Operation 708 represents generating first data identifying the second portion. In some examples, this operation is performed at least in part in response to determining that the second portion is larger than a threshold size. Further, in response to determining that the second portion is larger than the threshold size, the operation may include generating a portion of data that is based at least in part on and includes at least the first portion of the data. Further, in some examples, generating the first data includes generating a check value (e.g., a CRC value) using the second portion and generating a hash value using the second portion.

[0095] Meanwhile, operation 710 represents comparing the first data to second data identifying a first portion of a second version of the file. In some examples, subsequent operations may include determining, based at least in part on this comparison, that the third portion corresponds to the first portion of the second version of the file, and storing, in a manifest associated with the first version of the file, an indication that an offset value associated with the beginning of the third portion corresponds to the second data associated with the first portion of the second version of the file. In some examples, for example, the first portion of the second version may be identified in the manifest by a hash value and a size of the first portion of the second version.

[0096] In some examples, process 700 is performed on data that is not determined to form part of a matching N-byte-sized window of data. Accordingly, operations of the process may further include generating second data associated with a fourth portion of the first version of the file prior to determining that the first portion of the first version of the file satisfies one or more criteria. Additionally, the process may include comparing the second data to respective data associated with each portion of the second version of the file and determining that the second data does not correspond to the respective data. In these examples, operations 702-710 may be performed at least in part in response to determining that the second data does not correspond to the respective data.

[0097] 8 illustrates a flow diagram of an example process 800 that includes a client computing device 102(1) sending a request for an updated version of an application. The diagram also illustrates a remote system 104 receiving the request and sending to the client computing device new portions of the new version of the application and a manifest to enable the client computing device to recompile the new version using the new portions of the new version and the previous version of the application already running on the client computing device.

[0098] At operation 802, the client computing device 102(1) sends a request to update from a first version of an application to a second version of the application. The client computing device 102(1) may send this in response to a request from a user or based on any other trigger. In some examples, the request is accompanied by information used by the remote system to determine the current version and / or desired version of the application being executed by the client computing device.

[0099] At operation 804, the remote system receives the request for the update and, at operation 806, determines one or more portions and an appropriate manifest to send to the client computing device 102(1). For example, the remote system may determine which portions are new for the new version as compared to the second version and obtain these new portions and an appropriate manifest for updating from the first version to the second version using the new portions and the first version of the application. As described above, the manifest may include operations for updating from the first version to the second version, or in other examples, may simply include recompilation instructions for the second version (regardless of which version the client computing device is currently running). Furthermore, in some examples, sending the new portions may include sending information (e.g., a URL) to enable the client computing device to obtain the new portions.

[0100] At operation 808, the remote system 104 sends the new portion and manifest (e.g., as update data such as update data 302) to the client computing device 102(1). The client computing device 102(1) may receive the new portion and manifest at operation 810 and use the received data to update the application from the first version to the second version at operation 812. The reader will appreciate that the time associated with process 800 from initiation of the update request to successful updating of the application may be significantly shorter than if the remote system sent and the client computing device installed the entire second version in response to the initial update request.

[0101] Although the present subject matter has been described in language specific to structural features, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the particular features described. Rather, the particular features are disclosed as example forms of implementing the claims.

Claims

1. 1. A method comprising: determining that a first portion of a first version of a file includes a first byte offset value that points to a location in the first version of the file; defining a second portion of the first version of the file including the first portion, at least one byte before the first portion, and at least one byte after the first portion; determining that a third portion of the first version of the file that follows the second portion does not contain a byte offset value that points to a location in the first version of the file; determining that the third portion is greater than a threshold size; generating, at least in part in response to determining that the third portion is larger than the threshold size, first data identifying a fourth portion of the first version of the file that precedes the third portion, the fourth portion including at least the second portion; determining that a fifth portion of the first version of the file following the third portion includes a second byte offset value that points to a location in the first version of the file; defining a sixth portion of the first version of the file including the fifth portion, at least one byte before the fifth portion, and at least one byte after the fifth portion; generating second data identifying a seventh portion of the first version of the file, the seventh portion being between the fourth portion and the sixth portion.

2. comparing the second data with third data representing a first portion of a second version of the file; determining that the second data corresponds to the third data; The method of claim 1 , further comprising: determining that the seventh portion corresponds to the first portion of the second version of the file.

3. 3. The method of claim 2, further comprising storing in a manifest associated with the first version of the file an indication that an offset value associated with the beginning of the seventh portion corresponds to the third data associated with the first portion of the second version of the file.

4. comparing the first data with third data representing a first portion of a second version of the file; determining that the first data corresponds to the third data; The method of claim 1 , further comprising: determining that the fourth portion corresponds to the first portion of the second version of the file.

5. 1. A system comprising: one or more processors; one or more computer-readable media storing computer-executable instructions that, when executed, cause the one or more processors to: determining that a first portion of a first version of a file satisfies one or more criteria; determining that a second portion of the first version of the file subsequent to the first portion does not satisfy the one or more criteria; determining that a third portion of the first version of the file subsequent to the second portion satisfies the one or more criteria; generating first data identifying the second portion; comparing the first data with second data identifying a first portion of a second version of the file.

6. 6. The system of claim 5, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file includes a byte offset value that points to a location in the first version of the file.

7. 6. The system of claim 5, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file corresponds to a number that is less than a threshold number.

8. 6. The system of claim 5, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file corresponds to a number that is less than a first threshold number and greater than a second threshold number.

9. The one or more computer-readable media further store computer-executable instructions that, when executed, cause the one or more processors to: performing acts including determining that the second portion is greater than a threshold size; 6. The system of claim 5, wherein generating the first data comprises generating the first data at least in part in response to determining that the second portion is larger than a threshold size.

10. The one or more computer-readable media further store computer-executable instructions that, when executed, cause the one or more processors to: determining that the second portion is greater than a threshold size; 6. The system of claim 5, further comprising: in response at least in part to determining that the second portion is larger than the threshold size, generating third data identifying a fourth portion of the first version of the file, the fourth portion preceding the second portion and including at least the first portion of the first version of the file.

11. The one or more computer-readable media further store computer-executable instructions that, when executed, cause the one or more processors to: defining a fourth portion of the first version of the file, the fourth portion including the first portion of the first version of the file and at least one byte following the first portion; defining a fifth portion of the first version of the file, the fifth portion including the third portion and at least one byte before the third portion; The system of claim 5 , wherein the second portion is between the fourth portion and the fifth portion.

12. The one or more computer-readable media further store computer-executable instructions that, when executed, cause the one or more processors to: determining, based at least in part on said comparing, that said third portion corresponds to said first portion of said second version of said file; 6. The system of claim 5, wherein the system causes the system to perform an act including storing in a manifest associated with the first version of the file an indication that an offset value associated with the beginning of the third portion corresponds to second data associated with the first portion of the second version of the file.

13. 6. The system of claim 5, wherein generating the first data includes generating a check value using the second portion and generating a hash value using the second portion.

14. The one or more computer-readable media further store computer-executable instructions that, when executed, cause the one or more processors to: generating second data associated with a fourth portion of the first version of the file prior to determining that the first portion of the first version of the file satisfies the one or more criteria; comparing the second data with respective data associated with respective portions of the second version of the file; determining that the second data does not correspond to the respective data; 6. The system of claim 5, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file satisfies the one or more criteria at least in part in response to determining that the second data does not correspond to the respective data.

15. 1. A method comprising: determining that a first portion of a first version of a file satisfies one or more criteria; determining that a second portion of the first version of the file subsequent to the first portion does not satisfy the one or more criteria; determining that a third portion of the first version of the file subsequent to the second portion satisfies the one or more criteria; generating first data identifying the second portion; comparing the first data with second data identifying a first portion of a second version of the file.

16. 16. The method of claim 15, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file includes a byte offset value that points to a location in the first version of the file.

17. 16. The method of claim 15, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file corresponds to a number that is less than a threshold number.

18. 16. The method of claim 15, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file corresponds to a number that is less than a first threshold number and greater than a second threshold number.

19. determining that the second portion is greater than a threshold size; 16. The method of claim 15, wherein generating the first data comprises generating the first data at least in part in response to determining that the second portion is greater than a threshold size.

20. determining that the second portion is greater than a threshold size; 16. The method of claim 15, further comprising: generating, at least in part in response to determining that the second portion is larger than the threshold size, third data identifying a fourth portion of the first version of the file, the fourth portion preceding the second portion and including at least the first portion of the first version of the file.

21. defining a fourth portion of the first version of the file, the fourth portion including the first portion of the first version of the file and at least one byte following the first portion; defining a fifth portion of the first version of the file, the fifth portion including the third portion and at least one byte prior to the third portion; The method of claim 15 , wherein the second portion is between the fourth portion and the fifth portion.

22. determining, based at least in part on said comparing, that the third portion corresponds to the first portion of the second version of the file; 16. The method of claim 15, further comprising: storing an indication in a manifest associated with the first version of the file indicating that an offset value associated with the beginning of the third portion corresponds to the second data associated with the first portion of the second version of the file.

23. generating second data associated with a fourth portion of the first version of the file before determining that the first portion of the first version of the file satisfies the one or more criteria; comparing the second data with respective data associated with respective portions of the second version of the file; determining that the second data does not correspond to the respective data; 16. The method of claim 15, wherein determining that the first portion of the first version of the file satisfies the one or more criteria comprises determining that the first portion of the first version of the file satisfies the one or more criteria at least in part in response to determining that the second data does not correspond to the respective data.

Images