CN115004665B

CN115004665B - File sharing method, device and system

Info

Publication number: CN115004665B
Application number: CN202080093630.1A
Authority: CN
Inventors: 严哲峰; 刘畅
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-01-21
Filing date: 2020-01-21
Publication date: 2024-04-09
Anticipated expiration: 2040-01-21
Also published as: CN115004665A; WO2021146896A1

Abstract

A file sharing method, device and system relate to the field of distributed storage, and the method comprises the following steps: receiving a data acquisition request carrying the identification of the target data block from a request node (30), and if the target data block is not stored in a storage node (10) and the identification of the target data block is recorded in a to-be-transmitted list, sending a priority uploading request carrying the identification of the target data block to a target sharing node (20) for uploading the target data block; and receiving and sending the target data block uploaded by the target sharing node (20) to the request node (30). The storage node (10) can instruct the sharing node (20) to upload the target data block requested by the request node (30) preferentially, so that the target data block can be sent to the request node (30) timely. Therefore, the request node (30) can display the shared file in real time based on the acquired data blocks in the downloading process of the shared file, and does not need to wait for the complete downloading of the shared file to be displayed.

Description

File sharing method, device and system

Technical Field

The present disclosure relates to the field of distributed storage, and in particular, to a method, an apparatus, and a system for sharing files.

Background

The terminal may share files (e.g., video files or audio files, etc.) to other terminals for viewing by users of the other terminals.

In the related art, a terminal can upload a file to a cloud server, and other terminals can download the file from the cloud server, so that file sharing among different terminals is realized. However, since the terminal needs to upload the complete file to the cloud server, other terminals can download the file, resulting in lower efficiency of file sharing.

Disclosure of Invention

The embodiment of the application provides a file sharing method, device and system, which can solve the problem of lower file sharing efficiency in the related art.

In one aspect, a method for sharing files is provided and applied to a storage node, where the method may include: receiving a data acquisition request carrying the identification of the target data block from a request node, if the target data block is not stored in the storage node and the identification of the target data block is recorded in a to-be-transmitted list, determining the address of a target sharing node for uploading the target data block according to the identification of the target data block, and sending a priority uploading request carrying the identification of the target data block to the target sharing node based on the address of the target sharing node, wherein the priority uploading request is used for indicating the target sharing node to upload the target data block preferentially; and receiving the target data block uploaded by the target sharing node, and sending the target data block to the request node. The address of the target sharing node may be a network protocol (Internet protocol, IP) address.

Based on the scheme provided by the application, the storage node can instruct the target sharing node to upload the target data block requested by the request node preferentially, so that the target data block can be sent to the request node in time. Therefore, the request node can display the shared file in real time based on the acquired data blocks in the downloading process of the shared file, and does not need to wait for the display after the complete downloading of the shared file is completed, so that the efficiency of file sharing is effectively improved.

Optionally, the correspondence between the identifier of the data block to be uploaded and the address of the sharing node may be recorded in the to-be-transmitted list; the storage node may determine, as the address of the target sharing node, the address of the sharing node corresponding to the identifier of the target data block in the to-be-transmitted list.

The to-be-transmitted list can record the identification of the data block to be uploaded and the address of the corresponding sharing node in the form of a key value pair, wherein the identification of the data block is a primary key, and the address of the sharing node is a value. Correspondingly, after receiving the data acquisition request, the storage node can query the list to be transmitted by taking the identifier of the target data block as a main key, so as to improve the efficiency of acquiring the address of the target sharing node.

Optionally, the method may further include: receiving a file header block of a sharing file sent by the target sharing node, wherein the sharing file comprises a plurality of data blocks, and the file header block comprises an identifier of each data block; for each data block, recording the corresponding relation between the identification of the data block and the address of the target sharing node in the to-be-transmitted list; after receiving the target data chunk uploaded by the target sharing node, the method further comprises: and deleting the identification of the target data block from the to-be-transmitted list.

After receiving the target data block, deleting the identification of the target data block from the to-be-transmitted list in time, so that the accuracy of the identification of the data block to be uploaded recorded in the to-be-transmitted list can be ensured.

Optionally, the address of the target sharing node is an IP address; after the corresponding relation between the identification of the data block and the address of the target sharing node is recorded in the to-be-transmitted list, the method further comprises:

receiving an IP update instruction sent by the target sharing node, wherein the IP update instruction carries an updated IP address of the target sharing node; and updating the IP address of the target sharing node recorded in the to-be-transmitted list by adopting the updated IP address.

In the embodiment of the present application, the storage node may be a fixed node, where the fixed node is a node that does not substantially move, or has an IP address that does not change substantially or changes little. The sharing node (including the target sharing node) may be a fixed node or a mobile node, where the mobile node is a node that moves frequently or has a relatively large change in IP address.

When the target sharing node is a mobile node, because the IP address of the target sharing node changes more, the target sharing node can timely send an IP update instruction to the storage node when detecting that the IP address of the target sharing node changes, so that the storage node timely refreshes the IP address recorded in the list to be transmitted, and timeliness of the list to be transmitted is ensured.

Optionally, after receiving the header block of the shared file sent by the target sharing node, the storage node may further determine, for each data block, an identifier of the target storage node for storing the routing information of the data block according to the identifier of the data block and the distributed hash algorithm; and then, according to the identifier of the target storage node, a route update instruction carrying the identifier of the data block may be sent to the target storage node, where the route update instruction is used to instruct the target storage node to record route information of the data block in a route table of the target storage node, where the route information of the data block may include: the identity of the data chunk, and the address of the storage node.

That is, in the embodiment of the present application, the storage node may register the routing information of the plurality of data blocks into each storage node in the distributed storage system based on the identification of each data block, so that hash storage of the routing information of the plurality of data blocks may be achieved.

Optionally, after the storage node receives the target data block uploaded by the target sharing node, the identification of the target data block may be recorded in a local storage list; accordingly, after the storage node receives the data acquisition request from the requesting node, if it is detected that the identifier of the target data block is not recorded in the local storage list, it may be determined that the target data block is not stored in the storage node.

In the embodiment of the application, the storage node can record the identification of the locally downloaded blocks (including the file header blocks and the data blocks) through the local storage list, so that when a data acquisition request from a request node is received, whether the target data blocks requested by the request node are locally stored or not can be quickly determined by inquiring the local storage list, and the efficiency of data block inquiry is effectively improved.

On the other hand, a file sharing method is provided and applied to sharing nodes, and the method can comprise the following steps: transmitting a file header partition of a shared file to a storage node, wherein the shared file comprises a plurality of data partitions, and the file header partition comprises an identifier of each data partition; uploading the plurality of data chunks block by block to the storage node; receiving a priority uploading request from the storage node, wherein the priority uploading request carries the identification of a target data block in a plurality of data blocks; and responding to the priority uploading request, and calling the uploading sequence of the target data blocks. The original uploading sequence of the plurality of data blocks included in the sharing file may be a playing sequence of the sharing file.

In the scheme provided by the application, after the sharing node receives the priority uploading request carrying the identifier of the target data block, the target data block can be preferentially uploaded to the storage node, and the storage node can further timely send the target data block to the requesting node. Therefore, the request node can display the shared file in real time based on the acquired data blocks in the downloading process of the shared file, and does not need to wait for the display after the complete downloading of the shared file is completed, so that the efficiency of file sharing is effectively improved.

