Method and apparatus for synchronizing file data between computer systems
Through the exemplary synchronization protocol, the data transmission protocol is negotiated between different devices, and the compatibility problem of file synchronization between devices is solved, efficient file synchronization and data transmission is achieved, adapting to a variety of shape factors and topological structures.
Patent Information
- Application Number
- CN202110230957.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2016-04-01
- Filing Date
- 2016-08-09
- Publication Date
- 2025-01-07
- Estimated Expiration
- 2036-08-09
AI Technical Summary
Existing file synchronization technology is difficult to efficiently synchronize file data between different devices, especially due to compatibility issues caused by device shape factors and protocol differences, and the complex selection of data transmission protocols affects synchronization efficiency.
Using an exemplary synchronization protocol, through communication between the client and the server, a suitable data transmission protocol is negotiated and determined, a change batch response is generated to realize the synchronization of file data, supporting the docking of multiple data transmission protocols, separating file synchronization and Data transmission, adapt to different topological structures.
It realizes efficient file synchronization across devices, reduces the number of renegotiations, supports devices with multiple shape factors, improves synchronization delay time, saves computing resources, and adapts to multiple authentication solutions.
Smart Images

Figure CN113037826B_ABST
Abstract
Description
[0001] Related Applications
[0002] This application is a divisional application of the invention patent application with international application number PCT / US2016 / 046099, international application date August 9, 2016, entering the Chinese national stage on March 15, 2018, Chinese national application number 201680053821.9, and invention name “Operating system support for location cards”. Background Art
[0003] File synchronization can be used to synchronize files between machines / devices. There are many conventional mechanisms for synchronizing files. However, machines and devices have different form factors, capabilities, and locations, and not all mechanisms are compatible with all machines and devices. Nevertheless, users generally want their files to be available on any and all devices they use. Some conventional file synchronization solutions either implement synchronization protocols or file repository protocols (file lists, file downloads, file uploads) that can be used to implement file synchronization. In most cases, file synchronization operations are not separated from file data transfer operations. The present application is directed to a general technical environment for improved processing of file synchronization. Summary of the invention
[0004] The non-limiting examples of the present disclosure describe the implementation of an exemplary synchronization protocol for identifying file data for synchronization, and how to negotiate how to implement data transmission for synchronizing file data. A connection for a specific synchronization protocol can be established with a client device. The specific synchronization protocol interfaces with multiple data transmission protocols and can be used to identify file data to synchronize with the client device and determine one of multiple data transmission protocols to be used to download / upload specific file data. In one example, a request for synchronizing file data is received from a client device. As an example, the client device can be a protocol client, and the request can be received at a protocol server. The request may include: an identification generated by the request using a specific file synchronization protocol, knowledge metadata including a compact representation of the version status of the file data associated with the client device, and a request for a uniform resource identifier that the client device can use to download the file data for synchronization. A change batch response may be generated. The change batch response can be generated by a processing device such as a protocol server device. An exemplary change batch response can be used to synchronize file data. As an example, the change batch response includes: an identification that the change batch response is generated by using a specific file synchronization protocol, an identification of specific file data for synchronization, an instruction for accessing the specific file data including at least one uniform resource identifier for accessing the specific file data, and an instruction indicating that, for example, at least one data transfer protocol is used to obtain the specific file data when accessed using the uniform resource identifier. In the change batch response, the instruction indicating at least one data transfer protocol may also include: an instruction to obtain the first file data using a first data transfer protocol and an instruction to obtain the second file data using a second data transfer protocol different from the first data transfer protocol. The change batch response may be transmitted to the client device. In at least one additional example, an indication that one or more files of the file data are synchronized with the client device may be received. The indication may include updated knowledge metadata and, in some cases, may be received in response to a subsequent request. Additional communications between the client device and the server device may occur, for example, where additional requests and change batch responses may be exchanged to complete the synchronization of the file data.
[0005] In another example, a connection for a specific synchronization protocol can be established between a processing device and another processing device. The specific synchronization protocol is docked with multiple data transfer protocols and can be used to identify file data to synchronize with other processing devices and determine the data transfer protocol of multiple data transfer protocols to be used to download / upload specific file data. The processing device can generate a request for synchronization file data. As an example, the request can be generated by a protocol client device intended to communicate with a protocol server device. The request may include an identification that the request is generated using a specific file synchronization protocol, knowledge metadata, which includes a compact representation of the version status of the file data associated with the processing device, and a request for a uniform resource identifier that the processing device can use to download the file data for synchronization. In addition to other examples, the request can be transmitted to another processing device, such as a protocol server device. In response to the transmission of the request, a change batch response can be received. The change batch response may include: the change batch response is an identification generated using a specific file synchronization protocol, an identification of specific file data for synchronization, an instruction for accessing specific file data including at least one uniform resource identifier for accessing specific file data, and, for example, when accessing using a uniform resource identifier, an instruction to use at least one data transfer protocol to obtain specific file data. As an example, the uniform resource identifier may provide access to a storage device associated with the protocol server. The specific file data may be downloaded using a data transfer protocol (via the uniform resource identifier) identified in the change batch response. Further examples may include an indication that one or more files of the transferred file data are synchronized with the client device. In one example, the indication includes updated knowledge metadata. Additional communications between a processing device and another processing device may occur, for example, where additional requests and change batch responses may be exchanged to complete synchronization of the file data.
[0006] In yet another example, a first processing device may be docked with another processing device to synchronize file data by uploading file data from the first processing device to a storage device associated with a second processing device. A request for knowledge metadata identifying the state of file data associated with a server device may be transmitted from the first processing device to the second processing device. As an example, the first processing device may be a protocol client device, and the second processing device may be a protocol server device. The first processing device may, for example, receive knowledge metadata from the second processing device. In response to receiving the knowledge metadata, the first processing device may generate a file synchronization request, wherein the file synchronization request identifies file data to be synchronized with the second processing device. The file synchronization request may be transmitted to the second processing device. In response, the first processing device may receive a file synchronization response from the second processing device. The file synchronization response includes data indicating the location of the uploaded file data, and instructions indicating the use of at least one data transfer protocol to upload the file data. Using the file synchronization response, the first processing device may upload the file data.
[0007] The non-limiting examples of the present disclosure further describe an implementation of an exemplary synchronization protocol for identifying file data for synchronization and negotiating how to implement data transmission for synchronizing file data. In one example, a request for data synchronization is received from a processing device. In response to receiving the request, a response is generated. The response may include: an identification of file data for synchronization, an instruction for accessing the file data, and an instruction to utilize a data transmission protocol to obtain the file data. The response may be transmitted to the processing device, for example, to enable the processing device to synchronize the file data.
[0008] In other non-limiting examples of the present disclosure, an exemplary synchronization protocol is implemented to enable a processing device to synchronize file data with another processing device and / or a distributed network. In one example, a request for knowledge metadata identifying the state of file data associated with a second processing device is transmitted. The knowledge metadata may be received. In response, a file synchronization request identifying file data to synchronize with the second processing device may be generated. A file synchronization response may be received from the second processing device. The file synchronization response may include data indicating a location to upload file data, and instructions to upload file data using at least one data transfer protocol. The file synchronization response may be used to transmit file data for uploading, such as uploading to a storage device associated with the second processing device.
[0009] Additional features and advantages will be set forth in the following description and, to some extent, will become apparent from the description or may be learned through practice. The features and advantages may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features will become more apparent from the following description and the appended claims or may be learned through the practice set forth below. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Non-limiting and non-exhaustive examples are described with reference to the following figures.
[0011] Figure 1 An exemplary computer architecture for synchronizing file data between computer systems by which aspects of the present disclosure may be practiced is illustrated.
[0012] Figure 2 An exemplary computer architecture for synchronizing file data between computer systems by which aspects of the present disclosure may be practiced is illustrated.
[0013] FIG. 3A to FIG. 3D An exemplary computer architecture for synchronizing file data between computer systems by which aspects of the present disclosure may be practiced is illustrated.
[0014] Figure 4 An example method of synchronous downloading of files using a synchronization protocol is illustrated by which aspects of the present disclosure may be practiced.
[0015] Figure 5 An example method of file synchronization upload using a synchronization protocol by which aspects of the present disclosure may be practiced is illustrated.
[0016] Figure 6 is a block diagram illustrating an example of a computing device by which aspects of the present disclosure may be practiced.
[0017] Fig. 7A and Figure 7B is a simplified block diagram of a mobile computing device with which aspects of the present disclosure may be practiced.
[0018] Figure 8 is a simplified block diagram of a distributed computing system by which aspects of the present disclosure may be practiced. DETAILED DESCRIPTION
[0019] The example extends to methods, systems, and computer program products for synchronizing file data between processing devices using a protocol. A protocol is a set of rules that processing devices can utilize to communicate with each other. An exemplary synchronization protocol can be utilized to synchronize data between a protocol client and a protocol server. A protocol client is one or more processing devices that initiate communications with one or more other processing devices. In one example, a protocol client can be a processing device such as a computer or server. In another example, a protocol client can be a distributed network (e.g., a collection of remote devices), such as a cloud network, etc. A protocol server is one or more processing devices that receive communications from a protocol client and generate responses to the communications. In one example, a protocol server can be a processing device such as a computer or server. In another example, a protocol server can be a distributed network (e.g., a collection of remote devices), such as a cloud network, etc.
[0020] An exemplary synchronization protocol is a protocol that can be used to enable devices to communicate in order to negotiate which data needs to be transferred between processing devices, and further identify what data transfer protocol is to be used to transfer data between devices. Consider the following example, in which it is determined that 3 files from a file system including 100,000 files will be updated for synchronization between processing devices. An exemplary synchronization protocol can establish communication to identify how to synchronize those 3 files between processing devices. The synchronization protocol performs a sequence of processing operations for enabling devices to communicate to enable data transfer between processing devices. Processing devices can utilize different data transfer protocols to transfer data between devices. A data transfer protocol is a protocol for transferring data between processing devices. A data transfer protocol can be a standardized format for transferring data such as file data, wherein a data transfer protocol can specify how data transfer should occur, for example, to complete data synchronization between processing devices. Exemplary data transfer protocols may include, but are not limited to: File Transfer Protocol (FTP), Secure Shell Protocol (SSH), Hypertext Transfer Protocol (HTTP), HTTP Security (HTTP / S), Simple Mail Transfer Protocol (SMTP), File Service Protocol (FSP), SSH File Transfer Protocol (SFTP), FTP (FTPS) over Secure Sockets Layer (SSL), and Trivial File Transfer Protocol (TFTP), etc. The examples described herein are not limited to any particular data transfer protocol. That is, the exemplary synchronization protocols described herein are not limited to using a single data transfer protocol to transfer data. The synchronization protocol is configured to be extensible to work with a variety of different data transfer protocols. In some examples, more than one data transfer protocol is used to synchronize data. For example, in an example where three files are being synchronized, the first file may be transmitted using a first data transfer protocol, while the other two files may be transmitted using different data transfer protocols. When a processing device does not know the data transfer protocol being utilized by another device, problems may occur during data transfer. In some examples, a processing device that sends / receives data may not be configured to work with certain data transfer protocols. An exemplary synchronization protocol is implemented to identify file data for synchronization, instruct protocol clients where to access file data for transfer (eg, download / upload file data), and instruct protocol clients what data transfer to use when transferring file data, among other things.
[0021] For example, a protocol client can initiate synchronization of file data by communicating with a protocol server. For example, a protocol server can be associated with one or more storage devices / storage devices that maintain data on a distributed network. As an example, an exemplary synchronization protocol can be established between a protocol client and a protocol server so that the protocol client can communicate with the storage device / storage device to synchronize file data with the storage device / storage device. The synchronization protocol can be used to synchronize file data and synchronization metadata between processing devices (such as a protocol client and a protocol server). Synchronization metadata is exchanged between a protocol client and a protocol server to facilitate synchronization. File data includes file metadata and file content (data stream). File metadata may include file names, timestamps, attributes, etc. However, the synchronization protocol is separate from the transmission protocol for transmitting file data. In this way, the synchronization protocol can coordinate the use of different mechanisms / other protocols to transmit file data. For example, in one aspect, the synchronization protocol sends a uniform resource identifier (URI) that a protocol client can use to access file data. In one example, the URI may be a uniform resource locator (URL). The protocol client contacts the URL to obtain file data, which may be hosted in a separate service. The synchronization protocol can also send an indication of what data transmission protocol to use. That is, the synchronization protocol indicates how to use the URL appropriately. For example, the synchronization protocol supports arbitrary topologies of HTTP clients and servers. The synchronization protocol can be configured to accommodate a single server topology as well as any number of servers (e.g., data centers and / or clouds) that synchronize file data sets with each other and with corresponding clients.
[0022] In the example described in this article, data transmission is distinguished from the synchronization of the processing device for transmitting data. As mentioned above, different processing devices can be configured to work (or preferably transmit data) using a specific data transmission protocol. For example, the client device can be configured to work in accordance with HTTP, and the storage device that the client device is synchronizing with it can be configured to work in accordance with another data transmission protocol such as HTTPS or FTP. The example described in this article can be extended to synchronize the processing device (for example, the protocol client downloads the file data to synchronize with the processing device / network) by downloading file data and synchronize one or more processing devices (for example, the protocol client uploads the file data to synchronize with the processing device / distributed network) by uploading data. However, the exemplary synchronization protocol is not limited to the download / upload of data, and can be applicable to any data transmission between the protocol client and the protocol server. As identified above, the exemplary synchronization protocol can be extended to any example related to the data transmission between the processing device.
[0023] An exemplary synchronization protocol utilizes knowledge data to identify what file data is needed in order to synchronize at least one protocol client and at least one protocol server. In this example, the knowledge metadata may include a compact representation of file data associated with one or more processing devices (such as a protocol client). Among other examples, the exemplary compact representation may include at least one of a vector clock and a Lamport timestamp. However, metadata for compact representations of file data on processing devices is not limited to such examples. For example, the knowledge metadata may be updateable, where modifications to the file data (e.g., by synchronization) may produce updated compact representations for the processing device. The compact representation of file data known to the processing device contains metadata relative to a variety of devices or nodes across a network, thereby enabling the protocol client to synchronize with different processing devices of a distributed network (or multiple distributed networks), regardless of the form factor of the processing device. In this way, knowledge metadata can be used to effectively synchronize processing devices with multiple nodes across different networks.
[0024] Further, the exemplary synchronization protocol is extensible. In one example, the synchronization protocol is configured to enable modification of file metadata (e.g., synchronization may generate additional data / metadata for each file). In another example, the synchronization protocol may be configured to integrate with any of a plurality of authentication schemes, e.g., to authenticate a protocol client and a protocol server.
[0025] Thus, the present disclosure provides a number of technical advantages, including but not limited to: implementation of a synchronization protocol that can interface with multiple data transfer protocols, the ability to separate synchronization data from data transfer, more efficient operation of processing devices to perform data transfer across applications (e.g., saving computing cycles / computing resources), more efficient communication between devices during file synchronization (e.g., less renegotiation between devices synchronizing file data), the ability to work with devices having a variety of form factors, a synchronization protocol that supports arbitrary topologies for data transfer, scalability when working with file data for synchronization (including the ability to modify metadata associated with files being synchronized), a synchronization protocol that can support any authentication scheme for authenticating client / server relationships, and reduced latency for synchronization between devices and file transfers, etc.
[0026] As discussed in more detail below, implementations may include or utilize a special or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory. Implementations also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media that can be accessed by a general or special-purpose computer system. A computer-readable medium that stores computer-executable instructions is a computer storage medium (device). A computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, implementations may include at least two distinct computer-readable media: a computer storage medium (device) and a transmission medium.
[0027] Computer storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid-state drives ("SSD") (e.g., RAM-based), flash memory, phase-change memory ("PCM"), other memory types, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired program code in the form of computer-executable instructions or data structures, and which can be accessed by a general or special purpose computer.
[0028] "Network" is defined as one or more data links that enable electronic data to be transmitted between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer appropriately regards the connection as a transmission medium. Transmission media may include networks and / or data links that can be used to carry computer executable instructions or desired program code devices in the form of data structures and can be accessed by general or special computers. The above combinations should also be included in the scope of computer-readable media.
[0029] Further, upon reaching various computer system components, program code devices in the form of computer executable instructions or data structures may be automatically transferred from a transmission medium to a computer storage medium (device) (or vice versa). For example, computer executable instructions or data structures received over a network or data link may be cached in RAM within a network interface module (e.g., "NIC") and then ultimately transferred to computer system RAM and / or non-volatile computer storage medium (device) at the computer system. Thus, it should be understood that computer storage media (devices) may be included in computer system components that also (or even primarily) utilize transmission media.
[0030] Computer executable instructions include, for example, instructions and data, which, when executed at a processor, cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a certain function or group of functions. Computer executable instructions may be, for example, binary files, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in a language dedicated to the actions of structural features and / or methods, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. On the contrary, the described features and actions are disclosed as example forms of implementing the claims.
[0031] Those skilled in the art will appreciate that the various aspects described can be practiced in a network computing environment with many types of computer system configurations, including data centers, personal computers, desktop computers, laptop computers, message processors, handheld devices, wearable devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, watches, routers, switches, etc. The described aspects can also be practiced in a distributed system environment, where local computer systems and remote computer systems linked by a network (by a hardwired data link, a wireless data link, or a combination of a hardwired data link and a wireless data link) all perform tasks. In a distributed system environment, program modules may be located in local memory storage devices and remote memory storage devices.
[0032] The various aspects described may also be implemented in a distributed network environment. An example of a distributed network environment is a cloud computing environment. However, those skilled in the art will recognize that the distributed network is not limited to the example of a cloud computing environment. In this specification and in the following claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources. For example, cloud computing may be employed in the marketplace to provide anywhere and convenient on-demand access to a shared pool of configurable computing resources. A shared pool of configurable computing resources may be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
[0033] The cloud computing model may consist of various features, such as, for example, on-demand self-service, broadband network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model may also exhibit various service models, such as, for example, software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS"). The cloud computing model may also be deployed using different deployment models, such as private cloud, community cloud, public cloud, hybrid cloud, etc. In this specification and claims, a "cloud computing environment" is an environment that employs cloud computing.
[0034] Aspects of the present invention include a sequence of protocol commands and a corresponding sequence of protocol parameters for a synchronization protocol. Any of the first party, the second party, and the third party may implement a client and / or server side of the synchronization protocol to interface with a file storage solution. A collection of files to be synchronized may be identified based on the transmission of metadata in a compact representation known to a processing device. Exemplary Compact Representation
[0035] Figure 1 An example computer architecture 100 for synchronizing file data between computer systems is illustrated. Figure 1 , the computer architecture 100 includes a protocol client 101, a protocol server 102, a storage device 103, and a storage device 104. The protocol client 101, the protocol server 102, the storage device 103, and the storage device 104 can be connected to a network (or a portion of a network), such as, for example, a local area network ("LAN"), a wide area network ("WAN"), or even the Internet. Thus, the protocol client 101, the protocol server 102, the storage device 103, and the storage device 104, as well as any other connected computer systems and components thereof, can create message-related data and exchange message-related data over the network (e.g., Internet Protocol ("IP") datagrams and other higher-layer protocols such as the Transmission Control Protocol ("TCP"), the Hypertext Transfer Protocol ("HTTP"), the Simple Mail Transfer Protocol ("SMTP"), the Simple Object Access Protocol (SOAP), etc. that utilize IP datagrams or use other non-datagram protocols). Communications between the protocol client and the protocol server can be authenticated using any type of authentication scheme. The exemplary synchronization protocol may be configured to interface with any type of authentication scheme, for example, wherein establishment of a communication channel for the synchronization protocol may be performed via an authentication scheme to authenticate a protocol client and / or a protocol server.
[0036] exist Figure 1 In the description, the guide lines are labeled numerically (e.g., 1 to 7) to help understand the viewing Figure 1 .
[0037] In one aspect, among other examples, the protocol client 101 can be connected to the storage device 103 via a uniform resource identifier (URI) such as a local link, etc. For example, the protocol client 101 can be run on a computer system, and the storage device 103 can be included in the same computer system. In another aspect, the protocol client 101 can be run in a cloud computing environment, and the storage device 103 can be included in the same cloud computing environment. In other aspects, the protocol client 101 can be run in a cloud computing environment, and the storage device 103 is included in a different cloud computing environment. Any other configuration and relationship between the protocol client 101 and the storage device 103 is also possible.
[0038] The protocol server 102 may be configured to connect to the storage device 104. For example, the protocol server 102 may be run in a cloud computing environment, and the storage device 104 may be included in the same cloud computing environment. In another aspect, the protocol server 102 may be run on a computer system, and the storage device 104 may be included in the same computer system. In yet another aspect, the protocol server 102 may be run in one cloud computing environment, and the storage device 104 may be included in a different cloud computing environment. Any other configuration and relationship between the protocol server 102 and the storage device 104 is also possible.
[0039] In general, the computer architecture 100 can be used to transfer file data from a protocol server storage device to a protocol client storage device. From the perspective of the protocol client 101, the file data is downloaded from the protocol server storage device to the protocol client storage device. The communication is initiated by the protocol client 101. As an example, Figure 1 Synchronization of the protocol client 101 is described, where the protocol client 101 is initiating an action for obtaining file data for synchronization from the protocol server 102. As an example, the protocol client 101 may be attempting to download file data from the protocol server 102 to obtain file data that the protocol client 101 does not yet have.
[0040] For example, a synchronization protocol may be initiated between processing devices through an initial communication between a protocol client 101 and a protocol server 102. A connection for a specific synchronization protocol may be established between processing devices (e.g., a protocol client and a protocol server). In an exemplary scenario, the protocol client 101 seeks to synchronize file data with the protocol server 102 by downloading specific file data. The initial communication may be a data synchronization request with the protocol server 102, wherein the request may include one or more of the following: 1) an identification of an exemplary synchronization protocol; 2) metadata (e.g., knowledge metadata) such as a compact representation of the file state of the protocol client 101; and a request for a uniform resource identifier that the client device may use to download the file data for synchronization. In one example, the request may include an identification of a specific file synchronization protocol and knowledge metadata indicating the file state of the file data managed by the protocol client 101. As previously described, the protocol client 101 generates and maintains knowledge metadata 107. The knowledge metadata 107 may include a compact representation of the version state of the file 126 associated with the protocol client 101. Among other examples, the exemplary compact representation may include one or more of a vector clock and a Lamport timestamp. However, the metadata for compact representation of file data on the processing device is not limited to such examples. The protocol client 101 may send knowledge metadata 107 to the protocol server 102 (see, for example, Figure 1 Using the synchronization protocol, the protocol server 102 may receive knowledge metadata 107 from the protocol client 101 and utilize the metadata (e.g., a compact representation of the file data for the protocol client 101) to identify the state of the file data of the protocol client 101. Processing operations may be performed to determine what file data the protocol client 101 needs to synchronize with the protocol server 102. In doing so, the protocol client may compare the knowledge metadata 107 with metadata 108 maintained by the protocol client 101. The metadata 108 may be retrieved from one or more storage devices (e.g., storage device 104 (see, e.g., Figure 1 The guide line “2”)) is obtained.
[0041] In response to communications received from the protocol client 101, the protocol server 102 may generate a change batch 109 (see, e.g., Figure 1' . The exemplary change batch is a response to a request from the protocol client 101, wherein the protocol server 102 can evaluate and process the received knowledge metadata 107 to determine the file data that the protocol client 101 needs for synchronization. The change batch 109 may include one or more of the following: 1) an identification of an exemplary synchronization protocol; 2) a list of file data for the protocol client 101 to obtain / modify; 3) metadata for files to be synchronized with the protocol client 101; 4) instructions where to access (e.g., URI / URL links connected to one or more storage devices of a distributed network) the file data; and 5) instructions indicating one or more data transfer protocols utilized in transferring file data between a storage device associated with the protocol server 102 and a storage device associated with the protocol client 101. In one example, the change batch 109 may include file change data 111 and file access data 113. The file changes 111 also include metadata 108 associated with files for the storage device 104 of the protocol server 102. The file access data 113 also includes location data 114 and transfer protocol data 116. Location data 114 includes instructions for where to access file data (e.g., URI / URL link connected to one or more storage devices of a distributed network). Transfer protocol data 116 includes instructions indicating one or more data transfer protocols utilized in transmitting file data. As identified above, the protocol server 102 can generate a change batch 109 by performing a processing operation of comparing the received knowledge metadata 107 with the metadata 108. The change batch 109 identifies file changes 111 that were previously unknown to the protocol client 101. The file changes 111 are related to files 126 as stored in the storage device 104. On the other hand, the change batch 109 identifies the file change data 111 and one or more other file changes. The one or more other file changes may be changes to files in the file 126. Alternatively, the change batch 109 may not contain file changes (i.e., the change batch 109 is an empty batch). The file changes may be changes to file content (modification, creation, deletion) and / or file metadata (file name, file storage location, directory, file size, access attributes, etc.). The protocol server 102 may be configured to send the change batch 109 to the protocol client 101 . The protocol client 101 may receive the change batch 109 from the protocol server 102 .
[0042] The change batch 109 indicates file data to be modified and / or added to the storage device 103 associated with the protocol client 101. The protocol client 101 can use the change batch 109 to initiate a file data request 112 to retrieve the file data from the storage device (e.g., storage device 104) associated with the protocol server 102 (see, e.g., Figure 1 4). The file data request 112 may utilize data from the change batch 109 to access the storage device 104. In one example, the protocol client 101 may use the location data 114 (the location of the file 126 at the storage device 104) and the transfer protocol data 116 to download the file data 117 from the storage device 104. The transfer protocol data 116 may be a data transfer protocol compatible with the storage device 104. The transfer protocol data 116 may be determined using an exemplary synchronization protocol, where such data may be maintained by the protocol server 102 or obtained through communication with one or more other processing devices / storage devices associated with such a processing device.
[0043] In response to processing operations associated with evaluating the change batch 109, the protocol client 101 may utilize the change batch 109 to access the file data and obtain (e.g., download) the file data to synchronize the protocol client 101 with one or more storage devices of the protocol server 102. For synchronization purposes, the file data 117 may be transferred from the storage device 104 to the protocol client 101 (and associated storage devices) (see, e.g., Figure 1 In some examples, file data 117 received by protocol client 101, e.g., to update file 126, may include additional content (e.g., data stream) and one or more additional metadata fields, compared to file data (e.g., file 126) previously stored by protocol client 101. File data 117 may be stored in storage device 103 associated with protocol client 101 (see, e.g., Figure 1 In some examples, the processing operation occurs where a data submission notification is transmitted from the protocol client 101 to the protocol server 102. However, some examples may not include a notification of submission of data. For example, the protocol client 101 may update its knowledge metadata 107 to knowledge metadata 107u as an updated compact representation known and / or stored on the protocol client 101 (see, e.g., Figure 1's guide line "7"). In the example, the knowledge metadata 107 / 107u is not limited to the knowledge data for a specific protocol client / protocol server relationship. That is, the knowledge metadata 107 / 107u can be used to update different topologies of the client / server relationship. The knowledge metadata 107 and the updated knowledge metadata 107u provide advantages over simple timestamp data that relates to updates performed on a specific client / server relationship, where the knowledge metadata described herein can be used by multiple different topologies to initiate synchronization of data. In one example, the protocol client 101 can perform processing operations to submit metadata 108 and file data 117 to the storage device 103. Submitting the metadata 108 and file data 117 to the storage device 103 synchronizes the files in the storage device 103 with the files in the storage device 104. As described above, an example of submitting metadata can include the protocol client 101 updating the knowledge metadata 107 to the knowledge metadata 107u. If an error occurs during synchronization, the synchronization protocol may generate a communication indicating the error and restart the process to synchronize data, for example, download file data to the protocol client 101 .
[0044] Go to Figure 2 , Figure 2 An example computer architecture 200 for synchronizing file data between computer systems is illustrated. Figure 2 , the computer architecture 200 includes a protocol client 201, a protocol server 202, a storage device 203, and a storage device 204. The protocol client 201, the protocol server 202, the storage device 203, and the storage device 204 can be connected to a network (or a portion of a network), such as, for example, a local area network ("LAN"), a wide area network ("WAN"), or even the Internet. Accordingly, the protocol client 201, the protocol server 202, the storage device 203, and the storage device 204, as well as any other connected computer systems and components thereof, can create message-related data and exchange message-related data (e.g., Internet Protocol ("IP") datagrams and other higher-level protocols such as the Transmission Control Protocol ("TCP"), the Hypertext Transfer Protocol ("HTTP"), the Simple Mail Transfer Protocol ("SMTP"), the Simple Object Access Protocol (SOAP), etc. that utilize IP datagrams or use other non-datagram protocols). The computer system can switch between the protocol client function and the protocol server function, or can implement the protocol client function and the protocol server function at the same time. The communication between the protocol client and the protocol server can be authenticated using any type of authentication scheme. The exemplary synchronization protocol may be configured to interface with any type of authentication scheme, for example, wherein establishment of a communication channel for the synchronization protocol may be performed via an authentication scheme to authenticate a protocol client and / or a protocol server.
[0045] exist Figure 2 In the description, the guide lines are labeled numerically (e.g., 1 to 7) to help understand the viewing Figure 2 .
[0046] In one aspect, the protocol client 201 can be connected to the storage device 103 via a URI (e.g., a local link or RUI). For example, the protocol client 201 can be run on a computer system, and the storage device 203 can be included in the same computer system. In another aspect, the protocol client 201 can be run in a cloud computing environment, and the storage device 203 can be included in the same cloud computing environment. In other aspects, the protocol client 201 can be run in a cloud computing environment, and the storage device 203 is included in a different cloud computing environment. Any other configuration and relationship between the protocol client 201 and the storage device 203 is also possible.
[0047] The protocol server 202 may be configured to connect to the storage device 204. For example, the protocol server 202 may be run in a cloud computing environment, and the storage device 204 may be included in the same cloud computing environment. In another aspect, the protocol server 202 may be run on a computer system, and the storage device 204 may be included in the same computer system. In yet another aspect, the protocol server 202 may be run in one cloud computing environment, and the storage device 204 may be included in a different cloud computing environment. Any other configuration and relationship between the protocol server 202 and the storage device 204 is also possible.
[0048] In general, the computer architecture 200 can be used to transfer file data from a protocol client storage device to a protocol server storage device, for example, where data is uploaded from a protocol client to a protocol server in order to synchronize data between the protocol client and the protocol server. From the perspective of the protocol client 201, the file data is uploaded from the protocol client storage device to the protocol server storage device. The communication is initiated by the protocol client 201.
[0049] The protocol client 201 may send a knowledge metadata request 218 to the protocol server 202 (see, e.g., Figure 21). An example of a knowledge metadata request 218 may include a request for knowledge metadata from a protocol server 202 to initiate processing, wherein the protocol server 202 may send a view of data stored on the protocol server 202 and / or a processing device associated with the protocol server 202 to the protocol client 201. The protocol server 202 may receive the knowledge metadata request 218 from the protocol client 201. In response, the protocol server 202 may send knowledge metadata 207 to the protocol client 201 (see, e.g., Figure 2 The knowledge metadata 207 may include a compact representation of the version status of the file 206B. The protocol client 201 may receive the knowledge metadata 207 from the protocol server 202.
[0050] The protocol client 201 may compare the knowledge metadata 207 with the metadata 208 to identify any differences in knowledge between the protocol client 201 and the protocol server 202 (e.g., differences between the file 226 at the storage device 203 and the file 226 at the storage device 204). The differences may be represented in the metadata subset 228. However, even when the file data for synchronization is identified, the protocol client 201 still does not know where to upload the file data / metadata for synchronization due to the underlying protocol differences between the protocol client 201 and the protocol server 202. Among other things, the protocol client 201 may not be able to identify where to upload the file or what data transfer protocol to utilize in order to upload the file data to a specific location associated with the protocol server 202. Therefore, the exemplary synchronization protocol may be used to coordinate synchronization between the protocol client 201 and the protocol server 202.
[0051] As an example, the protocol client 201 may generate a put change batch metadata request 209 to indicate to the protocol server 202 that the protocol client 201 has file data that it wants to synchronize with the protocol server 202 (see, e.g., Figure 2201 ). For example, the protocol client 201 may have identified that it has 5 files to synchronize with the protocol server 202. The put change batch metadata request 209 may include identification of: 1) file data including file metadata to be uploaded to the protocol server 202; 2) a request for a location to upload the specific file data; and 3) a request for what data transfer to use to upload the specific file data. In one example, the put change batch metadata request 209 may include a metadata subset 228. For example, the metadata subset 228 may include metadata for 5 files that the protocol client 201 desires to upload to the protocol server 202. The protocol server 202 may use the metadata subset 228 to determine the location data 214 (of the file 226 at the storage device 204) and the transfer protocol data 216 for the file 226.
[0052] The protocol server 202 may generate a change batch response 210, wherein the change batch response 210 is a response to the place change batch metadata request 209 received from the protocol client 201 (see, e.g., Figure 2 4). The exemplary change batch response 210 includes data that enables the protocol client 201 to upload file data to a storage device (e.g., storage device 204) associated with the protocol server 202. The change batch response 210 may include information file access data 212, which includes location data 214 and transfer protocol data 216. The location data 214 may include data regarding where to transfer file data for synchronization with the protocol server 202. In one example, the location data 214 may include a link to a storage device / directory associated with the protocol server 202. The transfer protocol data 216 may include data for utilizing a data transfer protocol to synchronize data between the protocol client 201 and the protocol server 202, for example, during the upload of file data from the protocol client 201.
[0053] The protocol client 201 may receive a change batch response 210. With knowledge of the file access data 212, the protocol client 201 may upload file data 217 using at least the location data 214 and the transfer protocol data 216. The file data 217 may be uploaded directly to the storage device 204 or may be uploaded to an intermediate storage server that operates to store the data in the storage device 204.
[0054] The protocol client 201 may generate placement change batch data 225 indicating that the protocol server 202 may submit the uploaded data (see, e.g., Figure 25). Place change batch data 225 indicates that the file data upload has been completed and requests that the file data be submitted to a storage device associated with protocol server 202. In response, protocol server 202 may submit metadata 208 to storage device 204 and cause file data 217 to be submitted to storage device 204 (e.g., through communication with an intermediate storage service) (see, e.g., Figure 2 In some examples, file data 217 received by protocol server 202, e.g., for updating file 226, may include additional content (e.g., data stream) and one or more additional metadata fields, compared to file data previously stored by protocol server 202 (e.g., file 226). Protocol server 202 may send status 219 indicating that metadata 208 and file data 217 are committed to protocol client 201 (e.g., see, Figure 2 7). In some examples, errors may occur during the upload of file data between the protocol client 201 and the protocol server 202. The examples herein may only submit successfully uploaded file data. If an error occurs during synchronization, the synchronization protocol may generate a communication indicating the error and restart the processing of the synchronization data. For example, assume that an upload is to occur to upload 3 files from the protocol client 201 to the protocol server 202, and 2 of the 3 files are successfully uploaded. The protocol server 202 may submit these two files and resend communications (e.g., knowledge metadata) for the protocol client 101 to re-upload the third file.
[0055] FIG. 3A to FIG. 3D An exemplary computer architecture for synchronizing file data between computer systems is illustrated. Figure 3A , the computer architecture includes computer systems 301, 302, and 303 and storage devices 307, 308, and 309. Computer systems 301, 302, and 303 and storage devices 307, 308, and 309 may be connected to a network (referred to as part of the network), such as, for example, a local area network ("LAN"), a wide area network ("WAN"), or even the Internet. Thus, computer systems 301, 302, and 303 and storage devices 307, 308, and 309, as well as any other connected computer systems and components thereof, may create and exchange message-related data over the network (e.g., Internet Protocol ("IP") datagrams or other higher-layer protocols such as Transmission Control Protocol ("TCP"), Hypertext Transfer Protocol ("HTTP"), Simple Mail Transfer Protocol ("SMTP"), Simple Object Access Protocol (SOAP), etc. that utilize IP datagrams or use other non-datagram protocols).
[0056] In general, computer systems 301, 302, 303 and storage devices 307, 308, and 309 can operate in any environment. As depicted, computer system 301 includes a protocol client 311 and is associated with storage device 307. Protocol client 311 can be associated with storage device 307 via a local link or a network connection. For example, protocol client 311 and storage device 307 can be connected via a system bus at computer system 301, can be connected in the same data center, connected via the Internet, etc. Computer system 302 includes a protocol server 312 and is associated with storage device 308. Protocol server 312 can be associated with storage device 308 or a local link or a network connection. For example, protocol server 312 and storage device 308 can be connected via a system bus at computer system 302, can be connected in the same data center, connected via the Internet, etc.
[0057] The computer system 303 includes a protocol server 314 and is associated with a storage device 309. The protocol server 314 can be associated with the storage device 309 or a local link or network connection. For example, the protocol server 314 and the storage device 309 can be connected via a system bus at the computer system 303, can be connected in the same data center, connected via the Internet, etc.
[0058] In one aspect, protocol server 312 and protocol server 314 operate in the same cloud computing environment. In another aspect, protocol server 312 and protocol server 314 operate in different cloud computing environments. In one aspect, storage device 308 and storage device 309 are located in the same cloud computing environment. In another aspect, storage device 308 and storage device 309 are located in different cloud computing environments.
[0059] Any other configurations and relationships between the protocol client 311, the protocol servers 312 and 314, and the storage devices 308 and 309 are possible.
[0060] Based on the existing configuration, the protocol client 311 can be configured to synchronize with the protocol server 312. The protocol client 311 and the protocol server 312 can exchange synchronization protocol communications 316. The synchronization protocol communications 316 can be a communication channel for the protocol client 311 and the protocol server 312 to initiate synchronization of file data. Based on the synchronization protocol communications 316, the transport protocol can then be used to send (upload) the file data 306 from the storage device 307 to the storage device 308.
[0061] Go to Figure 3B, the computer system switches to implement the protocol client. The protocol client and the protocol server 314 can exchange synchronization protocol communications 326. The synchronization protocol communications 326 can be a communication channel for the protocol client and the protocol server 314 to initiate synchronization of file data. Based on the synchronization protocol communications 326, the transport protocol can then be used to send (upload) the file data 306 from the storage device 308 to the storage device 309.
[0062] Go to Figure 3C , based on the configuration change, the protocol client 311 may be configured to synchronize with the protocol server 314. The protocol client 311 and the protocol server 314 may exchange synchronization protocol communications 317. The synchronization protocol communications 317 may be a communication channel for the protocol client 311 and the protocol server 314 to initiate synchronization of file data. Based on the synchronization protocol communications 317, the transport protocol 333 may then be used to send (download) the file data 306 from the storage device 309 to the storage device 307. Alternatively and / or and / or in combination, the transport protocol 334 may be used to send (upload) the file data 319 from the storage device 307 to the storage device 309. The file data 319 may be file data generated at the computer system 301 after the synchronization protocol communications 316. When considering Figure 3A and Figure 3C , it is identified that the protocol client 311 can communicate with different protocol servers, for example, protocol server 312 and protocol server 314, to synchronize file data. That is, the protocol client 311 can synchronize file data with a first protocol server 312 (for example, in a first cloud computing region), and then turn to and synchronize file data with another protocol server 314 (for example, in a second cloud computing region). When doing so, a certain amount of renegotiation usually occurs for the first synchronization between the protocol client 311 and each protocol server. Such renegotiation may usually include many back-and-forth interactions or knowledge data files that indicate what is known, and the resolution of such renegotiation may take time. In other instances, file data may be stored across multiple protocol servers. In such instances, when a protocol server (for example, protocol server 314) is unaware of updates to the protocol client 311 by another protocol server (for example, protocol server 312), synchronization may be difficult. In the present example, knowledge metadata (e.g., a compact representation of what the protocol client 311 knows) can be used to enable the protocol client to immediately pivot and synchronize with different protocol servers (e.g., protocol server 312 and protocol server 314) without requiring large-scale renegotiation with the corresponding protocol servers. As described above, the knowledge metadata (and updated knowledge metadata following an update to the protocol client) can include metadata relating to a variety of devices or nodes across a network.
[0063] In another example, no changes to the files in the storage device 307 occur after the synchronization protocol communication 316. Figure 3D , the protocol server 314 may use the synchronization protocol communication 341 to send an empty batch 321 to the protocol client 311 (e.g., when the protocol client 311 initiates a download). Alternatively, the protocol client 311 may use the synchronization protocol communication 341 to send an empty batch 322 to the protocol server 314 (e.g., when the protocol client 311 initiates an upload). The empty batch indicates that the files in the storage device 307 and the corresponding files in the storage device 309 are synchronized.
[0064] Although the protocol server 312 and the protocol client 311 are described separately, the computer system 302 can implement the protocol server 312 together with (e.g., simultaneously) the protocol client 311. The computer system 301 can also implement a protocol server (not shown) together with the protocol client 311 (e.g., simultaneously). The computer system 303 can also implement a protocol client (not shown) together with the protocol server 314 (e.g., simultaneously).
[0065] In one aspect, a computer system implements one or more (or more) protocol servers together with one or more (or more) protocol clients (e.g., simultaneously). Thus, a computer system can participate in multiple instances of a synchronization protocol substantially simultaneously. Multiple instances of a synchronization protocol can be used to synchronize file data with different computer systems and / or synchronize file data between different computer systems.
[0066] Figure 4 An example method 400 for synchronous downloading of files using a synchronization protocol is illustrated. As depicted, the download flow 400 includes a protocol client 401, a protocol service 402, a client storage device 403, and (possibly multiple instances) a server storage device 404. Figure 4 402. The thicker lines (e.g., for POSTing knowledge, change batch #1, get change batch (GetChange Batch), and change batch #2) are part of the synchronization protocol. The narrower lines (e.g., for get file #1 data, file data, get file data #2, apply batch #1, apply batch #, and status) are part of the separate transport protocols and the internal batch processing on the protocol client 401 and / or protocol service 402. As previously described, the protocol client and protocol service can establish communications for synchronization using the synchronization protocol.
[0067] The protocol client 401 sends knowledge to the protocol service 402 using a publish knowledge request. As an example, the publish knowledge request is such as Figure 1The protocol service 402 uses the knowledge of the protocol client 401 and its own metadata to generate one or more change batches. An exemplary change batch is, for example, Figure 1 The change batch 109 described in . In response to publishing the knowledge, the first change batch (change batch #1) is sent. If there are no changes to download, then change batch #1 is empty.
[0068] The protocol client 401 checks the change batch #1. If the change batch #1 is not empty, then for each file in the change batch #1, the protocol client 401 determines whether the file's data has changed and is to be downloaded. If so, the protocol client 401 uses the file's location information in the metadata to download the new file data. Once the file data is downloaded, the protocol client 401 applies the change batch #1 by submitting the file changes to the client storage device 403.
[0069] The protocol client 401 updates its metadata based on the information in the change batch. If there are no more change batches, the download ends. If there are more change batches, the protocol client 401 uses Get Change Batch to download the next change batch (Change Batch #2). Similar to the inspection and processing of Change Batch #1, the protocol client 401 can inspect and process Change Batch #2. It should be appreciated that because multiple change batches may need to be processed in order to synchronize file data between processing devices, the examples described herein extend to multiple requests / responses.
[0070] Figure 5 An example method 500 for synchronously uploading files using a synchronization protocol is illustrated. As depicted, the download flow 500 includes a protocol client 501, a protocol service 502, a client storage device 503, and a service storage device 504. Figure 5 502. The thicker lines (e.g., get knowledge, serve knowledge, put change batch #1 metadata, prepare batch response, put change batch #1 data, protocol server to protocol client status, put change batch #2 metadata, and put change batch #1 data) are part of the synchronization protocol. The narrower lines (e.g., put file #1 data, serve storage to protocol client status, put file #2 data, apply batch #1, apply batch #2, and serve storage to protocol server status) are part of the separate transport protocol and the internal batch processing on the protocol client 501 and / or protocol service 502. As previously described, the protocol client and protocol service can establish communications for synchronization using the synchronization protocol.
[0071] The protocol client 501 can use the get knowledge request to transmit knowledge metadata to the protocol service 502. Figure 2As described in , an exemplary get knowledge request may be a knowledge metadata request 218. The protocol service 502 may utilize the get knowledge request to provide the protocol client with service knowledge (e.g., a service knowledge response) for the protocol client to understand the status of file data stored on at least one storage device associated with the protocol service 502. An exemplary service knowledge response may be in Figure 2 The protocol client 501 generates one or more change batches using the service knowledge of the protocol service 502 and its own metadata. Example change batches (e.g., Figure 5 The placement change batch #1) can be as follows Figure 2 The described placement change batch metadata request 209. If there are no changes to upload, the first change batch may be an empty batch.
[0072] The protocol client 501 uses a Put Change Batch #1 metadata request to notify the protocol service 502 of the change batch. The protocol service 502 examines the Put Change Batch #1 metadata request and sets up a location to upload the new file data (e.g., in the service storage device 504) and responds to the protocol client 501 with a Prepare Batch Response. The Prepare Batch Response includes the necessary upload information. If the batch is not empty, for each file in the batch, the protocol client 501 determines whether the protocol service 502 wants to receive the file's data based on the response from the protocol service 502. If so, the protocol client 501 uses the location sent by the protocol service 502 to upload the file's data. The protocol client 501 uses the Put Change Batch Response request (e.g., Figure 5 Placement changes to batch #1 data) to transfer file data for upload.
[0073] In one aspect, the data transfer is via a data transfer protocol, which may not be owned by the protocol service 502. The data transfer may succeed or fail, and a transfer status indicating success or failure may be returned.
[0074] Afterwards, the put change batch (commit instruction) enters the protocol service 502. Part of the payload of the put change batch is a per-file payload, which includes the transfer status (per file). The protocol service 502 applies the batch and uses the transfer status to determine whether the files are to be applied. If the transfer status indicates failure, the files are not applied.
[0075] For example, the protocol client 501 uses a put change batch #1 data request to instruct the protocol service 502 to apply the batch. Figure 2As depicted, an exemplary put change batch request is put change batch data 225. The protocol service 502 submits the new or changed data (if any) to storage (e.g., to service storage 504). The protocol service 502 also updates its metadata based on the information in the change batch and responds to the protocol client 501 with a status.
[0076] If there are no more batches, the upload ends. If there are more change batches, the protocol client 501 uploads the next change batch (e.g., put change batch #2 metadata request). The protocol client 501 can check and process the put change batch #2 metadata request, which is similar to the checking and processing of the put change batch #1 metadata request.
[0077] In some aspects, the service storage device (404 or 504) can be compatible with multiple different transmission protocols. If so, the protocol service (e.g., 402 or 502) can use synchronization protocol messages to make the protocol client (e.g., 401 or 501) aware of multiple different transmission protocols. The protocol client can then use a transmission protocol from a plurality of different transmission protocols to transmit (e.g., download or upload) file data between the storage location in the protocol client and the service storage device. It should be appreciated that because multiple change batches may need to be processed in order to synchronize file data between processing devices, the examples described herein extend to multiple requests / responses.
[0078] Example Parameter Commands for an Example Synchronization Protocol
[0079] The following table describes the requests involved in the communication between a protocol client and a protocol service (including a protocol server), where the protocol client is synchronizing file data via download:
[0080] Publication of knowledge
[0081]
[0082]
[0083]
[0084] Get change batch
[0085]
[0086]
[0087] In one aspect, a change batch consists of two parts: file metadata and a binary large object ("BLOB"). The file metadata format may be as follows:
[0088]
[0089]
[0090]
[0091]
[0092]
[0093]
[0094]
[0095]
[0096] Place download results
[0097]
[0098]
[0099]
[0100]
[0101] The following table describes the requests involved in the communication between a protocol client and a protocol service (including a protocol server), where the protocol client synchronizes file data with the protocol service via upload: Get Knowledge
[0102]
[0103]
[0104] Place changes to batch metadata
[0105]
[0106]
[0107]
[0108] PrepareBatchRequestEntry is a subset of the file metadata information required for a staged upload entry.
[0109]
[0110]
[0111]
[0112] Place change batch data
[0113]
[0114]
[0115]
[0116]
[0117]
[0118] Figures 6 to 8 The and associated descriptions provide a discussion of various operating environments in which examples of the present invention may be practiced. Figures 6 to 8 The devices and systems illustrated and discussed are for purposes of example and explanation and are not limiting of the wide variety of computing device configurations that may be used to practice the examples of the invention described herein.
[0119] Figure 6 6 is a block diagram illustrating the physical components of a computing device 602 (e.g., a mobile processing device) that can practice an example of the present disclosure. For example, the computing device 602 can be an exemplary computing device for implementing processing performed in association with the exemplary synchronization protocol as described herein. In a basic configuration, the computing device 602 can include at least one processing unit 604 and a system memory 606. Depending on the configuration and type of the computing device, the system memory 606 can include, but is not limited to, volatile memory (e.g., random access memory), non-volatile memory (e.g., read-only memory), flash memory, or any combination of these memories. The system memory 606 can include an operating system 607 and one or more program modules 608 suitable for running (multiple) applications 620 such as an IO manager 624, other utilities 626, and applications 628. As an example, the system memory 606 can store instructions for execution. Other examples of the system memory 606 can store data associated with the application. For example, the operating system 607 can be suitable for controlling the operation of the computing device 602. Furthermore, examples of the present invention may be practiced in conjunction with a graphics library, other operating systems, or any other application, and are not limited to any particular application or system. Figure 6 622. The computing device 602 may have additional features or functionality. For example, the computing device 602 may also include additional data storage devices (removable and / or non-removable), such as, for example, magnetic disks, optical disks, or tapes. Figure 6 Such additional storage devices are illustrated by removable storage device 609 and non-removable storage device 610.
[0120] As stated above, several program modules and data files may be stored in system memory 606. While executing on processing unit 604, program modules 608 (e.g., input / output (I / O) manager 624, other utilities 626, and applications 628) may perform processes, including but not limited to one or more of the stages of operation described throughout the present disclosure. Other program modules that may be used in accordance with examples of the present invention may include email and contact applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided applications, photo editing applications, authoring applications, and the like.
[0121] Furthermore, examples of the present invention may be practiced in circuits including discrete electronic components, in packages or integrated electronic chips containing logic gates, in circuits utilizing microprocessors, or on a single chip containing electronic components or microprocessors. For example, examples of the present invention may be practiced via a system on a chip (SOC), wherein Figure 6 Each or more of the components illustrated in the figure can be integrated into a single integrated circuit. Such a SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") into a chip substrate as a single integrated circuit. When operated via a SOC, the functions described herein can be operated via application-specific logic integrated with other components of a computing device 602 on a single integrated circuit (chip). The examples disclosed herein can also be practiced using other technologies capable of performing logical operations (such as, for example, AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. In addition, examples of the present invention can be practiced in a general-purpose computer or in any other circuit or system.
[0122] The computing device 602 may also have one or more input devices 612, such as a keyboard, a mouse, a pen, a voice input device, a device for voice input / recognition, a touch input device, and the like. One or more output devices 614, such as a display, a speaker, a printer, and the like, may also be included. The above devices are examples, and other devices may be used. The computing device 602 may include one or more communication connections 616, which allow communication with other computing devices 618. Examples of suitable communication connections 616 include, but are not limited to, RF transmitters, receivers, and / or transceiver circuits; Universal Serial Bus (USB), parallel ports, and / or serial ports.
[0123] As used herein, the term "computer-readable medium" may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, or program modules). System memory 606, removable storage 609, and non-removable storage 610 are all examples of computer storage media (i.e., memory storage devices). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article that can be used to store information and can be accessed by computing device 602. Any such computer storage media may be part of computing device 602. Computer storage media do not include carrier waves or other propagated or modulated data signals.
[0124] Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more characteristics set or changed in a manner that encodes information in the signal. By way of example and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
[0125] Fig. 7A and Figure 7B A mobile computing device 700 is illustrated in which an example of the present invention may be practiced, e.g., a mobile phone, a smart phone, a personal data assistant, a tablet personal computer, a tablet phone, a slate, a laptop computer, etc. For example, the mobile computing device 700 may be an exemplary computing device for implementing processing associated with the exemplary synchronization protocol as described herein. For example, the mobile computing device 700 may be implemented to execute applications and / or application command controls associated with the exemplary synchronization protocol. The application command control involves the presentation and control of commands used with an application through a user interface (UI) or a graphical user interface (GUI). In one example, the application command control may be programmed to work specifically with a single application. In other examples, the application command control may be programmed to work across more than one application. Reference Fig. 7A, illustrates an example of a mobile computing device 700 for implementing these examples. In a basic configuration, the mobile computing device 700 is a handheld computer with input elements and output elements. The mobile computing device 700 typically includes a display 705 and one or more input buttons 710 that allow a user to enter information into the mobile computing device 700. The display 705 of the mobile computing device 700 can also be used as an input device (e.g., a touch screen display). If included, the optional side input element 715 allows other user input. The side input element 715 can be a rotary switch, a button, or any other type of manual input element. In an alternative example, the mobile computing device 700 can include more or fewer input elements. For example, in some examples, the display 705 may not be a touch screen. In another alternative example, the mobile computing device 700 is a portable telephone system, such as a cellular phone. The mobile computing device 700 can also include an optional keypad 735. The optional keypad 735 can be a physical keypad or a "soft" keypad generated on a touch screen display or any other soft input panel (SIP). In various examples, the output elements include a display 705 for showing a GUI, a visual indicator 720 (e.g., a light emitting diode), and / or an audio transducer 725 (e.g., a speaker). In some examples, the mobile computing device 700 includes a vibration transducer for providing tactile feedback to the user. In yet another example, the mobile computing device 700 includes input and / or output ports such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., an HDMI port) for sending signals to or receiving signals from external devices.
[0126] Figure 7B 7 is a block diagram illustrating an architecture of one example of a mobile computing device. That is, a mobile computing device 700 may include a system (i.e., architecture) 702 to implement some examples. In an example, the system 702 is implemented as a "smart phone" capable of running one or more applications (e.g., a browser, email, calendar, contact manager, messaging client, game, and media client / player). In some examples, the system 702 is integrated into a computing device, such as an integrated personal digital assistant (PDA), a tablet computer, and a wireless phone.
[0127] One or more application programs 766 may be loaded into the memory 762 and run on or in association with the operating system 764. Examples of application programs include a phone dialer program, an email program, a personal information management (PIM) program, a word processing program, a spreadsheet program, an Internet browser program, a messaging program, and the like. The system 702 also includes a non-volatile storage area 768 within the memory 762. The non-volatile storage area 768 may be used to store persistent information that should not be lost even if the system 702 loses power. The application programs 766 may use and store information in the non-volatile storage area 768, such as emails or other messages used by an email application, and the like. A synchronization application (not shown) also resides on the system 702 and is programmed to interact with a corresponding synchronization application residing on a host computer to keep information stored in the non-volatile storage area 768 synchronized with corresponding information stored at the host computer. It should be appreciated that other applications may be loaded into the memory 762 and run on the mobile computing device 700 described herein.
[0128] System 702 has a power source 770, which can be implemented as one or more batteries. Power source 770 can also include an external power source, such as an AC adapter or a power docking station to supplement or charge the batteries.
[0129] The system 702 may include a peripheral device port 730 that performs the function of facilitating connectivity between the system 702 and one or more peripheral devices. Transmissions to and from the peripheral device port 730 are performed under the control of an operating system (OS) 764. In other words, communications received by the peripheral device port 730 may be disseminated to the application 766 via the operating system 764, and vice versa.
[0130] The system 702 may also include a radio interface layer 772 that performs the function of transmitting and receiving radio frequency communications. The radio interface layer 772 facilitates wireless connectivity between the system 702 and the "outside world" via a communications carrier or service provider. Transmissions to and from the radio interface layer 772 are performed under the control of the operating system 764. In other words, communications received by the radio interface layer 772 may be propagated to the application 766 via the operating system 764, and vice versa.
[0131] The visual indicator 720 can be used to provide a visual notification, and / or the audio interface 774 can be used to generate an audible notification via the audio transducer 725. In the illustrated example, the visual indicator 720 is a light emitting diode (LED), and the audio transducer 725 is a speaker. These devices can be directly coupled to the power supply 770 so that when activated, even if the processor 760 and other components may be turned off to save battery power, they remain turned on for a duration specified by the notification mechanism. The LED can be programmed to remain turned on indefinitely until the user takes action to indicate the power-on state of the device. The audio interface 774 is used to provide an audible signal to the user and receive an audible signal from the user. For example, in addition to being coupled to the audio transducer 725, the audio interface 774 can also be coupled to a microphone to receive an audible input, such as to facilitate a telephone conversation. According to an example of the present invention, as described below, the microphone can also be used as an audio sensor to facilitate control of the notification. The system 702 can also include a video interface 776, which enables the operation of the onboard camera to record still images, video streams, etc.
[0132] The mobile computing device 700 implementing the system 702 may have additional features or functionality. For example, the mobile computing device 700 may also include additional data storage devices (removable and / or non-removable), such as magnetic disks, optical disks, or tapes. Figure 7B Such additional storage is illustrated by non-volatile storage area 768 .
[0133] As described above, data / information generated or captured by the mobile computing device 700 and stored via the system 702 may be stored locally on the mobile computing device 700, or the data may be stored on any number of storage media that may be accessed by the device via the radio interface layer 772 or via a wired connection between the mobile computing device 700 and a separate computing device associated with the mobile computing device 700 (e.g., a server computer in a distributed computing network such as the Internet). It should be appreciated that such data / information may be accessed via the mobile computing device 700, via the radio interface layer 772, or via a distributed computing network. Similarly, such data / information may be readily transferred between computing devices for storage and use in accordance with well-known data / information transmission and storage devices including electronic mail and collaborative data / information sharing systems.
[0134] Figure 8 One example of an architecture of a system for providing an application that reliably accesses target data on a storage system and handles communication failures to one or more client devices as described above is illustrated. Figure 8The system may be an exemplary system for processing related to the exemplary synchronization protocol as described herein. The target data accessed, interacted or edited in association with the program module 608, the application 620 and the storage device / memory may be stored in different communication channels or other storage types. For example, as described herein, any one of the directory service 822, the web portal 824, the mailbox service 826, the instant messaging storage device 828 or the social network site 830, the application 628, the IO manager 624, the other utility program 626 and the storage system that can use these types of systems, etc., can be used to implement data utilization. The server 820 can provide a storage system for use by clients operating on the general computing device 602 and one or more mobile computing devices 700 through the network 815. By way of example, the network 815 may include the Internet or any other type of local area network or wide area network, and the client node may be implemented as a computing device 602 embodied in a personal computer, a tablet computing device and / or a mobile computing device 700 (e.g., a mobile processing device). Any of these examples of client computing devices 602 , 200 , and 202 may obtain content from storage 816 .
[0135] The non-limiting examples of the present disclosure describe the implementation of an exemplary synchronization protocol, which identifies file data for synchronization and negotiates how to implement data transfer for synchronization of file data. A connection for a specific synchronization protocol can be established with a client device. The specific synchronization protocol interfaces with multiple data transfer protocols and can be used to identify file data to synchronize with the client device and determine the data transfer protocol among multiple data transfer protocols to be used to download / upload specific file data. In one example, a request for synchronizing file data is received from a client device. As an example, the client device can be a protocol client, and the request can be received at a protocol server. The request may include: an identification of the request generated using a specific file synchronization protocol, knowledge metadata including a compact representation of the version status of the file data associated with the client device, and a request for a uniform resource identifier that the client device can use to download the file data for synchronization. A change batch response may be generated. The change batch response can be generated by a processing device such as a protocol server device. An exemplary change batch response can be used for synchronization of file data. As an example, a change batch response includes: an identification of a change batch response generated using a specific file synchronization protocol, an identification of specific file data for synchronization, an instruction for accessing the specific file data including at least one uniform resource identifier for accessing the specific file data, and an instruction indicating, for example, to utilize at least one data transfer protocol to obtain the specific file data when accessed using the uniform resource identifier. In the change batch response, the instruction indicating at least one data transfer protocol may also include an instruction to obtain the first file data using a first data transfer protocol and an instruction to obtain the second file data using a second data transfer protocol different from the first data transfer protocol. The change batch response may be transmitted to a client device. In at least one additional example, an indication that one or more files of the file data are synchronized with the client device may be received. The indication may include updated knowledge metadata and may be received in response to a subsequent request in some cases. Additional communications between the client device and the server device may occur, for example, where additional requests and change batch responses may be exchanged to complete synchronization of the file data.
[0136] In another example, a connection for a specific synchronization protocol can be established between a processing device and another processing device. The specific synchronization protocol interfaces with multiple data transfer protocols and can be used to identify file data for synchronization with other processing devices, and determines a data transfer protocol of multiple data transfer protocols to be used for downloading / uploading specific file data. The processing device can generate a request for synchronizing file data. As an example, the request can be generated by a protocol client device intended to communicate with a protocol server device. The request may include an identification that the request is generated using a specific file synchronization protocol, knowledge metadata, which includes a compact representation of the version status of the file data associated with the processing device, and a request that the processing device can use a uniform resource identifier to download the file data for synchronization. The request can be transmitted to another processing device, such as a protocol server device, etc. In response to the transmission of the request, a change batch response can be received. The change batch response may include: the change batch response is an identification generated using a specific file synchronization protocol, an identification of specific file data for synchronization, an instruction for accessing specific file data including at least one uniform resource identifier for accessing specific file data, and, for example, when using a uniform resource identifier for access, an instruction for indicating at least one data transfer protocol to obtain specific file data. As an example, the uniform resource identifier may provide access to a storage device associated with the protocol server. The specific file data may be downloaded (via the uniform resource identifier) using a data transfer protocol identified in the change batch response. Further examples may include an indication that one or more files of the transferred file data are synchronized with the client device. In one example, the indication includes updated knowledge metadata. Additional communications between a processing device and another processing device may occur where, for example, additional requests and change batch responses may be exchanged to complete synchronization of the file data.
[0137] In another example, a first processing device may be docked with another processing device to synchronize file data by uploading the file data from the first processing device to a storage device associated with a second processing device. A request for knowledge metadata identifying the state of file data associated with a server device may be transmitted from the first processing device to the second processing device. As an example, the first processing device may be a protocol client device, and the second processing device may be a protocol server device. The first processing device may, for example, receive knowledge metadata from the second processing device. In response to receiving the knowledge metadata, the first processing device may generate a file synchronization request, wherein the file synchronization request identifies file data to be synchronized with the second processing device. The file synchronization request may be transmitted to the second processing device. In response, the first processing device may receive a file synchronization response from the second processing device. The file synchronization response includes data indicating the location of the uploaded file data and instructions for using at least one data transfer protocol to upload the file data. Using the file synchronization response, the first processing device may upload the file data.
[0138] The non-limiting examples of the present disclosure describe the implementation of an exemplary synchronization protocol to identify file data for synchronization and negotiate how to implement data transfer for synchronizing file data. A synchronization protocol is a protocol that can be used to identify file data to synchronize with a processing device and convey instructions to implement data transfer of file data. As an example, a first processing device (e.g., a protocol client) can be docked with a second processing device (e.g., a protocol server) to negotiate file synchronization between devices. As identified above, the description is not limited to a single processing device. For example, the protocol client and / or the protocol server can be one or more devices (connected via a distributed network). For example, the protocol client may be trying to synchronize file data with the protocol server by downloading file data from one or more storage devices associated with the protocol server. For example, the protocol client may be trying to download file data from a distributed network environment to synchronize file data with the distributed network. A communication channel can be established between the protocol client and the protocol server for a file synchronization protocol. In one example, a request for data synchronization is sent from a protocol client and received by a protocol server. The request includes knowledge metadata, which includes a compact representation of the version state of the file data associated with the processing device. The protocol server uses the knowledge metadata to identify the file data for synchronization. In one example, the protocol server can compare the received knowledge metadata with the metadata associated with the protocol server, which metadata identifies the state of the file data corresponding to the protocol server. For example, the file data corresponding to the protocol server can be file data stored by a storage device across a distributed network. In response to receiving the request, the protocol server generates a response. The response may include: an identification of file data for synchronization, an instruction for (protocol client) accessing file data, and an instruction for (for the protocol client) to use a data transfer protocol to obtain file data. The instruction for accessing file data may include a uniform resource identifier to connect a processing device and a storage device associated with the system. For example, the response may be transmitted to the protocol client so that the protocol client can synchronize file data. In one example, the response is transmitted to the protocol client using a connection for a synchronization protocol. The protocol client can use the response to access file data and download file data using one or more data transfer protocols identified in the response. The data transfer protocol is at least one selected from the group consisting of the following: HTTP, HTTP / S, FTP and FSP, SMTP, SFTP and FTPS. However, the synchronization protocol can be configured to dock with any data transfer protocol. In other examples, the protocol server receives a second request from the protocol client. The second request may include updated knowledge metadata including, for example, a compact representation of a version state of file data associated with the processing device after a change occurred at the protocol client.The protocol client may generate a second response to the second request.The second response may include: an identification of the second file data for synchronization, an instruction for accessing the second file data, and an instruction indicating that a data transfer protocol is to be used to obtain the second file data. The second response may be transmitted to the protocol client so that the protocol client can synchronize by downloading the second file data.
[0139] In other non-limiting examples of the present disclosure, an exemplary synchronization protocol is implemented to enable a processing device to synchronize file data with another processing device and / or a distributed network. As an example, a first processing device (e.g., a protocol client) can be docked with a second processing device (e.g., a protocol server) to negotiate file synchronization between devices. As identified above, the description is not limited to a single processing device. For example, the protocol client and / or the protocol server can be one or more devices (connected via a distributed network). For example, the protocol client may be trying to synchronize file data with the protocol server by uploading the file data to one or more storage devices associated with the protocol server. For example, the protocol client may be trying to upload the file data to a distributed network environment so that a local copy of the file data is synchronized with the distributed network. A communication channel can be established between the protocol client and the protocol server for a file synchronization protocol. In one example, a request is transmitted for knowledge metadata identifying the state of the file data associated with the protocol server. The knowledge metadata can be transmitted to the protocol client and received at the protocol client. In response, the protocol client can generate a file synchronization request. The file synchronization request can identify the file data to be synchronized with the protocol server. The file data for synchronization can be identified by a processing operation, wherein the protocol client can determine the difference between the file state metadata for the protocol client and the knowledge metadata received from the protocol server. The file data synchronized with the protocol server is identified based on the difference between the determined file states. The file synchronization request can be transmitted to the protocol server. The file synchronization response can include data indicating the location of the uploaded file data and instructions for uploading the file data using at least one data transfer protocol. The file synchronization response can be used to transmit the file data for, for example, uploading to a storage device associated with the protocol server. For example, the protocol client can upload file data to the protocol server using one or more different data transfer protocols (identified by the synchronization protocol). In the example, the file synchronization request and the file synchronization response are generated by the file synchronization protocol.
[0140] Reference has been made throughout this specification to "one example" or "an example," which means that a particular described feature, structure, or characteristic is included in at least one example. Thus, use of such a phrase may refer to more than one example. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples.
[0141] However, one skilled in the relevant art may recognize that the examples may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well-known structures, resources, or operations are not shown or described in detail, solely to avoid obscuring aspects of the examples.
[0142] Although exemplary examples and applications have been illustrated and described, it should be understood that the examples are not limited to the precise configuration and resources described above. Various modifications, changes and variations that are obvious to those skilled in the art may be made to the arrangement, operation and details of the methods and systems disclosed herein without departing from the scope of the claimed examples.
Claims
1. A method for synchronizing file data, comprising: Receiving a request for synchronization of file data from a client device, wherein the request comprises: metadata including a representation identifying a state of file data associated with the client device, and In response to a request for a uniform resource identifier, the client device may use the uniform resource identifier to download the file data for synchronization; generating a response to the request for synchronization of the file data, wherein the response comprises: The identifier of the specific file data to be synchronized. an instruction for accessing the specific file data, comprising at least one uniform resource identifier for accessing the specific file data, and Instructions for obtaining the specific file data using at least one data transfer protocol when the specific file data is accessed using the uniform resource identifier, wherein the instructions include: instructions for obtaining the first file data using a first data transfer protocol, and instructions for obtaining the second file data using a second data transfer protocol different from the first data transfer protocol; transmitting the response to the client device; receiving a request for the specific file data from the client device; and Causing the specific file data to be sent to the client device.
2. A method according to claim 1, wherein the request for synchronization also includes an identification that the request is generated using a specific file synchronization protocol, wherein the response also includes an identification that the response is generated using the specific file synchronization protocol, and wherein at least one data transfer protocol is different from the specific file synchronization protocol. 3 . The method according to claim 1 , wherein the at least one data transmission protocol is at least one selected from the group consisting of: HTTP, HTTP / S, FTP, SMTP, FSP and SFTP. 4 . The method of claim 1 , further comprising receiving an indication that one or more files of the file data are synchronized with a client device, wherein the indication includes updated metadata.
5. The method according to claim 4, further comprising: generating a second response using the updated metadata, wherein the second response comprises: The identifier of the additional file data to be synchronized. instructions for accessing the additional file data, comprising at least one uniform resource identifier for accessing the additional file data, and instructions to obtain the additional file data using at least one data transfer protocol when accessed using the uniform resource identifier; and The second response is sent to the client device.
6. The method according to claim 2, further comprising: A connection is established with the client device for the specific file synchronization protocol, wherein the specific file synchronization protocol is connected to multiple data transfer protocols and can be used to: identify file data to synchronize with the client device, and determine which of the multiple data transfer protocols will be used to download the specific file data. The method of claim 1 , wherein the representation is a compact representation.
8. A system for synchronizing file data, comprising: at least one processor; as well as a memory operably connected to the at least one processor, the memory storing computer executable instructions, the computer executable instructions, when executed by the at least one processor, causing the at least one processor to perform a method, the method comprising: Receiving a request for synchronization of file data from a client device, wherein the request comprises: metadata including a representation identifying a state of file data associated with the client device, and In response to a request for a uniform resource identifier, the client device may use the uniform resource identifier to download the file data for synchronization; generating a response to the request for synchronization of the file data, wherein the response comprises: The identifier of the specific file data to be synchronized. an instruction for accessing the specific file data, comprising at least one uniform resource identifier for accessing the specific file data, and Instructions for obtaining the specific file data using at least one data transfer protocol when the specific file data is accessed using the uniform resource identifier, wherein the instructions include: instructions for obtaining the first file data using a first data transfer protocol, and instructions for obtaining the second file data using a second data transfer protocol different from the first data transfer protocol; transmitting the response to the client device; receiving a request for the specific file data from the client device; and Causing the specific file data to be sent to the client device.
9. A system according to claim 8, wherein the request for synchronization also includes an identification that the request is generated using a specific file synchronization protocol, wherein the response also includes an identification that the response is generated using the specific file synchronization protocol, and wherein at least one of the data transfer protocols is different from the specific file synchronization protocol.
10. The system of claim 8, wherein the at least one data transmission protocol is at least one selected from the group consisting of: HTTP, HTTP / S, FTP, SMTP, FSP, and SFTP.
11. The system of claim 8, wherein the method further comprises: An indication is received that one or more files of the file data are synchronized with a client device, wherein the indication includes updated metadata.
12. The system of claim 11, wherein the method further comprises: generating a second response using the updated metadata, wherein the second response comprises: The identifier of the additional file data to be synchronized. instructions for accessing the additional file data, comprising at least one uniform resource identifier for accessing the additional file data, and instructions to obtain the additional file data using at least one data transfer protocol when accessed using the uniform resource identifier; and The second response is sent to the client device.
13. The system of claim 9, wherein the method further comprises: A connection is established with the client device for the specific file synchronization protocol, wherein the specific file synchronization protocol is connected to multiple data transfer protocols and can be used to: identify file data to synchronize with the client device, and determine which of the multiple data transfer protocols will be used to download the specific file data.
14. At least one computer readable medium storing instructions which, when executed by at least one processor, cause the at least one processor to perform a method comprising: Receiving a request for synchronization of file data from a client device, wherein the request comprises: metadata including a representation identifying a state of file data associated with the client device, and In response to a request for a uniform resource identifier, the client device may use the uniform resource identifier to download the file data for synchronization; generating a response to the request for synchronization of the file data, wherein the response comprises: The identifier of the specific file data to be synchronized. an instruction for accessing the specific file data, comprising at least one uniform resource identifier for accessing the specific file data, and Instructions for obtaining the specific file data using at least one data transfer protocol when the specific file data is accessed using the uniform resource identifier, wherein the instructions include: instructions for obtaining the first file data using a first data transfer protocol, and instructions for obtaining the second file data using a second data transfer protocol different from the first data transfer protocol; transmitting the response to the client device; receiving a request for the specific file data from the client device; and Causing the specific file data to be sent to the client device.
15. At least one computer-readable medium according to claim 14, wherein the request for synchronization also includes an identification that the request is generated using a specific file synchronization protocol, wherein the response also includes an identification that the response is generated using the specific file synchronization protocol, and wherein the at least one data transfer protocol is different from the specific file synchronization protocol.
16. The at least one computer-readable medium of claim 14, wherein the at least one data transfer protocol is at least one selected from the group consisting of: HTTP, HTTP / S, FTP, SMTP, FSP, and SFTP.
17. The at least one computer-readable medium of claim 14, wherein the method further comprises: An indication is received that one or more files of the file data are synchronized with a client device, wherein the indication includes updated metadata.
18. The at least one computer readable medium of claim 17, wherein the method further comprises: generating a second response using the updated metadata, wherein the second response comprises: The identifier of the additional file data to be synchronized. instructions for accessing the additional file data, comprising at least one uniform resource identifier for accessing the additional file data, and instructions to obtain the additional file data using at least one data transfer protocol when accessed using the uniform resource identifier; and The additional file data is downloaded using the second response.
19. The at least one computer-readable medium of claim 15, wherein the method further comprises: A connection is established with the client device for the specific file synchronization protocol, wherein the specific file synchronization protocol is connected to multiple data transfer protocols and can be used to: identify file data to synchronize with the client device, and determine which of the multiple data transfer protocols will be used to download the specific file data.
20. The at least one computer-readable medium of claim 14, wherein the representation is a compact representation.
Citation Information
Patent Citations
Data synchronization protocol
CN103327073A
File storage synchronisation system and components thereof
EP2372574A1