WO2010092017A1 - A method and device for reconstructing torrent content metadata - Google Patents
A method and device for reconstructing torrent content metadata Download PDFInfo
- Publication number
- WO2010092017A1 WO2010092017A1 PCT/EP2010/051489 EP2010051489W WO2010092017A1 WO 2010092017 A1 WO2010092017 A1 WO 2010092017A1 EP 2010051489 W EP2010051489 W EP 2010051489W WO 2010092017 A1 WO2010092017 A1 WO 2010092017A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- torrent
- torrent content
- peer
- client
- content file
- Prior art date
- Legal status (The legal status 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 status listed.)
- Ceased
Links
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
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- 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/1063—Discovery through centralising entities
-
- 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
Definitions
- G calculating the amount of segments from the torrent content file size and the segment length.
- the client that desires to download and cache a torrent content file obtains the torrent content identifier, e.g. the infohash in case of BitTorrent, from signaling from another, standard client that is downloading the targeted torrent content file with access to the metafile.
- the caching client that operates according to the present invention does not have access to the metafile.
- This caching client further needs to obtain from an Internet tracker the IP address of a peer that holds a full size segment of the targeted torrent content file.
- the caching client will receive more than one peer address in answer to a single request.
- the caching client operating according to the present invention contacts an Internet tracker (whose address has been obtained from the torrent signaling from the standard client) and obtains from the Internet tracker the IP address of a peer that stores a segment of the targeted torrent content file. Should the peer contain only a single segment with no guaranteed full segment size, the steps D and E may have to be repeated iteratively as will be explained below. It is also noticed that typically, the caching client will receive more than one peer address in answer to a request in step D. By sequentially downloading minimum size blocks, e.g. 16 kByte blocks, until a block request is rejected, the client can learn the size of a segment. From the BitTorrent signaling from the standard client, the caching client further obtains the torrent content file size. The last missing parameter, the amount of segments in the torrent content file, can be determined by the caching client from the segment size and the torrent content file size (and eventual verification against the Bitfield length, as will be explained below).
- the present invention also relates to a corresponding device as defined by claim 8, e.g. a carrier or memory device holding software for executing the method of claim 1.
- step E of the method according to the present invention may comprise handshaking with the peer, thereby retrieving the peer's Bitfield, each bit in the Bitfield being representative for the availability of a corresponding segment of the torrent content file.
- the BitTorrent client will contact the peer whose IP address has been received from the Internet tracker in order to receive a Bitfield associated with the targeted torrent content file.
- This Bitfield is received in response and will indicate the possible maximum number of segments (corresponding to the Bitfield length) and which segments of the torrent content file are stored in the peer.
- the Bitfield typically contains as many bits as there are segments in the torrent content file. In the Bitfield, a bit is set (“one” or “true”) when the corresponding segment is available and downloadable from the peer and a bit is not set (“zero” or "false”) when the corresponding segment is not available at the peer.
- step F of the method according to the present invention may comprise:
- step E iteratively repeating step E and eventually also step D until the Bitfield contains plural bits set, or until only the first bit in the Bitfield is set;
- step A of the method according to the present invention may comprise obtaining a unique torrent identifier (i.e. infohash) identifying the torrent content file from BitTorrent signaling.
- a unique torrent identifier i.e. infohash
- step B may comprise: - obtaining the number of bytes downloaded and the number of bytes left from
- the number of bytes left and the number of bytes downloaded can be obtained from BitTorrent signaling from another, standard client that is downloading the torrent content file with access to the metafile.
- BitTorrent the number of bytes left and the number of bytes downloaded can be obtained from BitTorrent signaling from another, standard client that is downloading the torrent content file with access to the metafile.
- the client may elect to determine the file size from the Bitfield length, i.e. the maximum Bitfield length received from peers in step E or iterations of this step, and the segment length as determined in step F. It is noticed here that the multiplication of the Bitfield length and segment size may be different from the actual torrent content file size since the last segment may be an incomplete one.
- the client or caching node can start downloading the torrent content file and store it partially or entirely in cache memory.
- Fig. 1 shows a BitTorrent cache client 101 and a peer 102, i.e. a machine that stores certain segments of a torrent content file, e.g. a movie file "Raiders of the Lost Ark". It is assumed that the peer 102 also supports the BitTorrent protocol. Both the cache client 101 and peer 102 have Internet connectivity and the cache client 101 has obtained the IP address of the peer 102 from an Internet tracker from BitTorrent signaling from another, standard client that is downloading the targeted movie file with access to the metafile.
- a BitTorrent cache client 101 and 102 i.e. a machine that stores certain segments of a torrent content file, e.g. a movie file "Raiders of the Lost Ark". It is assumed that the peer 102 also supports the BitTorrent protocol. Both the cache client 101 and peer 102 have Internet connectivity and the cache client 101 has obtained the IP address of the peer 102 from an Internet tracker from BitTorrent signaling from another, standard client that is downloading the targeted movie file with access to the metafile.
- the cache client 101 From the received Bitfield 103 the cache client 101 has to derive the segment size and the number of segments of the targeted torrent content file. This is done as follows. The cache client 101 first has to find a segment that has guaranteed full segment size. Any bit, except the last set bit in the Bitfield 103 represents a segment with guaranteed full segment size that can be downloaded from the peer 102. The last set bit might or might not represent a segment with full segment size and therefore cannot be relied upon to determine the segment size. If the Bitfield would have only one bit set and if this is not the first bit then the cache client 101 cannot derive the segment size from the Bitfield. In such case, the cache client 101 would discard the Bitfield and try handshaking with a different peer. In Fig.
- the Bitfield 103 contains more than one set bit.
- the cache client 101 takes any set bit before the last one, e.g. bit 104, and that bit number as the ID to start downloading the corresponding segment of the torrent content file.
- the cache client 101 informs the other peer 102 that it is interested in the segment corresponding to the selected bit 104 in the Bitfield 103.
- the cache client 101 thereupon starts sending piece requests for minimum size blocks 105, i.e. subsequent blocks of 16 kByte like block 106.
- the cache client 101 also keeps a count on the number of block requests sent. As soon as a block request is rejected, this indicates the end of the segment.
- the cache client 101 can now compute the segment size from the number of successful block requests multiplied with the block size.
- the cache client 101 at last determines the number of segments through dividing the file size by the segment size or, in case where the file size cannot be trusted, from the maximum Bitfield length multiplied with the segment size. [26] In the embodiment described here above, it is assumed that the initially reported file size is correct, i.e. the initial client requesting the cache client 101 to cache the torrent content file provides correct and complete bytes left and bytes downloaded information. A slight modification of the embodiment described here above allows the download of (nearly complete) torrent content, even in the case where the initially reported file size is incorrect. In another alternate embodiment, multiple peers may be contacted concurrently in order to increase the probability that a peer holding a full size segment will be contacted and consequently reduce or avoid iterations of steps A and B of the method.
- top, bottom, over, under, and the like are introduced for descriptive purposes and not necessarily to denote relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances and embodiments of the invention are capable of operating according to the present invention in other sequences, or in orientations different from the one(s) described or illustrated above.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method for reconstructing torrent content metadata, i.e. a torrent identifier, a segment length and an amount of segments of a torrent content file, without access to the torrent content metafile, comprises the steps of: A. obtaining the torrent content identifier from torrent signaling from a client; B. obtaining a torrent content file size from said torrent signaling from said client; C. obtaining a tracker address from said torrent signaling from said client: D. obtaining a peer address from a tracker; E. contacting a peer via the peer address; F. downloading sequential minimum size blocks of a full size segment from the peer in order to determine the segment length; G. calculating the amount of segments from the torrent content file size and the segment length.
Description
A METHOD AND DEVICE FOR RECONSTRUCTING TORRENT CONTENT
METADATA
Field of the Invention
[01] The present invention generally relates to peer-to-peer communication, more particularly to downloading and caching a torrent content file whose fixed size pieces or segments are stored on one or plural peers. The torrent content file may for instance be a movie file, an audio file, a software file, etc. The downloading and caching concerns the storing of the torrent content file on another client than the one that actually initiated the download. Typically, two downloads will be ongoing: one regular download towards the initiating client according to state-of-the-art mechanisms and one particular download for the caching client according to the present invention.
Background of the Invention
[02] BitTorrent is a peer-to-peer communication protocol that enables a BitTorrent client to download fixed size segments of a torrent content file from one or plural peers in order to reconstitute the torrent content file, e.g. a movie or song. The BitTorrent client thereto needs a unique torrent content identifier with which it contacts an Internet tracker which holds a list of the peers that store segments of the torrent content file. This unique torrent content identifier is advertised as upfront knowledge in the torrent content metafile. The BitTorrent client receives the IP addresses of these peers from the Internet tracker and consequently can start exchanging segments with these peers in order to download and reconstitute the entire torrent content file. The BitTorrent client thereto needs the torrent content file size, the number of segments in which the torrent content file has been divided and the fixed length for all but the last such segments. These metadata are also advertised as upfront knowledge in the torrent content metafile.
[03] The drawback of the above described, known method for downloading and caching torrent content is that the torrent content metafile may not always be available to all the clients that desire to download the torrent content file, as a result
of which downloading and caching the torrent content file is not possible for clients that have no access to the torrent content metafile.
[04] It is an objective of the present invention to disclose a method and device for reconstructing missing torrent content metadata that is necessary to allow the download of a torrent content file without having access to the torrent content metafile.
Summary of the Invention
[05] According to the present invention, the above defined objective is realized and the drawback of the prior art is overcome by the method for reconstructing missing torrent content metadata as defined by claim 1 , comprising the steps of:
A. obtaining a torrent content identifier from torrent signaling from a client; B. obtaining a torrent content file size from said torrent signaling from said client;
C. obtaining a tracker address from said torrent signaling from said client;
D. obtaining a peer address from a tracker;
E. contacting a peer via the peer address; F. downloading sequential minimum size blocks of a full size segment from the peer in order to determine the segment length; and
G. calculating the amount of segments from the torrent content file size and the segment length.
[06] Indeed, according to the invention, the client that desires to download and cache a torrent content file obtains the torrent content identifier, e.g. the infohash in case of BitTorrent, from signaling from another, standard client that is downloading the targeted torrent content file with access to the metafile. The caching client that operates according to the present invention however does not have access to the metafile. This caching client further needs to obtain from an Internet tracker the IP address of a peer that holds a full size segment of the targeted torrent content file. Typically, the caching client will receive more than one peer address in answer to a single request. The caching client operating according to the present invention contacts an Internet tracker (whose address has been obtained from the torrent
signaling from the standard client) and obtains from the Internet tracker the IP address of a peer that stores a segment of the targeted torrent content file. Should the peer contain only a single segment with no guaranteed full segment size, the steps D and E may have to be repeated iteratively as will be explained below. It is also noticed that typically, the caching client will receive more than one peer address in answer to a request in step D. By sequentially downloading minimum size blocks, e.g. 16 kByte blocks, until a block request is rejected, the client can learn the size of a segment. From the BitTorrent signaling from the standard client, the caching client further obtains the torrent content file size. The last missing parameter, the amount of segments in the torrent content file, can be determined by the caching client from the segment size and the torrent content file size (and eventual verification against the Bitfield length, as will be explained below).
[07] Apart from the method defined by claim 1 , the present invention also relates to a corresponding device as defined by claim 8, e.g. a carrier or memory device holding software for executing the method of claim 1.
[08] Any system that desires to cache torrent content without having access to the torrent content metafile(s) may take benefit of the present invention. An example of such systems is a BitTorrent client, as is indicated by claim 9.
[09] Further optionally, as defined by claim 2, step E of the method according to the present invention may comprise handshaking with the peer, thereby retrieving the peer's Bitfield, each bit in the Bitfield being representative for the availability of a corresponding segment of the torrent content file.
[10] Indeed, the BitTorrent client will contact the peer whose IP address has been received from the Internet tracker in order to receive a Bitfield associated with the targeted torrent content file. This Bitfield is received in response and will indicate the possible maximum number of segments (corresponding to the Bitfield length) and which segments of the torrent content file are stored in the peer. The Bitfield typically contains as many bits as there are segments in the torrent content file. In the Bitfield, a bit is set ("one" or "true") when the corresponding segment is available and
downloadable from the peer and a bit is not set ("zero" or "false") when the corresponding segment is not available at the peer.
[11] Further optionally, as defined by claim 3, step F of the method according to the present invention may comprise:
- iteratively repeating step E and eventually also step D until the Bitfield contains plural bits set, or until only the first bit in the Bitfield is set;
- selecting a bit in the Bitfield that is set, the bit being different from the last bit in the Bitfield that is set unless only the first bit in the Bitfield is set; - sending block requests to the peer for minimum size blocks of a segment corresponding to the selected bit until a block request is rejected;
- counting the number of block requests sent; and
- multiplying the number of block requests with the minimum size block length to thereby determine the segment length.
[12] Indeed, the caching client needs to derive the piece size (or segment size or segment length) from the Bitfield. The caching client shall thereto sequentially download small blocks of a segment until it reaches the border of the segment, but upfront needs guarantees that the segment that is downloaded is a full size segment. Typically, the last segment of the torrent content file will not be a full size segment. Therefore, the last set bit in the received Bitfield might or might not represent a full size segment and cannot be used by the caching client to determine the segment length. The caching client consequently will sequentially download small blocks of a segment corresponding with a bit in the Bitfield that is different from the last set bit. If the Bitfield contains only one set bit, the client will discard the Bitfield and will attempt handshaking with a different peer by repeating steps D and E. In case the caching client has received multiple peer addresses in a previous execution of step D, step D need not be repeated as the caching client can attempt to contact one of the other peers. Exceptionally, when the Bitfield contains only one set bit and this bit is the first bit in the Bitfield, the caching client can select the first segment for gradual downloading to establish the segment length. The caching client will start sending requests for minimum size blocks of the selected segment. When a block request is rejected, this indicates the end of the segment. By counting the number of unrejected block requests sent, and multiplying this number with the length of a minimum size
block, e.g. 16 kByte, the caching client can determine the segment length for the targeted torrent content file.
[13] Also, as defined by claim 4, step A of the method according to the present invention may comprise obtaining a unique torrent identifier (i.e. infohash) identifying the torrent content file from BitTorrent signaling.
[14] Indeed, in case of BitTorrent, a unique torrent identifier (i.e. infohash identifying the torrent content file can be obtained from BitTorrent signaling from a standard client that is downloading the targeted torrent content file with access to the metafile.
[15] Another optional aspect of the method according to the present invention, defined by claim 5, is that step B may comprise: - obtaining the number of bytes downloaded and the number of bytes left from
BitTorrent signaling from a standard BitTorrent client; and
- determining the torrent content file size by summing the number of bytes downloaded and the number of bytes left.
[16] Again, in case of BitTorrent, the number of bytes left and the number of bytes downloaded can be obtained from BitTorrent signaling from another, standard client that is downloading the torrent content file with access to the metafile. These two figures, when summed together, give the client an estimate on the torrent content file size. In case where the reported file size however is doubtful, the client may elect to determine the file size from the Bitfield length, i.e. the maximum Bitfield length received from peers in step E or iterations of this step, and the segment length as determined in step F. It is noticed here that the multiplication of the Bitfield length and segment size may be different from the actual torrent content file size since the last segment may be an incomplete one.
[17] Further optionally, as defined by claim 6, in the method according to the present invention step G may comprise determining the amount of segments through dividing the torrent content file size by the segment length.
[18] Indeed, the client still has to derive the number of pieces or amount of segments that constitute the targeted torrent content file in order to complete its knowledge of the metadata. By dividing the file size as determined in step E by the segment length as determined in step C, the client can calculate the amount of segments.
[19] As is indicated by claim 7, the method for reconstructing torrent content metadata according to the present invention may be complemented with the optional step: H. downloading and caching one or more segments of the torrent content file.
[20] Thus, with the knowledge of the torrent identifier an the reconstructed metadata, i.e. the torrent content file size, the segment length and the amount of segments, the client or caching node can start downloading the torrent content file and store it partially or entirely in cache memory.
Brief Description of the Drawings
[21] Fig. 1 illustrates an embodiment of the method for reconstructing torrent content metadata without access to the torrent content metafile according to the present invention.
Detailed Description of Embodiment(s)
[22] Fig. 1 shows a BitTorrent cache client 101 and a peer 102, i.e. a machine that stores certain segments of a torrent content file, e.g. a movie file "Raiders of the Lost Ark". It is assumed that the peer 102 also supports the BitTorrent protocol. Both the cache client 101 and peer 102 have Internet connectivity and the cache client 101 has obtained the IP address of the peer 102 from an Internet tracker from BitTorrent signaling from another, standard client that is downloading the targeted movie file with access to the metafile.
[23] From the BitTorrent signaling from the other, standard client, the cache client 101 further obtains a unique torrent identifier (i.e. infohash) identifying the targeted
torrent content file, i.e. the movie "Raiders of the Lost Ark", and the amount of bytes left and amount of bytes downloaded, the sum of which gives the expected torrent content file size.
[24] The cache client 101 contacts the peer 102 to receive a Bitfield associated with the targeted torrent content file, i.e. the movie "Raiders of the Lost Ark". This is the first handshake with the peer 102. The Bitfield 103 is received in the response from the peer 102.
[25] From the received Bitfield 103 the cache client 101 has to derive the segment size and the number of segments of the targeted torrent content file. This is done as follows. The cache client 101 first has to find a segment that has guaranteed full segment size. Any bit, except the last set bit in the Bitfield 103 represents a segment with guaranteed full segment size that can be downloaded from the peer 102. The last set bit might or might not represent a segment with full segment size and therefore cannot be relied upon to determine the segment size. If the Bitfield would have only one bit set and if this is not the first bit then the cache client 101 cannot derive the segment size from the Bitfield. In such case, the cache client 101 would discard the Bitfield and try handshaking with a different peer. In Fig. 1 , it is assumed that the Bitfield 103 contains more than one set bit. The cache client 101 takes any set bit before the last one, e.g. bit 104, and that bit number as the ID to start downloading the corresponding segment of the torrent content file. The cache client 101 informs the other peer 102 that it is interested in the segment corresponding to the selected bit 104 in the Bitfield 103. The cache client 101 thereupon starts sending piece requests for minimum size blocks 105, i.e. subsequent blocks of 16 kByte like block 106. The cache client 101 also keeps a count on the number of block requests sent. As soon as a block request is rejected, this indicates the end of the segment. The cache client 101 can now compute the segment size from the number of successful block requests multiplied with the block size. The cache client 101 at last determines the number of segments through dividing the file size by the segment size or, in case where the file size cannot be trusted, from the maximum Bitfield length multiplied with the segment size.
[26] In the embodiment described here above, it is assumed that the initially reported file size is correct, i.e. the initial client requesting the cache client 101 to cache the torrent content file provides correct and complete bytes left and bytes downloaded information. A slight modification of the embodiment described here above allows the download of (nearly complete) torrent content, even in the case where the initially reported file size is incorrect. In another alternate embodiment, multiple peers may be contacted concurrently in order to increase the probability that a peer holding a full size segment will be contacted and consequently reduce or avoid iterations of steps A and B of the method.
[27] Although the present invention has been illustrated by reference to specific embodiments it will be apparent to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied with various changes and modifications without departing from the scope thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. In other words, it is contemplated to cover any and all modifications, variations or equivalents that fall within the scope of the basic underlying principles and whose essential attributes are claimed in this patent application. It will furthermore be understood by the reader of this patent application that the words "comprising" or "comprise" do not exclude other elements or steps, that the words "a" or "an" do not exclude a plurality, and that a single element, such as a computer system, a processor, or another integrated unit may fulfill the functions of several means recited in the claims. Any reference signs in the claims shall not be construed as limiting the respective claims concerned. The terms "first", "second", third", "a", "b", "c", and the like, when used in the description or in the claims are introduced to distinguish between similar elements or steps and are not necessarily describing a sequential or chronological order. Similarly, the terms "top", "bottom", "over", "under", and the like are introduced for descriptive purposes and not necessarily to denote relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances and embodiments of
the invention are capable of operating according to the present invention in other sequences, or in orientations different from the one(s) described or illustrated above.
Claims
1. A method for reconstructing torrent content metadata, i.e. a torrent content file size, a segment length and an amount of segments of a torrent content file, without access to the torrent content metafile,
CHARACTERIZED IN THAT said method comprises the steps of:
A. obtaining a torrent content identifier from torrent signaling from a client;
B. obtaining a torrent content file size from said torrent signaling from said client; C. obtaining a tracker address from said torrent signaling from said client;
D. obtaining a peer address from a tracker;
E. contacting a peer via said peer address;
F. downloading sequential minimum size blocks of a full size segment from said peer in order to determine said segment length; and G. calculating said amount of segments from said torrent content file size and said segment length.
2. A method for reconstructing torrent content metadata according to claim 1 , CHARACTERISED IN THAT said step E comprises handshaking with said peer, thereby retrieving said peer's Bitfield, each bit in said Bitfield being representative for the availability of a corresponding segment of said torrent content file.
3. A method for reconstructing torrent content metadata according to claim 2, CHARACTERISED IN THAT said step F. comprises:
- iteratively repeating said step E and eventually also said step D until said Bitfield contains plural bits set, or until only the first bit in said Bitfield is set;
- selecting a bit in said Bitfield that is set, said bit being different from the last bit in said Bitfield that is set unless only the first bit in said Bitfield is set; - sending block requests to said peer for minimum size blocks of a segment corresponding to the selected bit until a block request is rejected;
- counting the number of block requests sent; and
- multiplying said number of block requests with the minimum size block length to thereby determine said segment length.
4. A method for reconstructing torrent content metadata according to claim 1 , CHARACTERISED IN THAT said step A comprises obtaining a unique torrent identifier or infohash identifying said torrent content file from BitTorrent signaling.
5. A method for reconstructing torrent content metadata according to claim 1 , CHARACTERISED IN THAT said step B comprises:
- obtaining the number of bytes downloaded and the number of bytes left from BitTorrent signaling; and - determining the torrent content file size by summing the number of bytes downloaded and the number of bytes left.
6. A method for reconstructing torrent content metadata according to claim 1 , CHARACTERISED IN THAT said step G comprises determining said amount of segments through dividing said torrent content file size by said segment length.
7. A method for reconstructing torrent content metadata according to claim 1 , CHARACTERISED IN THAT said method further comprises the step of:
H. downloading and caching one or more segments of said torrent content file.
8. A torrent information reconstruction device adapted to perform the method of any of claims 1 to 7.
9. A torrent information reconstruction device according to claim 8, CHARACTERISED IN THAT said torrent information reconstruction device is integrated in a BitTorrent client.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020117021192A KR101314018B1 (en) | 2009-02-10 | 2010-02-08 | A method and device for reconstructing torrent content metadata |
| CN201080007163.2A CN102318310B (en) | 2009-02-10 | 2010-02-08 | A method and device for reconstructing torrent content metadata |
| JP2011548700A JP5363593B2 (en) | 2009-02-10 | 2010-02-08 | Method and device for reconstructing torrent content metadata |
| US13/148,419 US8719430B2 (en) | 2009-02-10 | 2010-02-08 | Method and device for reconstructing torrent content metadata |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP09305123A EP2216958B1 (en) | 2009-02-10 | 2009-02-10 | Method and device for reconstructing torrent content metadata |
| EP09305123.3 | 2009-02-10 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2010092017A1 true WO2010092017A1 (en) | 2010-08-19 |
Family
ID=40852218
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2010/051489 Ceased WO2010092017A1 (en) | 2009-02-10 | 2010-02-08 | A method and device for reconstructing torrent content metadata |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8719430B2 (en) |
| EP (1) | EP2216958B1 (en) |
| JP (1) | JP5363593B2 (en) |
| KR (1) | KR101314018B1 (en) |
| CN (1) | CN102318310B (en) |
| AT (1) | ATE531180T1 (en) |
| WO (1) | WO2010092017A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9785937B2 (en) | 2012-04-30 | 2017-10-10 | Paul Wickliffe | Computer enabled methods and systems for facilitating micropayments via public networks |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8135912B2 (en) | 2009-05-18 | 2012-03-13 | Hola Networks, Ltd. | System and method of increasing cache size |
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| WO2012031031A2 (en) | 2010-08-31 | 2012-03-08 | Lawrence Ganeshalingam | Method and systems for processing polymeric sequence data and related information |
| CN102075581B (en) * | 2011-01-25 | 2013-06-12 | 中国科学院计算技术研究所 | Data transmission method and device oriented to distributed file system |
| WO2012122546A2 (en) | 2011-03-09 | 2012-09-13 | Lawrence Ganeshalingam | Biological data networks and methods therefor |
| US8745158B2 (en) * | 2011-09-30 | 2014-06-03 | Avid Technology, Inc. | Application-guided bandwidth-managed caching |
| WO2013192631A1 (en) * | 2012-06-22 | 2013-12-27 | Maltbie Dan | System and method for secure, high-speed transfer of very large files |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| CN104539727A (en) * | 2015-01-15 | 2015-04-22 | 北京国创富盛通信股份有限公司 | Cache method and system based on AP platform |
| CN104539728A (en) * | 2015-01-15 | 2015-04-22 | 北京国创富盛通信股份有限公司 | P2P transmission method and system based on AP |
| US11023846B2 (en) | 2015-04-24 | 2021-06-01 | United Parcel Service Of America, Inc. | Location-based pick up and delivery services |
| CN105095511A (en) * | 2015-09-08 | 2015-11-25 | 浪潮(北京)电子信息产业有限公司 | File processing method, apparatus and system based on distributed system |
| CN108964845B (en) | 2018-07-03 | 2021-04-16 | 网宿科技股份有限公司 | A method and device for acquiring BT resource information |
| US10911337B1 (en) * | 2018-10-10 | 2021-02-02 | Benjamin Thaddeus De Kosnik | Network activity monitoring service |
| EP3780557B1 (en) | 2019-02-25 | 2023-02-15 | Bright Data Ltd. | System and method for url fetching retry mechanism |
| EP4383686A1 (en) | 2019-04-02 | 2024-06-12 | Bright Data Ltd. | System and method for managing non-direct url fetching service |
| EP4377817A4 (en) | 2021-07-26 | 2025-05-28 | Bright Data Ltd. | WEB BROWSER EMULATION IN A DEDICATED MIDDLE BOX |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4208920B2 (en) * | 2005-01-28 | 2009-01-14 | 株式会社グリッド・ソリューションズ | How to download files using BitTorrent protocol |
| JP4950295B2 (en) * | 2006-08-21 | 2012-06-13 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Distributed server network for providing triple play services to end users |
| CN100493094C (en) * | 2006-08-25 | 2009-05-27 | 清华大学 | P2P data message detection method based on character code |
| JP2008146517A (en) * | 2006-12-13 | 2008-06-26 | Hitachi Ltd | Data distribution system and index holding device |
| US8122488B2 (en) * | 2007-05-18 | 2012-02-21 | Yangaroo, Inc. | Media file distribution system and method |
| US20080307094A1 (en) * | 2007-06-11 | 2008-12-11 | Olli Karonen | Association of peer-to-peer contribution credits with multiple devices |
| US8386630B1 (en) * | 2007-09-09 | 2013-02-26 | Arris Solutions, Inc. | Video-aware P2P streaming and download with support for real-time content alteration |
| CN101184002A (en) * | 2007-12-14 | 2008-05-21 | 国家广播电影电视总局广播科学研究院 | A method and device for in-depth monitoring of point-to-point traffic |
| US8015283B2 (en) * | 2008-04-30 | 2011-09-06 | Motion Picture Laboratories, Inc. | Cooperative monitoring of peer-to-peer network activity |
| WO2010033732A1 (en) * | 2008-09-17 | 2010-03-25 | Vuze, Inc. | Associative construction of multimedia subscriptions |
| US8204915B2 (en) * | 2009-02-13 | 2012-06-19 | Alcatel Lucent | Apparatus and method for generating a database that maps metadata to P2P content |
| US8280958B2 (en) * | 2009-07-13 | 2012-10-02 | International Business Machines Corporation | List passing in a background file sharing network |
-
2009
- 2009-02-10 EP EP09305123A patent/EP2216958B1/en not_active Not-in-force
- 2009-02-10 AT AT09305123T patent/ATE531180T1/en not_active IP Right Cessation
-
2010
- 2010-02-08 WO PCT/EP2010/051489 patent/WO2010092017A1/en not_active Ceased
- 2010-02-08 JP JP2011548700A patent/JP5363593B2/en not_active Expired - Fee Related
- 2010-02-08 CN CN201080007163.2A patent/CN102318310B/en not_active Expired - Fee Related
- 2010-02-08 US US13/148,419 patent/US8719430B2/en not_active Expired - Fee Related
- 2010-02-08 KR KR1020117021192A patent/KR101314018B1/en not_active Expired - Fee Related
Non-Patent Citations (3)
| Title |
|---|
| BRAM COHEN: "BEP 3: The BitTorrent Protocol Specification", 28 February 2008 (2008-02-28), pages 1 - 9, XP002537916, Retrieved from the Internet <URL:http://www.bittorrent.org/beps/bep_0003.html> [retrieved on 20090716] * |
| FONSECA J ET AL: "BitTorrent Protocol -- BTP/1.0", INTERNET CITATION, XP002418253, Retrieved from the Internet <URL:http://www.nitro.dk/ jonas/bittorrent/bittorrent-rfc.ps> [retrieved on 20070202] * |
| GREG HAZEL: "BEP 9: Extension for Peers to Send Metadata Files", 6 May 2008 (2008-05-06), pages 1 - 6, XP002537915, Retrieved from the Internet <URL:http://www.bittorrent.org/beps/bep_0009.html> [retrieved on 20090716] * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9785937B2 (en) | 2012-04-30 | 2017-10-10 | Paul Wickliffe | Computer enabled methods and systems for facilitating micropayments via public networks |
Also Published As
| Publication number | Publication date |
|---|---|
| JP5363593B2 (en) | 2013-12-11 |
| CN102318310A (en) | 2012-01-11 |
| JP2012517629A (en) | 2012-08-02 |
| US20120047202A1 (en) | 2012-02-23 |
| ATE531180T1 (en) | 2011-11-15 |
| KR101314018B1 (en) | 2013-10-02 |
| EP2216958B1 (en) | 2011-10-26 |
| US8719430B2 (en) | 2014-05-06 |
| CN102318310B (en) | 2014-11-05 |
| EP2216958A1 (en) | 2010-08-11 |
| KR20110116219A (en) | 2011-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8719430B2 (en) | Method and device for reconstructing torrent content metadata | |
| US9106668B2 (en) | Distributed peer location in peer-to-peer file transfers | |
| JP5514315B2 (en) | Chunk format download on content distribution network | |
| US8037135B2 (en) | Automatic distributed downloading | |
| US20060224687A1 (en) | Method and apparatus for offline cooperative file distribution using cache nodes | |
| US20100161752A1 (en) | Method and System of Administrating a Peer-to-Peer File Sharing Network | |
| US8028019B2 (en) | Methods and apparatus for data transfer in networks using distributed file location indices | |
| CN108173774B (en) | Client upgrading method and system | |
| CN101902346A (en) | P2P (Point to Point) content caching system and method | |
| US20140359066A1 (en) | System, method and device for offline downloading resource and computer storage medium | |
| RU2520430C2 (en) | Method and apparatus for loading data | |
| US20060236386A1 (en) | Method and apparatus for cooperative file distribution in the presence of firewalls | |
| CN112732775A (en) | Method and device for processing block node data, computer equipment and storage medium | |
| KR20130103599A (en) | Traffic localization in peer-to-peer networks | |
| Dale et al. | apt-p2p: A peer-to-peer distribution system for software package releases and updates | |
| EP2706753B1 (en) | Technique for processing a content distribution request | |
| Karapapas et al. | Enhancing ipfs bitswap | |
| US20120084429A1 (en) | Methods and Apparatus for Identifying Peers on a Peer-to-Peer Network | |
| CN109769019B (en) | Consistency load balancing method and device | |
| CN107659634B (en) | Method, device and equipment for selecting neighbor node and computer storage medium | |
| CN115766701B (en) | Decentralizing downloading method for shared large file | |
| CN113747252A (en) | Multimedia resource transmission method, device and system | |
| KR101383906B1 (en) | Method for preventing copylighted files from being distributed and copylight protection apparatus using the same | |
| Freedman | Democratizing content distribution | |
| Azhigulov et al. | Analyzing The Bittorrent Ecosystem Of Central Asia |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WWE | Wipo information: entry into national phase |
Ref document number: 201080007163.2 Country of ref document: CN |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 10702509 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2011548700 Country of ref document: JP |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| ENP | Entry into the national phase |
Ref document number: 20117021192 Country of ref document: KR Kind code of ref document: A |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 13148419 Country of ref document: US |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 10702509 Country of ref document: EP Kind code of ref document: A1 |