Optionally, the sharing node may also adjust the uploading sequence of the target number of data blocks located after the target data block before adjusting the uploading sequence of the target data block. The target number may be a fixed value stored in advance in the sharing node.

The sharing node also adjusts the uploading sequence of the target number of data blocks after the target data block, so that the target number of data blocks after the target data block can be received by the requesting node in time, and further continuity when the requesting node displays (e.g. plays) the shared file is ensured.

In yet another aspect, a storage node is provided, where the storage node may include at least one module, where the at least one module may be configured to implement the file sharing method applied to the storage node in the foregoing aspect.

In still another aspect, a sharing node is provided, where the sharing node may include at least one module, and the at least one module may be configured to implement the file sharing method applied to the sharing node in the foregoing aspect.

In still another aspect, a file sharing device is provided, and the device may be applied to the storage node or the sharing node provided in the above aspect. The apparatus may include: the storage node comprises a storage, a processor and a computer program stored in the storage and capable of running on the processor, wherein the processor realizes the file sharing method applied to the storage node or the file sharing method applied to the sharing node when executing the computer program.

In still another aspect, there is provided a nonvolatile storage medium having instructions stored therein, which when executed on a processor, cause the processor to perform the file sharing method provided in the above aspect applied to a storage node, or the file sharing method applied to a sharing node.

In yet another aspect, a distributed storage system is provided, the system comprising: a plurality of storage nodes as provided in the above aspect, a sharing node as provided in the above aspect, and a requesting node.

The technical scheme provided by the application at least can comprise the following beneficial effects:

the application provides a file sharing method, device and system, after a storage node receives a data acquisition request from a request node, if an identifier of a target data block carried by the data acquisition request is recorded in a to-be-transmitted list, a priority uploading request can be sent to a sharing node for uploading the target data block, so that the sharing node can upload the target data block preferentially, and the storage node can send the target data block to the request node timely. That is, the storage node may instruct the sharing node to adjust the order of uploading the data blocks according to the order in which the requesting node requests the data blocks, so as to meet the requirement of the requesting node for displaying (e.g. playing) the data blocks. Accordingly, the requesting node can display the sharing file in real time based on the acquired data blocks in the downloading process of the sharing file, for example, play the video file in real time, without waiting for the display after the complete downloading of the sharing file. The scheme provided by the application realizes real-time display of the shared file in the downloading process, and effectively improves the efficiency of file sharing.

Drawings

FIG. 1 is a schematic diagram of a distributed storage system according to an embodiment of the present application;

FIG. 2 is a schematic diagram of another distributed storage system according to an embodiment of the present application;

FIG. 3 is a flowchart of a file sharing method according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a data partition and a header partition according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of a mobile node according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a distributed storage system according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a fixed node according to an embodiment of the present application;

FIG. 8 is a flowchart of a method for registering routing information for a data block according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a storage node according to an embodiment of the present disclosure;

fig. 10 is a schematic structural diagram of a sharing node according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a file sharing device according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

With the rapid development of internet technology, the amount of data to be processed is increasing, so that the capacity (capability) of a single machine is difficult to meet the data processing requirement. The capacity may include at least one of a computing resource (e.g., memory), a storage resource (e.g., hard disk), and a network resource (e.g., network input/output), among others. Thus, an architecture of a distributed storage system, such as a peer-to-peer (P2P), is proposed. The distributed storage system may work together and provide services by coordinating multiple terminals (also referred to as nodes) to meet the demand for capacity.

In the distributed storage system, each node can acquire services from other nodes and can also provide services for other nodes, so that the state that the network is centered on a server at present is changed, and the traditional client/server (C/S) structure in the Internet is broken. The distributed storage system changes the storage mode of the network from a "content-centric" to a "content-marginally" mode.

The distributed storage system may share files such as audio, video, text, and pictures through distributed hash table (distributed hash table, DHT) technology. DHT technology uses routing over an overlay network over the internet. The overlay network may also be referred to as an overlay (overlay) network. Distributed storage systems employing DHT technology may also be referred to as DHT networks, which may employ a ring topology. In the ring topology, each node may have a unique node identification (identity document, ID), which may be a hash of several bits (typically more than 100 bits), on which node queries and routing in the DHT network are based. The node ID may be used to represent a logical location of the node in the DHT network, and may not reflect a real physical location of the node, which may be reflected by an address of the node. Wherein the address of the node may be the IP address of the node plus a port number, the IP address may include a network protocol version 4 (Internet protocol version, IPv 4) address or an IPv6 address, etc.

The DHT network may be constructed based on DHT algorithms, which may include Chord algorithm, network transport protocol (Kademlia) algorithm, and the like. Accordingly, a routing table of the DHT network may be constructed according to a DHT algorithm for constructing the DHT network. The routing table may have a plurality of routing information (i.e., routing entries) recorded therein, wherein each routing entry is a binary set of information, and the binary set of information may include: content ID and address of node. The content ID is an ID capable of uniquely identifying content (which may also be referred to as a partition or a resource) stored in a node whose address is the address of a node for storing the content indicated by the content ID, and the address of the node may be an IP address. The routing table may be stored in a distributed manner in the individual nodes, i.e. each node in the DHT network may store a part of the routing table entries in the routing table.

For example, each node may store routing entries for content stored in its predecessor and successor nodes. Through the routing information in the routing table, the designated node can be conveniently found. For example, when a certain request node searches for content data stored in a target node, the position of the target node can be roughly determined according to the relation between the ID of the request node and the ID of the target node, so that the request message is sent to the node closer to the target node, and a better search effect is formed.

Fig. 1 is a schematic structural diagram of a distributed storage system according to an embodiment of the present application, and fig. 1 is an illustration of a DHT network. As shown in fig. 1, the distributed storage system may comprise a plurality of storage nodes 10, which plurality of storage nodes 10 may form a DHT network, i.e. DHT ring. The system may further include: a sharing node 20 and a requesting node 30. The sharing node 20 may upload the sharing file to a certain storage node 10, and the requesting node 30 may request to obtain the sharing file from the storage node 10 in the DHT ring.

In the embodiment of the application, each node in the distributed storage system may be a device with a processing function. For example, the terminal device may be a mobile terminal, a notebook computer, a desktop computer, a server, or the like. And, each node in the distributed storage system can be divided into two types, namely a fixed node and a mobile node. Wherein, the fixed node can be a terminal device which basically does not move or has an IP address which is basically unchanged or rarely changed; the mobile node may refer to a terminal device that moves frequently or has a relatively large change in IP address. That is, the mobile node moves more frequently or the IP address changes relatively more than the fixed node. For example, the fixed node may include a desktop, a smart tv, a network attached storage (network attached storage, NAS) device, and a smart home gateway or other terminal device. The mobile node may include terminal devices such as smart phones, tablet computers, notebook computers, and portable computers.

In the embodiment of the present application, the storage nodes 10 in the DHT ring may be all fixed nodes, i.e. the DHT ring may be composed of fixed nodes. The sharing node 20 and the requesting node 30 may be fixed nodes or mobile nodes. When a certain node of the sharing node 20 and the requesting node 30 is a fixed node, the fixed node may be one storage node 10 in the DHT ring. When one of the sharing node 20 and the requesting node 30 is a mobile node, the mobile node may serve as a client of the DHT network, and access the DHT network through a preset fixed node.

