WO2020006822A1 - 一种获取bt资源信息的方法和设备 - Google Patents

一种获取bt资源信息的方法和设备 Download PDF

Info

Publication number
WO2020006822A1
WO2020006822A1 PCT/CN2018/101518 CN2018101518W WO2020006822A1 WO 2020006822 A1 WO2020006822 A1 WO 2020006822A1 CN 2018101518 W CN2018101518 W CN 2018101518W WO 2020006822 A1 WO2020006822 A1 WO 2020006822A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
target
bitmap
data
peer
Prior art date
Application number
PCT/CN2018/101518
Other languages
English (en)
French (fr)
Inventor
陈凯林
Original Assignee
网宿科技股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 网宿科技股份有限公司 filed Critical 网宿科技股份有限公司
Priority to EP18925702.5A priority Critical patent/EP3820063A4/en
Priority to US16/617,358 priority patent/US11190584B2/en
Publication of WO2020006822A1 publication Critical patent/WO2020006822A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • H04L1/0007—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length
    • H04L1/0008—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length by supplementing frame payload, e.g. with padding bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1042—Peer-to-peer [P2P] networks using topology management mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1076—Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data

Definitions

  • the present invention relates to the technical field of data transmission, and in particular, to a method and device for acquiring BT resource information.
  • BT (BitTorrent, Bitstream) protocol is a computer communication protocol, which is widely used for BT resource sharing between BT clients in peer-to-peer networks.
  • the BT client needs to determine the request from the peer based on the meta information of the BT resources (including the total size of the BT resource, the number of data slices of the BT resource, and the size of each data slice). How many data slices, and how many data blocks each data slice has to request.
  • a BT client After receiving a BT resource acquisition request sent by a peer, a BT client finds that the meta-information of the corresponding BT resource is not available locally, and then obtains the meta-information mainly through the following two existing methods: First, the BT client The client can retrieve the corresponding seed file from the local or remote seed bank according to the info and hash of the BT resource carried in the BT resource acquisition request, and then read the meta information of the BT resource contained in the seed file. Second, the BT client is communicating with After the terminal completes the "Handshake", it requests meta information of the BT resource from the peer or other peers that are sharing the BT resource.
  • the peer or other peer does not support the BT protocol extension of "ut_metadata", and the peer or other peer does not respond to the request for meta information.
  • the client cannot obtain the meta information of the BT resource, and the BT client cannot respond to the request sent by the peer or other peer.
  • embodiments of the present invention provide a method and device for acquiring BT resource information.
  • the technical solution is as follows:
  • a method for acquiring BT resource information includes steps:
  • the inverting the bitmap A and feeding back the new bitmap B obtained by the inversion to the peer end includes:
  • bitmap of the target BT resource is not stored locally, the bitmap A is inverted, and the new bitmap B obtained from the inversion is fed back to the peer, otherwise the local storage is fed back to the peer.
  • bitmap of the target BT resources are not stored locally.
  • the feedback of the bitmap of the target BT resource stored locally to the peer end includes:
  • the peer end does not store all the data slices of the target BT resource stored locally, feedback the bitmap of the target BT resource stored locally to the peer end; otherwise, invert the bitmap A , Feeding the new bitmap B obtained by reversal to the peer end.
  • the predicting the data slice size of the target BT resource according to the offset in the data block acquisition request includes:
  • the offset in the data block acquisition request is greater than the known data block offset of the target BT resource, updating the data slice of the target BT resource according to the offset in the data block acquisition request size.
  • the method further includes:
  • the method further includes:
  • the storage situation of each data block of the target BT resource locally is recorded in the form of a two-dimensional array.
  • the method further includes:
  • the method is implemented by a cache server.
  • the BT when the BT resource data is exchanged with the peer end, if the local end does not have the meta information of the BT resource, the BT can be determined based on the bitmap A of the BT resource sent by the peer end after the BT protocol handshake. The number of data pieces of the resource, and then invert the bitmap A, and feedback to the opposite end to obtain the bitmap B, so as to trigger the opposite end to send a data block acquisition request of the BT resource to the local end, so that the data block acquisition request can be based on To predict the data slice size of the BT resource, the resource information of the BT resource can be obtained. Further, the local end may download the data block of the BT resource from the peer end based on the acquired BT resource information.
  • an embodiment of the present invention further provides a device for acquiring BT resource information.
  • the device runs a computer program, and the computer program can implement the method of the foregoing embodiment.
  • the device is a cache server.
  • FIG. 1 is a flowchart of a method for acquiring BT resource information according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a request response system according to an embodiment of the present invention.
  • An embodiment of the present invention provides a method for acquiring BT resource information, which can be applied to a BT system.
  • the BT system can face the entire Internet, and a BT client can perform BT resource data transmission with other BT clients through the BT protocol.
  • the meta information provides resource information such as the total size of the BT resource (in bytes), how many data slices it contains, and the size of each data slice. If a BT client lacks these resource information, it does not know how many data slices it wants to request from the peer, and how many data blocks each data slice needs to request.
  • the method provided in this example can predict the resource information of BT resources based on the bitmap and data block acquisition request of the BT resources provided by the peer, so that the BT client does not have meta information of BT resources, or cannot obtain BT in the normal way. In the case of resource meta-information, data transmission of BT resources with the peer can still be performed.
  • Step 101 After performing a handshake with the opposite end, receive a bitmap A of the target BT resource sent by the opposite end.
  • the BT client may first establish communication with the peer (which may be referred to as the peer later). After the connection, the two parties exchange basic information for data transmission through handshake, including the info hash value of the target BT resource, their respective device IDs, and other extended information (such as whether to support the DHT mode, whether to support the "ut_metadata" protocol extension, etc.)
  • the BT client may wait for the peer to send a bitmap A of the target BT resource maintained by the peer.
  • the bitmap A can reflect the download completion of the data piece of the BT resource in the peer end.
  • Each bit in the bitmap (including 8 binary bits in one byte) indicates whether the data piece of the corresponding BT resource has been downloaded.
  • the BT client obtains the bitmap A of the target BT resource, it can determine the number of data slices contained in the target BT resource according to the binary digits in the bitmap A.
  • Step 102 Invert the bitmap A, and feed back the new bitmap B obtained by the inversion to the opposite end.
  • the BT client can invert the bitmap A, that is, change the value of the binary digit in the bitmap A to 0 and the binary digit to 1. Change to 0 to get a new bitmap B. Then the BT client can feedback the new bitmap B obtained from the inversion to the peer.
  • the processing in step 102 may be as follows: If the bitmap of the target BT resource is not stored locally, then The bitmap A is inverted, and the new bitmap B obtained from the inversion is fed back to the peer, otherwise the bitmap of the target BT resource stored locally is fed back to the peer.
  • the BT client may first determine whether the bitmap of the target BT resource has been stored locally. If it is not stored, the BT client can invert the bitmap A, and then feed the new bitmap B obtained from the inversion to the peer; if it has been stored, the BT client can feedback the locally stored target to the peer. Bitmap of BT resources.
  • the bitmap of the target BT resource stored locally is, in one case, the bitmap of the target BT resource obtained by the BT client in a normal manner, and in another case, the BT client uses the solution of this embodiment to predict The obtained bitmap of the target BT resource. Therefore, compared with the process of directly inverting the opposite bitmap, the peer can actually obtain the data block of the target BT resource from the BT client based on the bitmap stored by the BT client. .
  • the bitmap obtained by inversion may still be fed back, and the corresponding processing may be as follows: if the opposite end does not store all data of the target BT resource stored locally Slice, the bitmap of the target BT resource stored locally is fed back to the peer, otherwise the bitmap A is inverted, and the new bitmap B obtained by the inversion is fed back to the peer.
  • the two bitmaps can be compared first. If it is found that the peer does not store all the data slices of the target BT resource stored locally, the BT client can feedback the bit map of the target BT resource stored locally to the peer; and if the bit map of the peer completely covers the locally stored bits The image, that is, the data slice of the target BT resource stored locally, has been stored on the opposite end. At this time, the BT client can invert the bitmap A sent by the opposite end, and then feedback the new bitmap B obtained from the inversion to Peer.
  • the peer bitmap completely covers the locally stored bitmap, if the locally stored bitmap is still fed back to the peer, during this interaction, the peer will not send any information to the BT client.
  • the data block acquisition request of the target BT resource In this way, the BT client cannot use the data block acquisition request to further predict the data slice size of the target BT resource.
  • Step 103 Receive a data block acquisition request for a target BT resource sent by a peer end.
  • the peer can base on the new bit Figure B, sending a data block acquisition request of a target BT resource to a BT client.
  • the BT client can thus receive the corresponding data block acquisition request.
  • Step 104 Predict the data slice size of the target BT resource according to the offset in the data block acquisition request.
  • the BT client after the BT client receives a data block acquisition request from the peer, it can predict the data slice size of the target BT resource according to the offset in the data block acquisition request.
  • the data block acquisition request may specify that a segment of byte data of a specific piece of data is to be obtained, and the byte data may be located by an offset, that is, the starting position of the requested byte data is at The few bytes in the data slice, and since the size of each data block in the BT resource is a fixed 16KB, it can be predicted that the data slice contains at least a few data blocks based on the offset.
  • each BT resource is generally divided into multiple data pieces of the same size. Except for the last data piece, the size of the other data pieces are the same. Therefore, each data piece of the target BT resource can be included based on the prediction. The number of data blocks to predict the data slice size of the target BT resource.
  • the last data slice of the BT resource is inconsistent with the size of other data slices, the last data slice can be processed separately, that is, the offset in the request to obtain the data block for the last data slice To predict the last data slice size of the target BT resource.
  • the processing of steps 101 to 104 above mainly provides a method for performing resource information on BT resources in the case that the meta information of the BT resources cannot be obtained based on the normal manner given in the background art.
  • the prediction method therefore, before performing step 101, if the BT client does not store the meta information of the BT resource, the meta information of the BT resource can be obtained in the normal manner described above, and if the acquisition fails, then The resource information of the BT resource can be predicted according to the method given in step 101 to step 104 in this embodiment.
  • the processing in step 104 may be as follows: If the offset in the data block acquisition request is greater than the known data block offset of the target BT resource, the data slice size of the target BT resource is updated according to the offset in the data block acquisition request.
  • the BT client can obtain the offset carried by the data block acquisition request, and then offset the offset from the data block of the known target BT resource. For comparison, if the offset in the data block acquisition request is greater than the data block offset of the known target BT resource, the BT client can update the data of the target BT resource according to the offset in the data block acquisition request. Slice size.
  • the data block offset of the target BT resource known by the BT client is 0x8000
  • the data slice size of the target BT resource is predicted to be 48KB.
  • the offset in the data block acquisition request received this time is 0xc000, which is greater than 0x8000, so based on the current offset 0xc000, the size of the data slice for updating the target BT resource is 64KB.
  • the known data block of the target BT resource may be predicted by the BT client based on the previous data block acquisition request of the target BT resource, and the previous data block acquisition request may be sent by the peer end or may be When the BT client interacts with other peers, other peers send it to the BT client.
  • the BT client may download the BT resource based on the obtained BT resource information, and the corresponding processing may be as follows: according to the bitmap A and the predicted data slice size of the target BT resource, Obtain the data block of the target BT resource from the peer.
  • the BT client after the BT client predicts the data slice size of the target BT resource, it can determine the data slices of all the target BT resources stored by the peer according to the bitmap A, and then further determine based on the predicted data slice sizes of the target BT resource.
  • the data blocks of all target BT resources stored by the peer end, and further, the BT client can judge the locally unstored data blocks among the data blocks of the target BT resource stored by the peer end, so that the BT client can obtain these locally unstored data blocks. While the peer has stored the data block of the target BT resource.
  • the target BT resource actually contains 5 data slices.
  • the BT client predicts that each data slice contains at least 3 data blocks through the above method.
  • the bitmap A is 10110, and the BT client already stores the top 2 3 data blocks of the first data slice and the first 2 data blocks of the third data slice, so the BT client can determine that the data block that the peer has stored but not stored locally is the third data of the third data slice Block and the first three data blocks of the fourth data slice. In this way, the BT client can obtain the above data block from the peer by sending a data block acquisition request to the peer.
  • the BT client updates the data slice size of the target BT resource, it needs to re-determine the data block stored locally and the data block stored locally, and then Continue to obtain locally unstored data blocks from the peer.
  • a two-dimensional array can be used to record the data storage of the BT resource.
  • the corresponding processing can be as follows: the number of data blocks in each data slice is the length of the first dimension, and the number of data slices is the first The two-dimensional length records the storage situation of each data block of the local target BT resource in the form of a two-dimensional array.
  • the number of data blocks in each data slice can be the length of the first dimension, and the number of data slices can be the length of the second dimension.
  • the form of an array records the storage situation of each data block of the local target BT resource.
  • a, b, c, and d represent data pieces, and 1, 2, 3, and 4 represent data pieces, then a4 represents the fourth data piece of the a-th data piece, and the two-dimensional array is (a1, b1 , C1, d1), (a2, b2, c2, d2), (a3, b3, c3, d3), (a4, b4, c4, d4).
  • the two-dimensional array is (a1, b1 , C1, d1), (a2, b2, c2, d2), (a3, b3, c3, d3), (a4, b4, c4, d4).
  • a new data group is correspondingly added at the end of the first dimension of the two-dimensional array.
  • the BT client selects a two-dimensional array to record the storage of the data block of the target BT resource, if the predicted data slice size of the target BT resource increases, it can be directly at the end of the first dimension of the two-dimensional array. Correspondingly add a new data set.
  • the existing two-dimensional array is (a1, b1, c1, d1), (a2, b2, c2, d2), (a3, b3, c3, d3), (a4, b4, c4, d4), if The size of the predicted data slice of the target BT resource is increased to 5, and a data group (a5, b5, c5, d5) can be added correspondingly at the end of the first dimension of the two-dimensional array. It can be seen that because the number of data slices of BT resources is generally significantly larger than the number of data blocks contained in one data slice, the above two-dimensional array record is selected. In the process of updating the two-dimensional array, it is not necessary to traverse all the arrays, which can save Memory and CPU usage.
  • This embodiment also provides a method for obtaining BT resource information by a cache server.
  • the cache server may be deployed in the request response system shown in FIG. 2.
  • the request response system includes a request response device 201 and at least one cache server.
  • 202 illustrated by 202a and 202b in the figure
  • the cache server 202 and the request response device 201 are connected through a network.
  • the request response device may be a network exit device, such as a router or a switch, connected to the peer in the BT system; it may also be another independently running server device connected to the network exit device and set in the same computer room.
  • a network exit device such as a router or a switch
  • the cache server 202 may communicate with the peer 301 (illustrated by 301 a and 301 b in the figure) in the BT system based on the BT protocol.
  • the peer301 in the BT system obtains the BT seed file on the Internet, parses it based on the BT protocol, obtains a list of tracker servers, randomly selects a tracker server, and sends a peer acquisition request to it. Because peer301 sends a peer acquisition request to the tracker server Generally, it must be sent out through the connected network exit device, and then reach the tracker server. After the tracker server receives the request, it responds, and the response will reach the network exit device first, and then reach peer301.
  • the request response device 201 responds to the peer acquisition request in advance, and feeds back the access address of the cache server 202 to the peer 301, so that the peer 301 quickly obtains the access address of the cache server 202 without waiting for the response from the tracker server, and starts to contact the cache server 202.
  • Perform a handshake and perform steps 101 to 104 so that the cache server 202 can obtain BT resource information based on the interaction with peer 201, and obtain data blocks of BT resources from peer 201.
  • the cache server can automatically obtain
  • the peers are rich in BT resources in the local database. There is no need to manually maintain the BT resources maintained by the cache server, and the BT resources in the local database are BT resources with high user demand and high popularity, and the value of storing BT resources is high. .
  • an embodiment of the present invention further provides a device for acquiring BT resource information.
  • the device can run a computer program, and the computer program can implement the method in the foregoing embodiment.
  • the device is a cache server.
  • the program may be stored in a computer-readable storage medium.
  • the storage medium mentioned may be a read-only memory, a magnetic disk or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种获取BT资源信息的方法和设备，属于数据传输技术领域。本发明实施例中，在与对端进行BT资源的数据交互时，如果本端没有BT资源的元信息，则可以在进行BT协议握手后，基于对端发来的BT资源的位图A，确定BT资源的数据片个数，然后对位图A取反，向对端反馈取反得到位图B，以触发对端向本端发送BT资源的数据块获取请求，这样，可以基于数据块获取请求来预测BT资源的数据片大小，从而可以获取到BT资源的资源信息。进一步的，本端还可以基于获取到BT资源信息从对端下载BT资源的数据块。