Optionally, as shown in fig. 2, the distributed storage system provided in the embodiment of the present application may further include a user management server 40, where the user management server 40 may be configured to maintain and manage a user identifier (for example, a user ID) and device information of a terminal device that logs in to the user identifier, where the device information may include information of all fixed nodes and mobile nodes that log in to the user identifier. Wherein the information of each node may include the communication address of the node, the node type, etc. The user identifier may be an identifier registered when the user uses the terminal device, and synchronization of data or services between a plurality of terminal devices used by the same user may be achieved through the user identifier.

For example, assume that a user identified as UID1 has terminal device 1, terminal device 2, and terminal device 3, and that the 3 terminal devices may be mobile nodes or fixed nodes. The user management server 40 may manage 3 terminal devices that are logged into UID 1. For example, an online device that logs in UID1 is recorded, and its current IP address is registered.

Fig. 3 is a flowchart of a file sharing method according to an embodiment of the present application, where the method may be applied to a system as shown in fig. 1 or fig. 2. Referring to fig. 3, the method may include:

step 101, the sharing node divides the sharing file to be uploaded into a plurality of data blocks, and generates a header block of the sharing file.

In this embodiment of the present application, before the sharing node uploads the sharing file, the sharing file may be first partitioned to obtain a plurality of data partitions. Thereafter, the sharing node may generate a header partition of the shared file. The header partition may include an identification of each of the plurality of data partitions. Wherein the identification of each data chunk may be a string that uniquely represents the data chunk. For example, the identification of each data chunk may be a hash value obtained by hashing the data chunk. The hash operation may be a message digest algorithm fifth edition (message digest algorithm, MD 5) or a secure hash algorithm (secure hash algorithm, SHA), etc.

Optionally, the sharing file may be a streaming media file such as a video file or audio file, or may also be text or pictures. If the shared file is a video file, the header partition may further include metadata of the video file, where the metadata is data for describing the video file, and the metadata is data required by a player to play the video file. For example, the metadata may include data such as the encoding format of the video file, the title, the abstract, the author, the duration, the tag, the number of data chunks included, and the size of each data chunk.

For example, assume that a sharing file to be uploaded by a sharing node is a video file, and as shown in fig. 4, the sharing node blocks the video file to obtain BLK1 to BLKn common n data blocks, where n is an integer greater than 1. The header partition HEAD of the video file generated by the sharing node may include: metadata of the video file, and identifications CID1 to CIDn of the n data blocks.

In this embodiment of the present application, the sharing node may be a fixed node or a mobile node, which is not limited in this embodiment of the present application. Assuming that the sharing node is a mobile node, as shown in fig. 5, the mobile node may include a data storage module 01, where the data storage module 01 may be used to store each data chunk of the sharing file, and a header chunk.

Step 102, the sharing node sends the header block of the shared file to the storage node.

In this embodiment of the present application, if the sharing node is a mobile node, the sharing node may determine a storage node to be uploaded for the sharing file from a plurality of storage nodes included in the distributed storage system by means of pre-configuration, domain name resolution (domain name resolution, DNS), hypertext transfer protocol (hypertext transfer protocol, HTTP) redirection, or querying a user management server, and may send a header partition of the sharing file to the storage node.

For example, the sharing node may obtain information of a first fixed node (for example, an IP address of the first fixed node) from the user management server, where the first fixed node may be a fixed node corresponding to the same user identifier as the sharing node in the distributed storage system. And then, the sharing node can determine the first fixed node as a storage node for uploading the shared file, and send the file header block of the shared file to the first fixed node. Referring to fig. 5, the mobile node may further comprise a communication module 02, which communication module 02 may be used to interact with a fixed node in the distributed storage system, e.g. may send a header chunk to a first fixed node.

Fig. 6 is a schematic structural diagram of another distributed storage system provided in an embodiment of the present application, as shown in fig. 6, where a DHT network in the distributed storage system may include 5 fixed nodes 1 to 5 fixed nodes. Assuming that the sharing node 20 is a mobile node and the first fixed node determined by the sharing node 20 is the fixed node 1, the sharing node 20 may send the header block of the shared file to the fixed node 1 through the communication module 02.

It should be noted that, if the sharing node is a fixed node, the sharing node does not need to upload the header block and each data block of the sharing file to other storage nodes, that is, the sharing node may directly execute the methods shown in the following steps S1 and S2, and execute the method shown in step 107 after receiving the data acquisition request sent by the requesting node.

Step 103, for each data block, the storage node records the corresponding relation between the identification of the data block and the address of the sharing node in the to-be-transmitted list.

After receiving the header blocks of the shared file sent by the sharing node, the storage node can acquire the identification of each data block in the header blocks. And, for each data block, the storage node may record, in the to-be-transmitted list, a correspondence between the identifier of the data block and the address of the sharing node. The address of the sharing node may be an IP address of the sharing node. That is, the storage node may take the form of a key-value pair, and record, in the to-be-transmitted list, the identification of the data chunk to be uploaded to the storage node, and the address of the sharing node for uploading the data chunk. The identification of the data block is a primary key, and the address of the sharing node is a value.

For example, assuming that the IP address of the sharing node is IP1, the fixed node 1 may record the correspondence between the identifiers of the n data blocks and the address of the sharing node in the to-be-transmitted list shown in table 1. Referring to table 1, it can be seen that the addresses of the sharing nodes corresponding to the identifiers CID1 to CIDn of the data blocks are all IP1. In addition, the to-be-transmitted list also records the address IPk of the sharing node corresponding to the identifier CIDk of the data block, that is, the sharing node with the IP address IPk also uploads the data block to the fixed node 1.

TABLE 1

Identification of data chunks	Sharing addresses of nodes
		CID1	IP1
CID2	IP1
		...	...
CIDm	IP1
		...	...
CIDn	IP1
		CIDk	IPk

Fig. 7 is a schematic structural diagram of a storage node (i.e., a fixed node) according to an embodiment of the present application, as shown in fig. 7, the fixed node 10 may include a to-be-uploaded data management module 11, where the to-be-uploaded data management module 11 stores the to-be-transmitted list, and the to-be-uploaded data management module 11 may be used to maintain and manage the to-be-transmitted list.

Optionally, in the embodiment of the present application, after receiving the header chunk uploaded by the sharing node, the storage node may register the routing information of the data chunk into a certain storage node included in the distributed storage system based on the identifier of each data chunk in the header chunk. As shown in fig. 8, the procedure of registering the routing information is as follows:

Step S1, for each block in a file header block and a plurality of data blocks of a shared file, determining the identification of a target storage node for storing the routing information of the block according to the identification of the block and a distributed hash algorithm.

The storage node may calculate the ID of each chunk using a DHT algorithm, thereby determining an identity (i.e., a node ID) of a target storage node that is closest to the logical distance of the calculation result of the DHT algorithm among the plurality of storage nodes included in the distributed storage system. The DHT algorithm may be Chord algorithm or Kademlia algorithm.

By way of example, assuming that the storage node is fixed node 1, the fixed node 1 may calculate the ID of the header chunk separately: ID0, and ID of n data chunks: hash value of each ID in CID1 to CIDn. Thereafter, for the hash value of the ID of each chunk, the fixed node 1 may determine from the DHT network the ID of the fixed node whose hash value is closest to the hash value of the ID of the chunk. For example, for the data chunk 1 identified as CID1, if the fixed node 1 determines that the hash value of the ID of the fixed node 2 is the same as the hash value of the CID1, the target storage node for storing the header chunk and the routing information of the data chunk 1 may be determined to be the fixed node 2. For the header block identified as CID0 and the data block 2 identified as CID2, if the fixed node 1 determines that the hash value of the ID of the fixed node 5 is the same as the hash values of the two IDs, the target storage node for storing the routing information of the header block and the data block 2 may be determined as the fixed node 5.

And step S2, according to the identification of the target storage node, sending a route update instruction carrying the identification of the block to the target storage node.

The route update indication is used for indicating the target storage node to record the route information of the block in a route table, and the route information of the block can comprise: the identity of the partition, and the address of the storage node. That is, the storage address of the chunk in the routing information may point to the storage node that sent the routing update indication.

For example, fixed node 1 may send a route update indication carrying CID1 to fixed node 2 and may send route update indications carrying CID0 and CID2, respectively, to fixed node 5. As shown in fig. 6, after receiving the route update instruction, the fixed node 2 may record, in its routing table, the route information of the data block 1, where the route information includes: CID1, IP address of fixed node 1: NIP1. Similarly, the fixed node 5 may record, in response to the route update instruction, the route information of the file header partition and the route information of the data partition 2 in its route table, where the IP addresses in the route information of the two partitions are both the IP addresses of the fixed node 1: NIP1.

As can be seen from the above steps S1 to S2, in the embodiment of the present application, the storage node that receives the header block of the shared file may store the routing information of each of the header block and the plurality of data blocks on a fixed node whose hash value of the node identifier is the same as/similar to the hash value of the ID of the block, thereby implementing hash storage of the routing information of the header block and the plurality of data blocks.

Optionally, referring to fig. 7, each fixed node 10 may further include a routing table 12 and a communication module 13, where the routing table 12 may be used to record routing information of different blocks, and the communication module 13 may be used to interact information with other fixed nodes and user equipment management servers in the DHT network. For example, the fixed node 10 may send route update indications to other fixed nodes through the communication module 13.

Step 104, the sharing node uploads a plurality of data blocks to the storage node block by block.

After the sharing node finishes uploading the file header blocks to the storage node, the sharing node can start uploading the plurality of data blocks block by block to the storage node block by block. Accordingly, the storage node may receive the data chunks uploaded by the sharing node, chunk by chunk.

Optionally, the sharing node may add a plurality of data blocks to be uploaded to the upload queue according to a file sequence, and may upload the data blocks in the upload queue to the storage node block by block according to a first-in first-out principle. Wherein the file order is the presentation order (e.g., play order) of the files.

For example, if the sharing node is a mobile node, as shown in fig. 5, the mobile node may further include a data upload management module 03, where the data upload management module 03 may maintain at least one upload queue, and each upload queue may include a plurality of data blocks sharing a file.

It should be noted that, if the sharing node is a mobile node, the IP address of the mobile node may change during the process of uploading the data block. Therefore, in the embodiment of the present application, after detecting that the IP address of the sharing node changes, the sharing node may send an IP update indication to the storage node, where the IP update indication carries an updated IP address of the sharing node. After receiving the IP update instruction, the storage node may update the IP address of the sharing node recorded in the to-be-transmitted list with the updated IP address. That is, the storage node may timely refresh the to-be-transmitted list based on the updated IP address, so as to ensure timeliness of the IP address recorded in the to-be-transmitted list.

For example, referring to fig. 6, assuming that the sharing node 20 updates its IP address from IP1 to IPx after uploading the data blocks identified as CID1 and CID2 to the fixed node 1 through the communication module 02, the sharing node 20 may send an IP update indication to the fixed node 1 through the communication module 02. As shown in fig. 6, the fixed node 1 may respond to the IP update instruction by recording the IP address in the to-be-transmitted list: IP1 is updated as: IPx.

Step 105, the requesting node obtains the file header block.

After the sharing node uploads the header block of the shared file, the identifier of the header block may be shared to the requesting node in multiple manners (e.g., social software, mail, web page, etc.). The identifier of the header chunk may be a hash value of the header chunk. After the requesting node obtains the identifier of the header block, the header block may be obtained from the distributed storage system based on the identifier of the header block.

As an optional implementation manner, the request node may be a fixed node, and the request node may determine, according to the identifier of the header chunk and the DHT algorithm, the identifier of a storage node storing route information of the header chunk, and obtain route information of the header chunk from the storage node indicated by the identifier, and may further obtain the header chunk based on the route information. The routing information of the file header partition may include: the identification of the header chunk, and the address of the storage node storing the header chunk, which may be an IP address.

By way of example, as shown in fig. 7, the fixed node 10 may include a data query module 14, and the data query module 14 may be a module in the fixed node for querying routing information of data to be acquired. Assuming that the identifier of the header block is CID0, the data query module 14 in the requesting node calculates the identifier CID0 by using the DHT algorithm, and determines that the storage node storing the routing information of the header block is the fixed node 5. The requesting node may obtain the routing information of the header block from the fixed node 5 through the communication module 13 as shown in fig. 6. If the IP address corresponding to CID0 recorded in the routing information is the IP address of the fixed node 1: NIP 1), the communication module 13 of the requesting node may be based on the IP address: NIP1 obtains the header chunk from fixed node 1.

As another alternative implementation manner, the requesting node may be a mobile node, and the requesting node may obtain information (for example, an IP address) of a second fixed node from the user management server, where the second fixed node may be a fixed node corresponding to the same user identifier as the requesting node in the distributed storage system. And then, the request node can send a routing information inquiry instruction to the second fixed node, wherein the routing information inquiry instruction comprises the identification of the file header block. The request node can further obtain the routing information of the file header block through the second fixed node. The process of obtaining the routing information of the header partition by the second fixed node may be described above, and will not be described herein.

It should be appreciated that when the requesting node is a mobile node, the requesting node may not be deployed on the DHT ring and thus the requesting node cannot directly access the routing information stored in the DHT network. At this time, the requesting node may acquire the routing information from the second fixed node in the DHT ring through the communication module 02.

Step 106, the request node sends a data acquisition request to the storage node.

After the requesting node obtains the header block of the shared file, the requesting node can send a data obtaining request to the storage node based on the identifiers of the plurality of data blocks included in the header block. The data acquisition request may carry an identifier of the target data block to be played.

Optionally, the requesting node may display the sharing file according to a display sequence (e.g. a play sequence) of the sharing file, and may determine, according to an offset position of data to be displayed relative to the entire sharing file and a size of a data partition in the sharing file, a data partition to which the data to be displayed belongs, where the data partition is a target data partition to be played. Then, the requesting node may send a data acquisition request for the target data chunk to the storage node. In embodiments of the present application, the requesting node may send a data acquisition request for one target data chunk at a time. Alternatively, in order to improve the efficiency of data sharing, the requesting node may also send multiple data acquisition requests for different target data blocks at the same time.

It should be noted that, when the user of the requesting node needs to adjust the display sequence of the shared file, for example, when the user needs to fast forward to play the video file, the requesting node may determine the target data block to be played based on the display position indicated by the user.