Description

一种获取BT资源信息的方法和设备 技术领域
本发明涉及数据传输技术领域，特别涉及一种获取BT资源信息的方法和设备。
背景技术
BT(Bit Torrent，比特流)协议是一种计算机通信协议，广泛用于对等网络(Peer to Peer)中BT客户端(peer)之间的BT资源共享。在与其它peer共享BT资源的过程中，BT客户端需要根据BT资源的元信息(包含BT资源的总大小、BT资源的数据片数目、每个数据片大小等资源信息)确定向对端请求多少个数据片，以及每个数据片要分多少个数据块来请求。
BT客户端在接收到某个peer发送的BT资源获取请求后，如果发现本地未拥有相应BT资源的元信息，则主要通过以下现有的2种方式来获取该元信息：其一，BT客户端可以根据BT资源获取请求中携带的BT资源的info hash从本地或者异地的种子库检索相应的种子文件，然后读取种子文件包含的BT资源的元信息；其二，BT客户端在与对端完成“Handshake”后，向对端或者正在共享该BT资源的其它peer请求BT资源的元信息。
在实现本发明的过程中，发明人发现现有技术至少存在以下问题：
如果本地或者异地的种子库内均检索不到该BT资源的种子文件，对端或者其它peer不支持“ut_metadata”的BT协议扩展，对端或者其它peer未对元信息的请求进行响应，BT客户端则无法获取到BT资源的元信息，进而BT客户端无法响应对端或者其他peer发送的请求。
发明内容
为了解决现有技术的问题，本发明实施例提供了一种获取BT资源信息的方法和设备。所述技术方案如下：
第一方面，提供了一种获取BT资源信息的方法，所述方法包含步骤：
在与对端进行handshake后，接收所述对端发送的目标BT资源的位图A；
对所述位图A进行取反，将取反得到的新位图B反馈给所述对端；
接收所述对端发送的所述目标BT资源的数据块获取请求；
根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小。
可选的，所述对所述位图A进行取反，将取反得到的新位图B反馈给所述对端，包括：
如果本地未存储有所述目标BT资源的位图，则对所述位图A进行取反，将取反得到的新位图B反馈给所述对端，否则向所述对端反馈本地存储的所述目标BT资源的位图。
可选的，所述向所述对端反馈本地存储的所述目标BT资源的位图，包括：
如果所述对端未存储有本地存储的所述目标BT资源的所有数据片，则向所述对端反馈本地存储的所述目标BT资源的位图，否则对所述位图A进行取反，将取反得到的新位图B反馈给所述对端。
可选的，所述根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小，包括：
如果所述数据块获取请求中的偏移量大于已知的所述目标BT资源的数据块偏移量，则根据所述数据块获取请求中的偏移量更新所述目标BT资源的数据片大小。
可选的，所述根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小之后，还包括：
根据所述位图A和预测的所述目标BT资源的数据片大小，从所述对端获取所述目标BT资源的数据块。
可选的，所述方法还包括：
以每个数据片内的数据块个数为第一维的长度，数据片个数为第二维长度，通过二维数组的形式记录本地所述目标BT资源的各数据块的存储情况。
可选的，所述方法还包括：
当预测到的所述目标BT资源的数据片大小增加时，在所述二维数组的第一维末尾对应添加新的数据组。
可选的，所述方法由缓存服务器实现。
基于上述方法，在与对端进行BT资源的数据交互时，如果本端没有BT资 源的元信息，则可以在进行BT协议握手后，基于对端发来的BT资源的位图A，确定BT资源的数据片个数，然后对位图A取反，向对端反馈取反得到位图B，以触发对端向本端发送BT资源的数据块获取请求，这样，可以基于数据块获取请求来预测BT资源的数据片大小，从而可以获取到BT资源的资源信息。进一步的，本端还可以基于获取到BT资源信息从对端下载BT资源的数据块。
第二方面，为了实现上述方法，本发明的实施例还提供了一种获取BT资源信息的设备，所述设备上运行有一计算机程序，所述计算机程序可实现上述实施例的方法。
可选的，所述设备为缓存服务器。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种获取BT资源信息的方法流程图；
图2是本发明实施例提供的一种请求响应系统结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
本发明实施例提供了一种获取BT资源信息的方法，可以应用于BT系统，BT系统可以面向整个互联网，BT客户端可以通过BT协议与其它BT客户端进行BT资源的数据传输。
两个BT客户端在互相进行数据传输之前，必须都拥有要共享的BT资源(可能是一个文件，也可能是多个文件的集合，以下统一称为“共享文件”)的元信息(metadata)。因为元信息中提供了BT资源的总大小(字节表示)、包含多少个数据片、每个数据片的大小等资源信息。如果一个BT客户端缺少这些资源信息，它就不知道自己要向对端请求多少个数据片，以及每个数据片要分多少个 数据块来请求。
本实例所提供的方法可以基于对端提供的BT资源的位图和数据块获取请求来预测BT资源的资源信息，从而使得BT客户端在没有BT资源的元信息，或者无法按照正常方式获取BT资源的元信息情况下，依然能够与对端进行BT资源的数据传输。
下面将结合具体实施方式，对图1所示的处理流程进行详细的说明，内容可以如下：
步骤101，在与对端进行handshake后，接收对端发送的目标BT资源的位图A。
在实施中，BT客户端在接收到来自某个peer的发送的针对某个BT资源(可称为目标BT资源)的数据请求后，可以先与该peer(后续可称为对端)建立通信连接，然后双方通过handshake交换数据传输的基础信息，包含：目标BT资源的info hash值、各自的设备ID、其它拓展信息(例如是否支持DHT模式，是否支持“ut_metadata”协议扩展等)。
在于对端进行handshake后，BT客户端可以先等待对端发送对端维护的目标BT资源的位图A。位图A可以反映对端中BT资源的数据片的下载完成情况，位图内的每一个二进制位(一个字节内包含8个二进制位)表示相应的BT资源的数据片是否已经下载完成。
例如，位图A的第一位数值是1，则表示对端中目标BT资源的第一个数据片的所有数据块均下载完成；位图A的第二位数值是0，则表示对端中目标BT资源的第二个数据片还未下载完整，即对端未存储或仅存储了部分第二个数据片的数据片。BT客户端在获取到目标BT资源的位图A之后，则可以根据位图A中的二进制位数确定出目标BT资源包含的数据片个数。
步骤102，对位图A进行取反，将取反得到的新位图B反馈给对端。
在实施中，BT客户端在获取到目标BT资源的位图A之后，可以对位图A进行取反，即将位图A中的二进制位数值为0的更改为1，二进制位数值为1的更改为0，从而得到新位图B。然后BT客户端可以将取反得到的新位图B反馈给对端。
可选的，如果本地存储有目标BT资源的位图，则优先向对端反馈本地存储的位图，相应的，步骤102的处理可以如下：如果本地未存储有目标BT资源的 位图，则对位图A进行取反，将取反得到的新位图B反馈给对端，否则向对端反馈本地存储的目标BT资源的位图。
在实施中，BT客户端在获取到对端发送的目标BT资源的位图A之后，可以先确定本地是否已存储有目标BT资源的位图。如果未存储，BT客户端则可以对位图A进行取反处理，然后将取反得到的新位图B反馈给对端；如果已存储，BT客户端则可以向对端反馈本地存储的目标BT资源的位图。
可以理解，本地存储的目标BT资源的位图，一种情况下是BT客户端通过正常方式获取到的目标BT资源的位图，另一种情况下是BT客户端采用本实施例的方案预测得到的目标BT资源的位图，因此，相对于直接对对端的位图取反反馈的处理，对端可以基于BT客户端存储的位图从BT客户端处切实获取到目标BT资源的数据块。
可选的，如果对端的位图完全覆盖了本地存储的位图，则可以仍反馈取反得到的位图，相应的处理可以如下：如果对端未存储有本地存储的目标BT资源的所有数据片，则向对端反馈本地存储的目标BT资源的位图，否则对位图A进行取反，将取反得到的新位图B反馈给对端。
在实施中，BT客户端如果存储有目标BT资源的位图，则在接收到对端发送的目标BT资源的位图A之后，可以先比较两个位图。如果发现对端未存储有本地存储的目标BT资源的所有数据片，BT客户端则可以向对端反馈本地存储的目标BT资源的位图；而如果对端的位图完全覆盖了本地存储的位图，即本地存储的目标BT资源的数据片，对端均已存储，此时BT客户端则可以对对端发送的位图A进行取反，然后将取反得到的新位图B反馈给对端。
需要说明的是，当对端位图完全覆盖本地存储的位图时，如果仍旧向对端反馈本地存储的位图，则在本次交互过程中，对端将不会向BT客户端发送任何目标BT资源的数据块获取请求，这样，BT客户端则无法通过数据块获取请求来对目标BT资源的数据片大小进行进一步的预测。
步骤103，接收对端发送的目标BT资源的数据块获取请求。
在实施中，BT资源的正常数据交互过程中，双方交换了各自的位图之后，当其中一端发现对方的位图有己端未包含的内容，也即对方存储有己端没有的数据时，则可以从对端获取相应的数据块。这样，当BT客户端将取反得到的新位图B反馈给对端之后，对端则认为BT客户端存储有对端未存储的目标BT资 源的数据块，故而，对端可以基于新位图B，向BT客户端发送目标BT资源的数据块获取请求。BT客户端从而可以接收到相应的数据块获取请求。
步骤104，根据数据块获取请求中的偏移量预测目标BT资源的数据片大小。
在实施中，BT客户端接收到对端发来的数据块获取请求后，可以根据数据块获取请求中的偏移量来预测目标BT资源的数据片大小。
具体的，数据块获取请求中可以指定想要获取具体某个数据片的某段字节数据，字节数据则可以由偏移量来进行定位，即表示请求的字节数据的起始位置处于该数据片中的第几个字节，同时由于BT资源中每个数据块的大小都是固定的16KB，则可以基于偏移量来预测出该数据片中至少包含几个数据块。
进一步的，每个BT资源的数据一般分为多个大小相同的数据片，除最后一个数据片外，其余数据片的大小均一致，故而，可以基于预测出的目标BT资源的各数据片包含的数据块个数来预测目标BT资源的数据片大小。
例如，对端请求的是目标BT资源的第20个数据片，偏移量为0x8000、长度为0x4000的字节数据，那么可以猜测目标BT资源的一个数据片至少包含(0x8000+0x4000)/0x4000＝3个数据块(一个数据块的大小是16KB，也就是0x4000)。
需要说明的是，由于BT资源的最后一个数据片的大小与其它数据片的大小不一致，可以对最后一个数据片单独处理，即仅根据对于最后一个数据片的数据块获取请求中的偏移量来预测目标BT资源的最后一个数据片大小。
值得一提的是，上述步骤101至步骤104的处理，主要是给出了一种在无法基于背景技术中给出的正常方式获取BT资源的元信息的情况下，对BT资源的资源信息进行预测的方法，故而，在执行步骤101之前，如果BT客户端中未存储有BT资源的元信息，则可以先按照上述正常方式来进行BT资源的元信息的获取处理，而如果获取失败，则可以按照本实施例中步骤101至步骤104给出的方法来预测BT资源的资源信息。
可选的，在预测数据片大小时，BT客户端如果收到来自对端的有更大偏移量的数据块获取请求，则可以动态更新预测结果，相应的，步骤104的处理可以如下：如果数据块获取请求中的偏移量大于已知的目标BT资源的数据块偏移量，则根据数据块获取请求中的偏移量更新目标BT资源的数据片大小。
在实施中，BT客户端接收到对端发来的数据块获取请求后，可以获取该数 据块获取请求携带的偏移量，然后将该偏移量与已知的目标BT资源的数据块偏移量作比较，如果数据块获取请求中的偏移量大于已知的目标BT资源的数据块偏移量，BT客户端则可以根据数据块获取请求中的偏移量更新目标BT资源的数据片大小。
例如，BT客户端已知的目标BT资源的数据块偏移量为0x8000，预测目标BT资源的数据片大小为48KB，而本次接收到的数据块获取请求中的偏移量为0xc000，大于0x8000，故而可以基于本次的偏移量0xc000，更新目标BT资源的数据片大小为64KB。此处，已知的目标BT资源的数据块可以是BT客户端基于之前的目标BT资源的数据块获取请求来预测得到的，而之前的数据块获取请求可以是对端发送的，也可以是BT客户端与其它peer交互时，其它peer发送至BT客户端的。
可选的，在获取完BT资源信息后，BT客户端可以基于获取到的BT资源信息进行BT资源的下载，相应的处理可以如下：根据位图A和预测的目标BT资源的数据片大小，从对端获取目标BT资源的数据块。
在实施中，BT客户端在预测了目标BT资源的数据片大小之后，可以根据位图A确定对端存储的所有目标BT资源的数据片，然后基于预测的目标BT资源的数据片大小进一步确定对端存储的所有目标BT资源的数据块，进而，BT客户端可以判断对端存储的目标BT资源的数据块中本地未存储的数据块，这样，BT客户端可以对端获取这些本地未存储，而对端已存储的目标BT资源的数据块。
举例来说，目标BT资源实际包含有5个数据片，BT客户端通过上述方法预测出每个数据片至少包含3个数据块，位图A为10110，而BT客户端中已存储有前2个数据片的3个数据块和第3个数据片的前2个数据块，故而BT客户端可以确定出对端已存储而本地未存储的数据块为第3个数据片的第3个数据块和第4个数据片的前3个数据块，这样，BT客户端则可以以向对端发送数据块获取请求的方式，从对端获取上述数据块。
进一步的，在从对端获取目标BT资源的数据块的过程中，BT客户端如果更新了目标BT资源的数据片大小，则需要重新确定对端存储的数据块和本地存储的数据块，然后继续从对端获取本地未存储的数据块。
可选的，可以选用二维数组的方式来记录BT资源的数据存储情况，相应的 处理可以如下：以每个数据片内的数据块个数为第一维的长度，数据片个数为第二维长度，通过二维数组的形式记录本地目标BT资源的各数据块的存储情况。
在实施中，BT客户端在存储目标BT资源的数据块时，可以以每个数据片内的数据块个数为第一维的长度，以数据片个数为第二维长度，通过二维数组的形式记录本地目标BT资源的各数据块的存储情况。
例如，以a、b、c、d代表数据片，1、2、3、4代表数据块，那么a4则代表第a个数据片的第4个数据块，二维数组即为(a1，b1，c1，d1)、(a2，b2，c2，d2)、(a3，b3，c3，d3)、(a4，b4，c4，d4)。这样，通过对二维数组中每个项赋予不同的bool型取值，则可以反映出各项对应的数据块的存储情况。
可选的，基于上述二维数组记录数据块的存储情况的处理，当预测到的目标BT资源的数据片大小增加时，在二维数组的第一维末尾对应添加新的数据组。
在实施中，BT客户端选用二维数组来记录目标BT资源的数据块的存储情况时，如果预测到的目标BT资源的数据片大小增加时，则可以直接在二维数组的第一维末尾对应添加新的数据组。例如，已有的二维数组为(a1，b1，c1，d1)、(a2，b2，c2，d2)、(a3，b3，c3，d3)、(a4，b4，c4，d4)，如果预测到的目标BT资源的数据片大小增加为5，则可以在二维数组的第一维末尾对应添加数据组(a5，b5，c5，d5)。可以看出，由于BT资源的数据片个数一般显著大于一个数据片包含的数据块个数，故而选用上述二维数组记录，在更新二维数组的过程中，无需遍历所有数组，可以节省对于内存、CPU的占用。
本实施例还提供了一种由缓存服务器来获取BT资源信息的方法，缓存服务器可以部署于如图2所示的请求响应系统中，该请求响应系统中包含请求响应设备201及至少一缓存服务器202(图中以202a、202b进行示意)，缓存服务器202与请求响应设备201通过网络连接。
请求响应设备可以为BT系统中peer所连接的网络出口设备，例如路由器、交换机；也可以是与网络出口设备连接，并设置在同一机房的其他独立运行的服务器设备。
缓存服务器202可基于BT协议与BT系统中的peer301(图中以301a、301b进行示意)进行通信。
BT系统中的peer301联网获取BT种子文件，并基于BT协议对其进行解析， 获取tracker服务器列表，并随机选取一个tracker服务器，并向其发送peer获取请求，由于peer301向tracker服务器发送的peer获取请求，一般都要经过其所连接的网络出口设备发送出去，再到达tracker服务器，tracker服务器接收到请求后，进行响应，该响应会先到达网络出口设备，再到达peer301。
在本实施中请求响应设备201通过提前对peer获取请求进行响应，向peer301反馈缓存服务器202的访问地址，使得peer301无需等待tracker服务器的响应而快速获取缓存服务器202的访问地址，开始与缓存服务器202进行握手并进行步骤101至步骤104的处理，从而缓存服务器202可以基于与peer201的交互，获取BT资源信息，并从peer201处获取BT资源的数据块，这样，缓存服务器可以自动从BT系统中的peer处丰富本地数据库中的BT资源，无需人工对缓存服务器维护的BT资源进行维护，并且本地数据库中的BT资源均是具备一定用户需求、热度较高的BT资源，存储BT资源的价值较高。
基于相同的技术构思，本发明实施例还提供了一种获取BT资源信息的设备，该设备上可运行有一计算机程序，所述计算机程序可实现上述实施例中的方法。
可选的，所述设备为缓存服务器。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

  1. 一种获取BT资源信息的方法，其特征在于，所述方法包括：
    在与对端进行handshake后，接收所述对端发送的目标BT资源的位图A；
    对所述位图A进行取反，将取反得到的新位图B反馈给所述对端；
    接收所述对端发送的所述目标BT资源的数据块获取请求；
    根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小。
  2. 根据权利要求1所述的方法，其特征在于，所述对所述位图A进行取反，将取反得到的新位图B反馈给所述对端，包括：
    如果本地未存储有所述目标BT资源的位图，则对所述位图A进行取反，将取反得到的新位图B反馈给所述对端，否则向所述对端反馈本地存储的所述目标BT资源的位图。
  3. 根据权利要求2所述的方法，其特征在于，所述向所述对端反馈本地存储的所述目标BT资源的位图，包括：
    如果所述对端未存储有本地存储的所述目标BT资源的所有数据片，则向所述对端反馈本地存储的所述目标BT资源的位图，否则对所述位图A进行取反，将取反得到的新位图B反馈给所述对端。
  4. 根据权利要求1所述的方法，其特征在于，所述根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小，包括：
    如果所述数据块获取请求中的偏移量大于已知的所述目标BT资源的数据块偏移量，则根据所述数据块获取请求中的偏移量更新所述目标BT资源的数据片大小。
  5. 根据权利要求1所述的方法，其特征在于，所述根据所述数据块获取请求中的偏移量预测所述目标BT资源的数据片大小之后，还包括：
    根据所述位图A和预测的所述目标BT资源的数据片大小，从所述对端获取所述目标BT资源的数据块。
  6. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    以每个数据片内的数据块个数为第一维的长度，数据片个数为第二维长度，通过二维数组的形式记录本地所述目标BT资源的各数据块的存储情况。
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    当预测到的所述目标BT资源的数据片大小增加时，在所述二维数组的第一维末尾对应添加新的数据组。
  8. 根据权利要求1-7任一项所述的方法，其特征在于，所述方法由缓存服务器实现。
  9. 一种获取BT资源信息的设备，其特征在于，所述设备上运行有一计算机程序，所述计算机程序可实现如权利要求1至8中任一项所述的方法。
  10. 如权利要求9所述的获取BT资源信息的设备，其特征在于，所述设备为缓存服务器。