For example, suppose the shared file is a video file, and metadata of the video file is further included in the header partition. The requesting node may start the player based on the metadata after it has acquired the header chunk. And, the requesting node may determine, based on the offset position of the video data to be played determined by the player with respect to the entire video file, the target data block to which the video data to be played belongs. And then, a data acquisition request carrying the identification of the target data block can be sent through the communication module. For example, if the requesting node plays the video file normally, the identifier of the target data block carried in the first data acquisition request sent by the requesting node may be CID1. If the request node receives a fast-forward instruction from the user when playing to the second data block identified as CID2, and determines that the target data block to be played is the mth data block based on the fast-forward instruction, the request node may send a data acquisition request carrying the identification CIDm of the target data block to the fixed node 1.

Step 107, the storage node detects whether the identification of the target data block is recorded in the local storage list.

In the embodiment of the application, a local storage list can be maintained in the storage node, and the identification of the blocks stored in the storage node is recorded in the local storage list. After receiving a data acquisition request carrying the identification of the target data block sent by the request node, the storage node can first detect whether the identification of the target data block is recorded in the local storage list.

If the identification of the target data chunk is not recorded in the local storage list, the storage node may determine that the target data chunk is not stored locally and may perform step 108. If the identification of the target data chunk is recorded in the local storage list, it may be determined that the target data chunk is stored locally, and step 113 may be performed.

The storage node records the identification of the locally downloaded block through the local storage list, so that when a data acquisition request from a request node is received, whether the target data block requested by the request node is locally stored or not can be quickly determined by inquiring the local storage list, and the efficiency of data block inquiry is effectively improved.

Illustratively, as shown in fig. 7, a data storage module 15 is further included in the fixed node, where the data storage module 15 may be configured to store the acquired blocks (including the header block and the data block, etc.), and to maintain the local storage list. Assuming that the identification of the target data block carried in the data acquisition request received by the fixed node 1 is CIDm, m is an integer greater than 2 and less than n, the local storage list stored in the data storage module 15 is shown in table 2 and fig. 6. Then the fixed node 1 may perform step 108 since the identity CIDm of the target data chunk is not recorded in the local storage list. If the identifier of the target data block carried in the data acquisition request received by the fixed node 1 is CID1, since the identifier CID1 of the target data block is recorded in the local storage list, the fixed node 1 may execute step 113.

TABLE 2

Identification of tiles

CID0

CID1

CID2

CIDj

Step 108, detecting whether the identification of the target data block is recorded in the to-be-transmitted list.

If the storage node detects that the target data block is not stored locally, the storage node can continue to detect whether the identification of the target data block is recorded in the to-be-transmitted list. If the identification of the target data chunk is recorded in the to-be-transmitted list, the storage node may execute step 109. If the identification of the target data chunk is not recorded in the to-be-transmitted list, the storage node may execute step 115.

By way of example, assuming that the identity of the target data chunk is CIDm, referring to table 1 and fig. 6, it can be seen that since the identity of the target data chunk is recorded in the to-be-transmitted list CIDm, the fixed node 1 may perform step 109. If the identification of the target data block is CIDP, then the fixed node 1 may execute step 115 because the identification of the target data block is not recorded in the to-be-transmitted list.

And step 109, determining the address of the sharing node corresponding to the identifier of the target data block in the to-be-transmitted list as the address of the target sharing node.

If the identifier of the target data block is recorded in the to-be-transmitted list in the storage node, the storage node can query the to-be-transmitted list by taking the identifier of the target data block as a primary key to obtain the address of the target sharing node for uploading the target data block. The to-be-transmitted list records the identification of the data block to be uploaded and the address of the corresponding sharing node in a key value pair mode, so that the efficiency of acquiring the address of the target sharing node can be improved.

For example, assuming that the identifier of the target data block is CIDm, the fixed node 1 may query the list to be transmitted shown in fig. 1 and fig. 6 by using the identifier CIDm as a primary key through the data management module to be uploaded 11, so as to determine that the address of the target sharing node is IPx.

Step 110, a priority uploading request is sent to the target sharing node.

In this embodiment of the present application, after determining the address of the target sharing node, the storage node may send, to the target sharing node, a priority upload request carrying the identifier of the target data block based on the address of the target sharing node. The priority upload request may be used to instruct the target sharing node to upload the target data chunk preferentially.

For example, the fixed node 1 may send a priority upload request to the sharing node 20 with the IP address IPx through the communication module 13, where the priority upload request may carry the identifier CIDm of the target data block.

In step 111, the target sharing node responds to the priority upload request to forward the upload sequence of the target data block.

After receiving the priority uploading request from the storage node, the target sharing node can adjust the uploading sequence of the target data blocks before based on the identification of the target data blocks carried by the priority uploading request, so that the target data blocks can be uploaded preferentially, and the requesting node can acquire the target data blocks in time.

Optionally, the sharing node may also forward the uploading sequence of the target number of data blocks located after the target data block. The target number may be a fixed value pre-stored in the sharing node. The sharing node also adjusts the uploading sequence of the target number of data blocks after the target data block, so that the target number of data blocks after the target data block can be received by the requesting node in time, and further continuity when the requesting node displays (e.g. plays) the shared file is ensured.

For example, assuming that the target sharing node is a mobile node, the data upload management module 03 of the mobile node may add a priority queue, and may adjust the target data block and the subsequent target number of data blocks from the original upload queue to the priority queue. The uploading priority of the priority queue is higher than that of the original uploading queue.

For example, assuming that the target number is 2 and the identifier of the target data block carried in the priority upload request is CIDm, as shown in fig. 6, the target sharing node 20 may add the target data block BLKm in the original upload queue S1 and two data blocks blkm+1 and blkm+2 after the target data block BLKm to the priority queue S2. The upload priority of the priority queue S2 is higher than that of the original upload queue S1, so the target sharing node 20 can upload the data blocks in the priority queue S2 preferentially.

Step 112, the target sharing node sends the target data block to the storage node.

The target sharing node can send the target data blocks to the requesting node preferentially before and after the uploading sequence of the target data blocks is adjusted. For example, the target sharing node may preferentially send the target data block BLKm in the priority queue S2 to the fixed node 1 through the communication module.

Step 113, the storage node sends the target data block to the requesting node.

After receiving the target data block sent by the target sharing node, the storage node can send the target data block to the requesting node. The requesting node may in turn present (e.g., play) the received target data chunk. For example, the fixed node 1 may send the target data block BLKm to the requesting node 30 via the communication module 13 for playback by the requesting node 30.

The storage node can instruct the target sharing node to upload the target data block requested by the request node preferentially, so that the request node can be ensured to acquire the target data block in time and display (e.g. play) the target data block, and real-time display in the downloading process of the sharing file is realized, namely the request node can start to display without waiting for the completion of downloading each data block in the sharing file.

And in the process that the request node downloads and displays the shared file, if the user of the request node instructs to adjust the display sequence of the shared file, the storage node can instruct the shared node to upload the adjusted display sequence preferentially, and then the target data to be displayed by the request node is partitioned, so that real-time display in the process of downloading the shared file is truly realized, and user experience is effectively improved.

It should be noted that, in this embodiment of the present application, after the storage node sends the target data block to the request node, if the storage node determines that the request node is a fixed node, the storage node may further send a route update instruction to the storage node storing the route information of the target data block again, where the route update instruction carries the identifier of the target data block and the address of the request node. After receiving the route update instruction, the storage node storing the route information of the target data block may update the route information of the target data block based on the address of the requesting node. That is, in the routing information of the target data block, the address of the requesting node is added to the address of the storage node corresponding to the identifier of the target data block. The storage node may determine, when determining the type of the request node, based on a data acquisition request sent by the request node, for example, may determine according to a structure type of the data acquisition request, or may determine according to a User Agent (UA) field in the data acquisition request.

Correspondingly, for a scenario that the routing information of the target data block includes addresses of a plurality of storage nodes, if other request nodes request to acquire the target data block subsequently, the other request nodes may send a data acquisition request to a storage node indicated by any address recorded in the routing information of the target data block, or may send a data acquisition request to all of the plurality of storage nodes indicated by the plurality of addresses.

For example, referring to fig. 6, assuming that the requesting node is the fixed node 5 and the identification of the target data chunk is CID1, after the fixed node 1 transmits the target data chunk to the fixed node 5, a route update indication may be transmitted to the fixed node 2 for storing route information of the target data chunk through the communication module 13, where the route update indication carries the IP address NIP5 of the fixed node 2. The fixed node 2 may further update the IP address corresponding to CID1 in the route information of the target data block to: NIP1 and NIP5.

In the scheme provided by the embodiment of the application, after the request node acquires the target data block, the storage node updates the routing information of the target data block based on the address of the request node, so that the distributed storage and query of the target data block can be realized.

Step 114, the storage node deletes the identification of the target data block from the to-be-transmitted list, and records the identification of the target data block into a local storage list.

In this embodiment of the present application, after receiving the target data block sent by the target sharing node, the storage node may further delete the identifier of the target data block from the to-be-transmitted list, and record the identifier of the target data block to the local storage list. Therefore, the list to be transmitted and the local storage list can be updated in time, and timeliness of identification of the data blocks recorded in the two lists is ensured.

For example, after receiving the target data block with the identifier CIDm uploaded by the sharing node, the fixed node 1 may delete the identifier CIDm of the target data block from the to-be-transmitted list shown in table 1 through the to-be-uploaded data management module 11, and add the identifier CIDm of the target data block to the local storage list shown in table 2. The updated to-be-transmitted list may be shown in table 3, and the updated local storage list may be shown in table 4.

TABLE 3 Table 3

Identification of data chunks	Sharing addresses of nodes
		CID1	IP1
CID2	IP1
		...	...
CIDn	IP1
		CIDk	IPk

TABLE 4 Table 4

Identification of tiles

CID0

CID1

CID2

CID2m

CIDj

Step 115, the storage node obtains the routing information of the target data block based on the identification of the target data block.

In this embodiment of the present application, if in step 108 described above, the storage node detects that the identifier of the target data block is not recorded in the to-be-transmitted list, the storage node may determine that the node for storing the target data block is another storage node. At this time, the storage node may acquire the routing information of the target data block based on the identification of the target data block.

Optionally, the storage node may search the routing information of the target data block from the routing table, and if the routing information of the target data block is recorded in the routing table of the storage node, the storage node may directly obtain the routing information. If the routing information of the target data block is not recorded in the routing table of the storage node, the storage node may calculate the identifier of the data block closest to the logical distance of the identifier of the target data block in the routing table by adopting a DHT algorithm. And then, the storage node can acquire the route information of the data block with the nearest logical distance, and send a route information inquiry instruction to the storage node indicated by the IP address in the route information, wherein the route information inquiry instruction comprises the identification of the target data block. That is, the storage node may use the IP address in the routing information as the address of the next hop, and continue to search for the routing information of the target data block.

For example, as shown in fig. 6, assuming that the current storage node is fixed node 1, the identification of the target data chunk is CIDp. If the IP address corresponding to the identifier CIDp is not recorded in the routing table of the fixed node 1, and the fixed node 1 calculates by adopting the DHT algorithm to obtain the identifier CIDq of the data block closest to the logical distance of the identifier CIDp in the routing table, where the IP address corresponding to the identifier CIDq is the IP address of the fixed node 3: NIP3. The fixed node 1 may send a routing information query instruction to the fixed node 3, where the routing information query instruction carries the identification CIDp of the target data block. Referring to fig. 6, since the fixed node 3 stores therein the route information of the target data block identified as CIDp, the fixed node 3 can transmit the route information of the target data block to the fixed node 1.

Step 116, the storage node obtains the addresses of other storage nodes storing the target data block from the routing information of the target data block.

Wherein the addresses of the other storage nodes may be IP addresses. For example, assuming that the identifier of the target data block is CIDp, as shown in fig. 6, the IP address recorded in the routing information of the target data block is the IP address of the fixed node 4, where the fixed node 1 obtains the IP address from the fixed node 3: NIP4. The fixed node 1 may determine the IP address of the other storage node for storing the target data chunk identified as CIDp as NIP4.

Step 117, the storage node sends the addresses of the other storage nodes to the requesting node.

After receiving the addresses of the other storage nodes, the request node can send a data acquisition request carrying the target data block to the other storage nodes based on the addresses of the other storage nodes. After receiving the data acquisition request, the other storage node may send the target data block to the requesting node by the method shown in steps 107 to 113.

By way of example, referring to fig. 6, the fixed node 1 may send the IP address of the fixed node 4 to the requesting node 30 via the communication module 13: NIP4. The requesting node 30 may in turn send a data acquisition request carrying the identity CIDp of the target data chunk to the fixed node 4 based on the IP address. After receiving the data acquisition request, the fixed node 4 may directly send the target data block identified as CIDp to the requesting node, since the local storage list thereof records the identifier CIDp of the target data block.

It should be noted that, the sequence of the steps of the file sharing method provided in the embodiment of the present application may be appropriately adjusted, and the steps may also be increased or decreased accordingly according to the situation. For example, step 105 and step 106 may be performed before step 104, step 114 may be performed before step 113, or performed in synchronization with step 113. Any method that can be easily conceived by those skilled in the art within the technical scope of the present disclosure should be covered in the protection scope of the present application, and thus will not be repeated.

In summary, the embodiment of the present application provides a file sharing method, after a storage node receives a data acquisition request from a requesting node, if an identifier of a target data block carried by the data acquisition request is recorded in a to-be-transmitted list, a priority upload request may be sent to a sharing node for uploading the target data block, so that the sharing node may preferentially upload the target data block, and then the storage node may timely send the target data block to the requesting node. That is, the storage node may instruct the sharing node to adjust the order of uploading the data blocks according to the order in which the requesting node requests the data blocks, so as to meet the data block display requirement (e.g. video playing requirement) of the requesting node. Accordingly, the requesting node can display the sharing file in real time based on the acquired data blocks in the downloading process of the sharing file, for example, play the video file in real time, without waiting for the display after the complete downloading of the sharing file. According to the scheme provided by the application, the real-time display of the shared file in the downloading process is realized, the file sharing efficiency is effectively improved, and the user experience is improved.

In addition, because the scheme provided by the embodiment of the application can store the sharing file in the distributed storage system, even if the sharing node is not on line, the request node can acquire the sharing file from the distributed storage system, so that the real-time acquisition of the sharing file is realized.

Fig. 9 is a schematic structural diagram of a storage node according to an embodiment of the present application, where the storage node may be applied to the system shown in fig. 1, fig. 2, or fig. 6. As shown in fig. 9, the storage node may include:

the receiving module 201 is configured to receive a data acquisition request from a requesting node, where the data acquisition request carries an identifier of a target data block. The functional implementation of the receiving module 201 may refer to the relevant description of step 106 in the above-described method embodiment.