PCT/CN2018/101518 2018-07-03 2018-08-21 一种获取bt资源信息的方法和设备 WO2020006822A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18925702.5A EP3820063A4 (en) 2018-07-03 2018-08-21 PROCESS AND DEVICE FOR ACQUIRING BT RESOURCE INFORMATION
US16/617,358 US11190584B2 (en) 2018-07-03 2018-08-21 Method and device for acquiring bit torrent resource information

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810718327.0 2018-07-03
CN201810718327.0A CN108964845B (zh) 2018-07-03 2018-07-03 一种获取bt资源信息的方法和设备

Publications (1)

Publication Number Publication Date
WO2020006822A1 true WO2020006822A1 (zh) 2020-01-09

Family

ID=64485282

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/101518 WO2020006822A1 (zh) 2018-07-03 2018-08-21 一种获取bt资源信息的方法和设备

Country Status (4)

Country Link
US (1) US11190584B2 (zh)
EP (1) EP3820063A4 (zh)
CN (1) CN108964845B (zh)
WO (1) WO2020006822A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101917488A (zh) * 2010-08-20 2010-12-15 成都市华为赛门铁克科技有限公司 一种bt下载方法、装置及系统
CN102075561A (zh) * 2010-11-29 2011-05-25 成都市华为赛门铁克科技有限公司 一种网络资源下载方法，装置及系统
US20170063981A1 (en) * 2015-08-28 2017-03-02 Electronics And Telecommunications Research Institute Peer-to-peer (p2p) network management system and method of operating the p2p network management system

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225228B2 (en) * 2002-03-25 2007-05-29 Sun Microsystems, Inc. Efficient binary content distribution using propagating messages
DE602006017040D1 (de) * 2006-05-19 2010-11-04 Microsoft Corp Inhaltsverwaltung in Peer-to-peer Datenverteilungswolken
EP2052336A1 (en) 2006-08-11 2009-04-29 Velocix Limited Improved storage performance
GB2440760A (en) * 2006-08-11 2008-02-13 Cachelogic Ltd Network and method of transferring data over the network by nodes sending messages containing a subset of list of data available at the node
US8606846B2 (en) * 2007-10-15 2013-12-10 Nbcuniversal Media, Llc Accelerating peer-to-peer content distribution
US20090100128A1 (en) * 2007-10-15 2009-04-16 General Electric Company Accelerating peer-to-peer content distribution
CN101588287B (zh) * 2008-05-20 2011-11-16 华为技术有限公司 对等网络数据调度和下载的方法、装置和系统
EP2216958B1 (en) 2009-02-10 2011-10-26 Alcatel Lucent Method and device for reconstructing torrent content metadata
US9313268B2 (en) * 2009-03-03 2016-04-12 Telefonaktiebolaget L M Ericsson (Publ) Methods and arrangements for prioritization in a peer-to-peer network
US20110060721A1 (en) * 2009-08-10 2011-03-10 Vuze, Inc. Offline downloader
JP5442131B2 (ja) * 2009-11-25 2014-03-12 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 記述ファイルに基づいた個別データ通信
US8458172B2 (en) * 2009-12-24 2013-06-04 At&T Intellectual Property I, L.P. Method and apparatus for automated end to end content tracking in peer to peer environments
WO2012061841A1 (en) * 2010-11-05 2012-05-10 The Trustees Of Columbia University In The City Of New York Methods, systems, and media for stored content distribution and access
US9148478B2 (en) * 2011-10-25 2015-09-29 Alcatel Lucent Verification of integrity of peer-received content in a peer-to-peer content distribution system
US8719345B2 (en) * 2012-05-11 2014-05-06 Oracle International Corporation Database replication using collaborative data transfers
US20160026788A1 (en) * 2014-07-28 2016-01-28 Iboss, Inc. Selectively introducing security issues in a sandbox environment to elicit malicious application behavior
US10896255B2 (en) * 2016-11-14 2021-01-19 The Quantum Group, Inc. Dynamic episodic networks
US11553014B2 (en) * 2017-07-04 2023-01-10 Vmware, Inc. Downloading of server-based content through peer-to-peer networks
CN112491972A (zh) * 2018-06-11 2021-03-12 华为技术有限公司 资源获取、分发、下载方法、装置、设备及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101917488A (zh) * 2010-08-20 2010-12-15 成都市华为赛门铁克科技有限公司 一种bt下载方法、装置及系统
CN102075561A (zh) * 2010-11-29 2011-05-25 成都市华为赛门铁克科技有限公司 一种网络资源下载方法，装置及系统
US20170063981A1 (en) * 2015-08-28 2017-03-02 Electronics And Telecommunications Research Institute Peer-to-peer (p2p) network management system and method of operating the p2p network management system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP3820063A4 *
WANG, ZHANMING: "BitTorrent (Research of BitTorrent's Principle and Algorithm and Its Performance Optimization)", CHINESE MASTER'S THESES FULL-TEXT DATABASE (INFORMATION & TECHNOLOGY), 15 December 2007 (2007-12-15), pages 1 - 67, XP055766517 *