The first determining module 202 may be configured to determine, if the target data block is not stored in the storage node and the identifier of the target data block is recorded in the to-be-transmitted list, an address of a target sharing node for uploading the target data block according to the identifier of the target data block. The functional implementation of the first determination module 202 may refer to the relevant description of step 109 in the above-described method embodiment.

The sending module 203 may be configured to implement the method shown in step 110 in the above method embodiment.

The receiving module 201 may be further configured to receive the target data chunk uploaded by the target sharing node. The functional implementation of the receiving module 201 may also refer to the relevant description of step 112 in the above-described method embodiment.

The sending module 203 may also be configured to implement the method shown in step 113 in the above method embodiment.

Optionally, the correspondence between the identifier of the data block to be uploaded and the address of the sharing node is recorded in the to-be-transmitted list. The first determining module 202 may be configured to implement the methods shown in step 108 and step 109 in the above-described method embodiments.

Optionally, the receiving module 201 may be further configured to receive a header partition of the shared file sent by the sharing node, where the shared file includes a plurality of data partitions, and the header partition includes an identifier of each data partition. The functional implementation of the receiving module 201 may also refer to the relevant description of step 102 in the above-described method embodiment.

As shown in fig. 9, the storage node may further include: a first recording module 204, configured to implement the method shown in step 103 and the method shown in step 114 in the above method embodiment.

Optionally, the address of the sharing node is an IP address. The receiving module 201 may be further configured to receive an IP update indication sent by the sharing node, where the IP update indication carries an updated IP address of the sharing node.

The first recording module 204 may be further configured to update the IP address of the sharing node recorded in the to-be-transmitted list with the updated IP address.

Optionally, as shown in fig. 9, the storage node may further include:

the second determining module 205 is configured to implement the method shown in step S1 in the above method embodiment.

The sending module 203 may be further configured to implement the method shown in step S2 in the above method embodiment.

Optionally, as shown in fig. 9, the storage node may further include:

a second recording module 206, configured to record the identification of the target data block into a local storage list. The second recording module 206 may be functionally implemented by referring to the method shown in step 114 in the above-described method embodiment.

The first determining module 202 may also be configured to implement the method shown in step 108 in the method embodiment described above.

In summary, the embodiment of the present application provides a storage node, after receiving a data acquisition request from a requesting node, if an identifier of a target data block carried by the data acquisition request is recorded in a to-be-transmitted list, the storage node may send a priority upload request to a sharing node for uploading the target data block, so that the sharing node may preferentially upload the target data block, and the storage node may further send the target data block to the requesting node in time. Therefore, the requesting node can display the sharing file in real time based on the acquired data blocks in the downloading process of the sharing file, for example, play the video file in real time, and does not need to wait for the whole downloading of the sharing file to be displayed. According to the scheme provided by the application, the real-time display of the shared file in the downloading process is realized, the file sharing efficiency is effectively improved, and the user experience is improved.

Fig. 10 is a schematic structural diagram of a sharing node according to an embodiment of the present application, where the sharing node may be applied to the system shown in fig. 1, fig. 2, or fig. 6. As shown in fig. 10, the sharing node may include:

the sending module 301 may be configured to implement the method shown in step 102 in the above method embodiment.

The sending module 301 may also be configured to implement the method shown in step 104 in the above method embodiment.

A receiving module 302, configured to receive a priority upload request from the storage node, where the priority upload request carries an identifier of a target data partition in the plurality of data partitions. The functional implementation of the receiving module 302 may refer to the method shown in step 110 in the above-described method embodiment.

The adjustment module 303 may be configured to implement the method shown in step 111 in the method embodiment described above.

Optionally, the adjusting module 303 may be further configured to: the uploading sequence of the target number of data blocks located after the target data block is adjusted before.

In summary, the embodiment of the present application provides a sharing node, where after receiving a request for preferential uploading carrying an identifier of a target data block, the sharing node may preferentially upload the target data block to a storage node, and the storage node may further send the target data block to a requesting node in time. Therefore, the requesting node can display the sharing file in real time based on the acquired data blocks in the downloading process of the sharing file, for example, play the video file in real time, and does not need to wait for the whole downloading of the sharing file to be displayed. According to the scheme provided by the application, the real-time display of the shared file in the downloading process is realized, the file sharing efficiency is effectively improved, and the user experience is improved.

It should be appreciated that the storage node or shared node of embodiments of the present application may also be implemented as an application specific integrated circuit (application specific integrated circuit, ASIC), a programmable logic device (programmable logic device, PLD), which may be a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof. The file sharing method provided by the method embodiment can also be implemented by software, and when the file sharing method provided by the method embodiment is implemented by software, each module in the storage node or the sharing node can also be a software module.

Fig. 11 is a block diagram of a file sharing device according to an embodiment of the present application, where the device may be configured in a storage node or a sharing node provided in the foregoing embodiment. Referring to fig. 11, the apparatus may include: a processor 1201, a memory 1202, an interface 1203, and a bus 1204. Wherein a bus 1204 is used to connect the processor 1201, the memory 1202 and the interface 1203. Communication connections with other devices may be made through interface 1203 (which may be wired or wireless). The memory 1202 stores therein a computer program 12021, and the computer program 12021 is used to realize various application functions.

It should be appreciated that in embodiments of the present application, the processor 1201 may be a CPU, and the processor 1201 may also be other general purpose processors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), GPUs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or any conventional processor or the like.

Memory 1202 may be a non-volatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory.

The bus 1204 may include a power bus, a control bus, a status signal bus, and the like in addition to a data bus. But for clarity of illustration, the various buses are labeled as bus 1204 in the figure.

The processor 1201 is configured to execute computer programs stored in the memory 1202. If the file sharing device is configured in a storage node, the processor 1201 can implement the steps performed by the storage node in the above-described method embodiment by executing the computer program 12021. If the file sharing device is configured in a sharing node, the processor 1201 can implement the steps performed by the sharing node in the above-described method embodiment by executing the computer program 12021.

The present embodiment also provides a distributed storage system, which can be seen in conjunction with fig. 1, 2 and 6, and the system may include a plurality of storage nodes 10, a sharing node 20 and a requesting node 30. The storage node 10 may be a node as shown in fig. 9, or may include a file sharing device as shown in fig. 11. The sharing node 20 may be a node as shown in fig. 10, or may include a file sharing device as shown in fig. 11.

Alternatively, the distributed storage system provided by embodiments of the present application may be an interplanetary file system (interplanetary file system, IPFS), which is a network transmission system capable of persistent and distributed storage and sharing of files. The IPFS has at least eight layers of sub-protocol stacks, namely identity, network, route, exchange, object, file, naming and application sub-protocol stacks from top to bottom, and each of the eight layers of sub-protocol stacks has the function of being matched with each other. The IPFS system can enable files (including words, pictures, sounds, videos, codes and the like) stored on the IPFS system to be quickly acquired by devices located in different physical locations through an underlying protocol, and is not affected by a firewall.

Each file block (including a file header block and a data block) stored in the IPFS system, after the IPFS system hashes the file block, a unique content identifier (i.e., a content ID or a block ID) is generated, and the file block can be accessed and acquired through the content identifier. And the content identification of each file block can be shared, and the content identification has the characteristics of tamper resistance and deletion due to the protection of an encryption algorithm. Thus, the file blocks can be stored in the IPFS system in a lasting manner.

The embodiment of the application also provides a chip, which may include: programmable logic and/or program instructions, when the chip is running, are used to implement the file sharing method provided by the method embodiments described above.

Embodiments of the present application also provide a computer program product comprising instructions which, when run on a processor, cause the processor to perform the steps of the method embodiments described above.

In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a alone, a and B together, and B alone, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The foregoing description of the exemplary embodiments of the present application is not intended to limit the invention to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, alternatives, and alternatives falling within the spirit and scope of the invention.

Claims

1. A method for sharing files, applied to a storage node, the method comprising:

receiving a data acquisition request from a request node, wherein the data acquisition request carries an identification of a target data block;

if the target data block is not stored in the storage node and the identification of the target data block is recorded in the to-be-transmitted list, determining the address of a target sharing node for uploading the target data block according to the identification of the target data block;

based on the address of the target sharing node, sending a priority uploading request carrying the identification of the target data block to the target sharing node, wherein the priority uploading request is used for indicating the target sharing node to upload the target data block preferentially;

Receiving the target data block uploaded by the target sharing node;

and sending the target data block to the request node.

2. The method of claim 1, wherein the correspondence between the identification of the data block to be uploaded and the address of the sharing node is recorded in the to-be-transmitted list; the determining, according to the identification of the target data block, an address of a target sharing node for uploading the target data block includes:

and determining the address of the sharing node corresponding to the identification of the target data block in the to-be-transmitted list as the address of the target sharing node.

3. The method according to claim 2, wherein the method further comprises:

receiving a file header block of a sharing file sent by the target sharing node, wherein the sharing file comprises a plurality of data blocks, and the file header block comprises an identifier of each data block;

for each data block, recording the corresponding relation between the identification of the data block and the address of the target sharing node in the to-be-transmitted list;

after receiving the target data chunk uploaded by the target sharing node, the method further comprises:

And deleting the identification of the target data block from the to-be-transmitted list.

4. The method of claim 3, wherein the address of the target sharing node is a network protocol IP address; after the corresponding relation between the identification of the data block and the address of the target sharing node is recorded in the to-be-transmitted list, the method further comprises:

receiving an IP update instruction sent by the target sharing node, wherein the IP update instruction carries an updated IP address of the target sharing node;

and updating the IP address of the target sharing node recorded in the to-be-transmitted list by adopting the updated IP address.

5. The method according to claim 3 or 4, wherein after receiving a header chunk of the shared file sent by the target sharing node, the method further comprises:

for each of the file header block and the plurality of data blocks, determining an identification of a target storage node for storing routing information of the block according to the identification of the block and a distributed hash algorithm;

according to the identification of the target storage node, sending a route update instruction carrying the identification of the block to the target storage node, wherein the route update instruction is used for instructing the target storage node to record the route information of the block in a route table, and the route information of the block comprises: the identity of the partition, and the address of the storage node.

6. The method of any of claims 1 to 4, wherein after receiving the target data chunk uploaded by the target sharing node, the method further comprises:

recording the identification of the target data block into a local storage list;

after the receiving the data acquisition request from the requesting node, the method further comprises:

and if the identification of the target data block is not recorded in the local storage list, determining that the target data block is not stored in the storage node.

7. The file sharing method is characterized by being applied to sharing nodes, and comprises the following steps:

transmitting a file header block of a shared file to a storage node, wherein the shared file comprises a plurality of data blocks, and the file header block comprises an identifier of each data block;

uploading a plurality of the data blocks block by block to the storage node;

receiving a priority uploading request from the storage node, wherein the priority uploading request carries the identification of a target data block in a plurality of data blocks;

and responding to the priority uploading request, and calling the uploading sequence of the target data blocks.

8. The method of claim 7, wherein before and after the order of uploading the target data chunks, the method further comprises:

And adjusting the uploading sequence of the target number of data blocks positioned after the target data blocks.

9. A storage node, the storage node comprising:

the receiving module is used for receiving a data acquisition request from a request node, wherein the data acquisition request carries the identification of the target data block;

the first determining module is used for determining an address of a target sharing node for uploading the target data block according to the identification of the target data block if the target data block is not stored in the storage node and the identification of the target data block is recorded in a to-be-transmitted list;

the sending module is used for sending a priority uploading request carrying the identification of the target data block to the target sharing node based on the address of the target sharing node, wherein the priority uploading request is used for indicating the target sharing node to upload the target data block preferentially;

the receiving module is further configured to receive the target data block uploaded by the target sharing node;

the sending module is further configured to send the target data block to the requesting node.

10. The storage node according to claim 9, wherein the correspondence between the identifier of the data block to be uploaded and the address of the sharing node is recorded in the to-be-transmitted list; the first determining module is configured to:

11. The storage node of claim 10, wherein the storage node comprises a plurality of storage nodes,

the receiving module is further configured to receive a header partition of a shared file sent by the target sharing node, where the shared file includes a plurality of data partitions, and the header partition includes an identifier of each data partition;

the storage node further comprises: the first recording module is used for recording the corresponding relation between the identification of the data block and the address of the target sharing node in the to-be-transmitted list for each data block;

the first recording module is further configured to delete, after the receiving module receives the target data chunk uploaded by the target sharing node, an identifier of the target data chunk from the to-be-transmitted list.

12. The storage node of claim 11, wherein the address of the target sharing node is a network protocol IP address;

the receiving module is further configured to receive an IP update indication sent by the target sharing node, where the IP update indication carries an updated IP address of the target sharing node;

And the first recording module is further used for updating the IP address of the target sharing node recorded in the to-be-transmitted list by adopting the updated IP address.

13. The storage node according to claim 11 or 12, characterized in that the storage node further comprises:

a second determining module, configured to determine, for each of the file header partition and the plurality of data partitions, an identifier of a target storage node for storing routing information of the partition according to the identifier of the partition and a distributed hash algorithm;

the sending module is further configured to send, to the target storage node, a route update instruction carrying the identifier of the partition according to the identifier of the target storage node, where the route update instruction is used to instruct the target storage node to record route information of the partition in a route table, and the route information of the partition includes: the identity of the partition, and the address of the storage node.

14. The storage node according to any of claims 9 to 12, wherein the storage node further comprises:

the second recording module is used for recording the identification of the target data block into a local storage list;

The first determining module is further configured to determine that the target data chunk is not stored in the storage node if the identifier of the target data chunk is not recorded in the local storage list.

15. A sharing node, the sharing node comprising:

the file head partitioning module is used for sending a file head partitioning block of a sharing file to the storage node, wherein the sharing file comprises a plurality of data partitioning blocks, and the file head partitioning block comprises an identifier of each data partitioning block;

the sending module is further configured to upload a plurality of the data blocks block by block to the storage node;

the receiving module is used for receiving a priority uploading request from the storage node, wherein the priority uploading request carries the identification of a target data block in a plurality of data blocks;

and the adjusting module is used for responding to the priority uploading request and adjusting the uploading sequence of the target data blocks.

16. The sharing node of claim 15, wherein the adjustment module is further configured to:

17. A file sharing apparatus, the apparatus comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the file sharing method according to any one of claims 1 to 6 or the file sharing method according to claim 7 or 8 when executing the computer program.

18. A non-volatile storage medium having instructions stored therein that, when executed on a processor, cause the processor to perform the file sharing method of any one of claims 1 to 6, or the file sharing method of claim 7 or 8.

19. A distributed storage system, the system comprising: a plurality of storage nodes according to any one of claims 9 to 14, a sharing node according to claim 15 or 16, and a requesting node.