Also Published As

Publication number Publication date
EP3820063A4 (en) 2021-08-25
US11190584B2 (en) 2021-11-30
US20210337018A1 (en) 2021-10-28
EP3820063A1 (en) 2021-05-12
CN108964845A (zh) 2018-12-07
CN108964845B (zh) 2021-04-16

Similar Documents

Publication Publication Date Title
US11194719B2 (en) Cache optimization
JP5363593B2 (ja) トレントコンテンツメタデータを再構成する方法およびデバイス
JP4938092B2 (ja) エッジネットワークにおけるデータ配信方法、データ配信システム、および関連装置
US7995473B2 (en) Content delivery system for digital object
US9678678B2 (en) Storage network data retrieval
US8880698B2 (en) Storage of content data in a peer-to-peer network
US11553014B2 (en) Downloading of server-based content through peer-to-peer networks
US8010748B2 (en) Cache structure for peer-to-peer distribution of digital objects
US8019830B2 (en) Methods and apparatus for acquiring file segments
CN103597471A (zh) 用于对计算机网络上的数据通信进行缓存的方法和系统
US8028019B2 (en) Methods and apparatus for data transfer in networks using distributed file location indices
US10116740B2 (en) Peer-to-peer network prioritizing propagation of objects through the network
KR20120018178A (ko) 객체 저장부들의 네트워크상의 스웜-기반의 동기화
US9479578B1 (en) Randomized peer-to-peer synchronization of shared content items
WO2010077379A1 (en) Systems and methods for peer-to-peer bandwidth allocation
WO2008025297A1 (fr) Procédé de téléchargement de fichiers selon la technique p2p (pair à pair) et système de téléchargement p2p
CN108881034B (zh) 一种应用于bt系统的请求响应方法、设备及系统
US10257272B2 (en) Randomized peer-to-peer synchronization of shared content items
JP2019016042A (ja) データ取得プログラム、装置、及び方法
GB2440759A (en) Selecting a download cache for digital data
US7849163B1 (en) System and method for chunked file proxy transfers
CN115004665B (zh) 文件分享方法、装置及系统
WO2020006822A1 (zh) 一种获取bt资源信息的方法和设备
KR101041092B1 (ko) 웹 폴더를 이용한 효과적인 피투피 시스템
JP2004348722A (ja) ドキュメント共有装置及びその制御方法、並びに、コンピュータプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18925702

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018925702

Country of ref document: EP

Effective date: 20210202