US20080066182A1 - Security techniques for cooperative file distribution - Google Patents
Security techniques for cooperative file distribution Download PDFInfo
- Publication number
- US20080066182A1 US20080066182A1 US11/519,990 US51999006A US2008066182A1 US 20080066182 A1 US20080066182 A1 US 20080066182A1 US 51999006 A US51999006 A US 51999006A US 2008066182 A1 US2008066182 A1 US 2008066182A1
- Authority
- US
- United States
- Prior art keywords
- package
- peers
- tracker
- request
- storage
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
Definitions
- the present invention relates generally to communication methods and systems, and more particularly, to cooperative and secure methods and systems for sharing one or more files among users.
- HTTP Hypertext Transfer Protocol
- a number of techniques have been proposed or suggested for reducing the bandwidth demands of file delivery on the server, using peer-to-peer content sharing.
- a peer-to-peer content sharing model often referred to as “cooperative distribution,” one or more users that have downloaded a file from the server can share the file with other users.
- a cooperative distribution model allows a server to deliver large files in a reliable manner that scales with the number of requesting users.
- cooperative distribution models exploit the underutilized upstream bandwidth of existing users.
- the BitTorrentTM file distribution system described, for example, in http://www.bittorrent.com/documentation.html, or Bram Cohen, “Incentives Build Robustness in BitTorrent,” http://www.bittorrent.com/bittorrentecon.pdf (May 22, 2003) is an example of a cooperative distribution technique.
- the various users upload pieces of the file to each other.
- a BitTorrent user trades pieces of a file that the user has with other required pieces that other users have until the complete file is obtained. In this manner, the cost of uploading a file is redistributed to the users of the file and the cost of hosting a popular file is more affordable.
- a method and system are provided for generating an encryption key or a nonce (or both) for a package containing one or more files that are to be sent in a cooperative file distribution system. Initially, samples are obtained of at least a portion of each of the files. Thereafter, a hash is applied to the samples and the encryption key or nonce (or both) are generated from a result of the hash.
- random access encryption techniques are employed to encrypt a package containing one or more files to be sent in a cooperative file distribution system.
- the package is first separated into pieces of a predefined size, and then a random access encryption technique is applied to each of the pieces.
- the encrypted package is comprised of the encrypted pieces.
- one or more storage proxies are allocated to a package to be transmitted in a cooperative file distribution system.
- the load of each of storage proxies is evaluated, and a weight is assigned to each storage proxy based on the evaluated load. Thereafter, a storage proxy is selected for the package using one or more predefined criteria to balance a load among the storage proxies.
- Another aspect of the invention controls access to a tracker in a cooperative file distribution system.
- the tracker allows peers associated with related content to discover each other.
- the tracker receives a request to upload or download content. Thereafter, the tracker determines if the sender of the request is authorized.
- the tracker will provide a security token to the sender of the request, whereby the security token can then be used to establish an authorization between the sender of the request and the tracker.
- content such as a package of one or more files
- content can automatically expire using a defined expiration period when the content is uploaded into the system.
- a variable announce interval mechanism is disclosed that allows the tracker to control how often the tracker will receive a message, such as an announcement or a heartbeat message, from peers in the system.
- FIG. 1 is a schematic block diagram illustrating a conventional BitTorrent file distribution system
- FIG. 2 is a schematic block diagram of a cooperative file distribution system incorporating features of the present invention
- FIG. 3 illustrates an exemplary key generation process for generating an encryption key and nonce in accordance with an exemplary embodiment of the present invention
- FIG. 4 illustrates an exemplary encryption process for encrypting a package of files using the encryption key and nonce generated by the process of FIG. 3 ;
- FIG. 5 illustrates the transmission of encrypted data in accordance with the present invention between one or more senders and one or more recipients
- FIG. 6 is a communication sequence diagram in accordance with a Unified Modeling Language (UML) notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for uploading (publishing) content into the cooperative file sharing system;
- UML Unified Modeling Language
- FIGS. 7A through 7C collectively, are a functional specification for a storage proxy allocation process incorporating features of the present invention.
- FIGS. 8A and 8B collectively, are pseudo code for an exemplary announce interval computation process incorporating features of the present invention.
- FIG. 9 is a communication sequence diagram in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for downloading content in the cooperative file sharing system;
- FIG. 10 is a communication sequence diagram in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for various operations in the cooperative file sharing system;
- FIG. 11 is a sample table identifying an exemplary token format.
- the present invention provides improved security techniques for a cooperative file distribution system.
- FIG. 1 is a schematic block diagram illustrating a conventional BitTorrent file distribution system 100 .
- a sender 110 desiring to send one or more large files 105 to a receiver 120 , interacts with a tracker 130 that is part of the BitTorrent file distribution system 100 .
- BitTorrent Protocol http://www.bittorrent.com/protocol.html
- BitTorrent Guide http://www.bittorrent.com/guide.html
- a corresponding static file 114 with extension .torrent is put on a web server 160 .
- a BitTorrent client 116 executing on the sender computing device 110 typically initiates a web browser 118 , for example, via a manual post 140 , to place the torrent file 114 on the BitTorrent web server 160 .
- the torrent file 114 can be sent by email to the receiver 120 .
- the web browser 118 communicates with the BitTorrent web server 160 , for example, by means of conventional HTTP communications 170 .
- the .torrent file 114 contains information about the file, including its length, name, and hashing information, and the web address (e.g., a URL) of a tracker 130 . Trackers 130 are responsible for helping users find each other.
- Trackers 130 communicate using a protocol that may be layered on top of HTTP in which a downloader 110 , 120 sends information regarding the one or more files that the user is downloading, the port that the user is listening on, and similar information, and the tracker 130 responds with a list of contact information for peers that are downloading the same file. Downloaders 110 , 120 then use this information to connect with one another.
- a downloader 110 having the complete file(s) 105 initiates a seed server 112 , using the BitTorrent client 116 .
- the bandwidth requirements of the tracker 130 and web server 160 are low, while the seed must send out at least one complete copy of the original file.
- the responsibilities of the tracker 130 are generally limited to helping peers (i.e., users) find each other.
- the tracker 130 returns a random list of peers to each user.
- the BitTorrent file distribution system 100 divides files into pieces of fixed size, typically a quarter megabyte.
- Each downloader 110 , 120 reports to all of its peers via the tracker 130 , the pieces held by the respective downloader 110 , 120 .
- each peer sends bit torrent tracker messages 165 to the tracker 130 .
- a hash of each piece can be included in the .torrent file 114 , and a given peer does not report that it has a given piece until the corresponding hash has been validated.
- the receiver 120 reads the web page on the tracker web site 160 with .torrent file 114 attached and uses the browser 126 to click on the .torrent file.
- the BitTorrent client 128 is launched on the receiver 120 and the .torrent file 124 is provided to the client process 128 .
- the BitTorrent client 128 initiates a “Leech” server 122 that allows the receiver 120 to connect to the public tracker 130 .
- the file 105 is sent from the “seed” 112 to the “leech” 122 via connection 150 , such as an offline peer-to-peer connection or swarm delivery, in a known manner.
- the file copy 105 can then be opened by the receiver 120 , for example, using an operating system function.
- FIG. 2 illustrates a cooperative file distribution system 200 that employs one or more storage proxies 260 .
- the storage proxy 260 allows an offline receiver to obtain files or pieces thereof when the receiver comes online.
- Storage node 260 can cache communications between two nodes 210 , 220 .
- the sender 210 deposits blocks of data into the proxy node 260 for subsequent retrieval by one or more receivers 220 .
- a receiver 220 can thereafter retrieve that data from the storage proxy 260 .
- the cooperative file distribution system 200 may be implemented, for example, using the BitTorrent file distribution system 100 of FIG. 1 , as modified herein to provide the features and functions of the present invention.
- the cooperative file distribution system 200 includes a tracker 230 that may be implemented using the tracker 130 of the BitTorrent file distribution system 100 of FIG. 1 , as modified herein to provide the features and functions of the present invention.
- the cooperative file distribution 200 employs a proxy service 250 to identify potential nodes that are available to serve as storage proxy 260 .
- the proxy service 250 may be integrated with the tracker 230 , as shown in FIG. 2 , or may be a stand-alone device, as would be apparent to a person of ordinary skill in the art.
- the proxy service 250 may employ, for example, a storage proxy database 255 that identifies the nodes that are available to serve as storage proxy 260 .
- the exemplary storage proxy database 255 provides a measure of the idleness, available disk space, available bandwidth, and the likelihood that the node is online (e.g., a characterization of whether the node is transient or permanent).
- the storage proxy database 255 optionally provides information on the operating system employed by the node and the current IP address of the node.
- the storage proxy database 255 is optionally indexed by a global unique identifier (GUID), in a known manner.
- GUID global unique identifier
- the exemplary profile information maintained in the storage proxy database 255 may be obtained, for example, by a profile service that can be integrated with, or independent of, the proxy service 250 .
- the profile service may obtain information directly from each potential storage proxy 260 regarding the state of the node (e.g., whether the node is behind a firewall) and its resources.
- the receiver 220 can provide a confirmation report to the profile service. In this manner, the validating information from the receivers 220 reduces the likelihood of abuse by the storage proxy 260 .
- files 205 that are transmitted in the cooperative file distribution system are encrypted in transit. In this manner, the files 205 are not compromised by eavesdropping.
- an Advanced Encryption Standard (AES) 256 in Counter (CTR) mode is employed.
- FIG. 3 illustrates an exemplary key generation process 300 for generating an encryption key 350 and nonce 360 in accordance with an exemplary embodiment of the present invention.
- the technique shown in FIG. 3 can be employed for potentially very large files.
- the encryption key 350 and nonce 360 for a package 310 comprised of one or more files 320 - 1 through 320 n are generated in an exemplary embodiment by applying a Secure Hash Algorithm (SHA-512) hash to blocks (i.e., samples) 340 from the package.
- the first 256 bits of the hash are used as the key 350
- the next 128 bits of the hash are used as the initial nonce 360 .
- SHA-512 Secure Hash Algorithm
- the encryption key 350 depends on the content of the file(s) 320 .
- the blocks 340 are five evenly-spaced 4K sampled blocks from each file 320 .
- the process 300 produces the same key 350 and nonce 360 for the same package 310 of ordered files 320 .
- two users can package the same content (e.g., the same video) and share a torrent.
- the duplicate content only needs to be stored once.
- users who independently publish the same data can take advantage of sharing a P2P torrent without being aware of each other.
- a given file 320 is less than 20K, the whole file is used.
- the use of the blocks 330 allows the key 350 and nonce 360 to be generated without reading the entire file(s), which can be long, in a similar manner to a thumbprint. Otherwise, each file would have to be scanned twice, once to generate the key and nonce, and once to hash it for torrent packaging, which would take too long.
- FIG. 4 illustrates an exemplary encryption process 400 for encrypting the package 310 using the encryption key 350 and nonce 360 generated by the process 300 of FIG. 3 .
- the encryption process 400 employs a random access encryption technique that allows any individual encrypted pieces that are received by a receiver 220 to be decrypted.
- the encryption process 400 uses an AES 256/CTR technique based on the AES encryption scheme using 256-bit keys 350 , 128-bit blocks, and a 128-bit nonce 360 .
- AES 256/CTR based on the AES encryption scheme using 256-bit keys 350 , 128-bit blocks, and a 128-bit nonce 360 .
- (nonce+N) is encrypted using the key 350 and the result is applied to an exclusive or (XOR) gate (not shown) with the block to be encrypted to generate the encrypted data 450 .
- this encryption technique allows the stream to be decrypted in random order.
- CTR See, for example, Wikipedia, “Block Cipher Modes of Operation,” (http://en.wikipedia.org/wiki/Block_cipher_modes_of operation).
- FIG. 5 illustrates the transmission of encrypted data in accordance with the present invention between one or more senders 510 - 1 and 520 - 2 and one or more recipients 520 - 1 and 520 - 2 .
- data is transmitted in the exemplary cooperative file distribution system using a storage proxy 515 and a tracker 525 , as discussed above in conjunction with FIGS. 1 and 2 .
- the data is delivered through the cooperative file distribution system as encrypted data.
- the clear data is handed off to the Bit Torrent system as encrypted data.
- the clear data 310 is encrypted into encrypted data 450 using the exemplary encryption process 400 shown in FIG. 4 .
- the storage proxy 515 does not have the key 350 or nonce 360 .
- the senders 510 and receivers 520 have the pando files appropriate for the transmitted information, such as the pando files 530 - 1 for the sender 510 - 1 and receiver 520 - 1 .
- the pando file 530 includes the key 350 and nonce 360 for the encrypted data 450 , which allows the recipient 520 - 1 to decrypt the encrypted data 450 and access the original clear data 310 .
- the encrypted data 450 is delivered without the ability to decrypt the data midstream.
- the encrypted data 450 is thus delivered with the benefits of Bit Torrent (including piece by piece integrity checks) without being able to access the original data.
- the data is stored by the storage proxy 515 but the storage proxy 515 has no ability to access the underlying clear data 310 .
- FIG. 6 is a communication sequence diagram 600 in accordance with a Unified Modeling Language (UML) notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for uploading (publishing) content into the cooperative file sharing system.
- UML Unified Modeling Language
- the communication sequence 600 is initiated during step 650 by the sender 510 attempting to login to obtain permission to send one or more files.
- the sender 510 and services processor 630 have a “session start” message exchange, whereby the sender 510 provides a node identifier, and the services processor 630 determines if the sender 510 has the appropriate permissions to send the desired file(s). If the sender 510 is approved, the sender 510 receives a “session start result” message containing, for example, a session identifier, and indication that the sender node was verified.
- the services processor 630 controls authentication and database access.
- the sender 510 After the sender 510 is validated by the message exchange 650 , the sender 510 attempts to start a session using message exchange 655 . Generally, the sender 510 sends a “start” message to the services processor 630 , which executes a storage proxy allocation process 700 , discussed further below in conjunction with FIGS. 7A through 7C . Upon selecting a storage proxy 515 and tracker 525 , the services processor 630 will store the information in the database 635 and provide the result to the sender 510 , with an identification of the assigned tracker 525 and a token, discussed further below in a section entitled “Tracker Tokens.” Generally, tracker tokens are used to control access and use of the tracker 525 , without requiring further database access. The token is a key that can be decrypted by the tracker 525 . Among other information, the token contains the last torrent update time.
- the sender 610 announces his or herself to the tracker 525 , during a message exchange 660 .
- the sender 610 sends an announce message to the tracker 525 .
- the announce message includes the assigned token, which allows the tracker 525 to validate the sender 610 .
- the announce message will trigger the tracker 525 to execute an announce interval computation process 800 , discussed further below in conjunction with FIG. 8 .
- the tracker 525 may be required to communicate with the services processor 630 to obtain (update) the torrent information, using the torrent identifier, during a message exchange 665 .
- the tracker 525 After implementing the announce interval computation process 800 , the tracker 525 will send an announce response to the sender 510 .
- the announce response includes a listing of the peers associated with the bit torrent, discussed further below in a section entitled “Tracker Peer Listing,” as well as the assigned announce interval (two seconds in this example).
- message exchange 670 occurs between the tracker 525 and the assigned storage proxy 515 .
- the message exchange 670 includes a request for the storage proxy 515 to join the bit torrent.
- the storage proxy 515 will respond to the tracker 525 with an announce message, which will trigger the tracker 525 to execute the announce interval computation process 800 .
- the sender 510 After the defined announce interval, the sender 510 will send another announce message during message exchange 675 .
- the sender 510 publishes the file on the assigned storage proxy 515 .
- the sender 510 will continue to announce periodically to the tracker 525 in accordance with the assigned announce interval.
- the sender 510 notifies the services processor 630 that the uploading is complete.
- the session is terminated during a message exchange 690 between the sender 510 and the 630 .
- FIGS. 7A through 7C are a functional specification for a storage proxy allocation process 700 incorporating features of the present invention.
- the storage proxy allocation process 700 collects statistics 710 on each storage proxy to help determine the load experienced by each storage proxy.
- the collected statistics 710 include the total number of published torrents currently assigned to the storage proxy, the maximum number allowed and the amount of available disk space.
- the collected statistics 710 are stored in a storage proxies table 720 , for example, along with an allocation factor, such as a user controlled number between 0 and 1.
- the storage proxy allocation process 700 includes a section 730 for selecting a storage proxy. As shown in FIG. 7B , during section 730 , the storage proxies table 720 is evaluated, and each storage proxy is assigned a weight based on the load values indicated in the table. Each storage proxy is selected with a frequency that matches its weight.
- the storage proxy allocation process 700 allows storage proxies to be grouped in section 740 , with weights calculated based on the assigned group. In this manner, different levels of services can be offered, such as higher quality services at a premium.
- the weight function 750 of the storage proxy allocation process 700 is shown in FIGS. 7B and 7C .
- the available disk space is first computed in section 760 .
- four types of storage proxy resources are evaluated in section 770 .
- the weight is computed in statement 780 . Since all of the factors are multiplied in the weight computation 780 , any one factor being zero (e.g., available disk space) can prevent a storage proxy from being allocated any more torrents. Taking the weight to a fractional power (e.g., ⁇ 0.25), for example, smooths the distribution of weights, reducing the tendency of the equation to over-allocate for the most underutilized storage proxy. This factor can be manipulated to make the allocation scheme sufficiently responsive without being over-responsive.
- a fractional power e.g., ⁇ 0.25
- FIGS. 8A and 8B collectively, are pseudo code for an exemplary announce interval computation process 800 incorporating features of the present invention.
- the announce interval computation process 800 is initiated whenever the sender 510 , receiver 520 or storage proxy 515 attempt to communicate with the tracker 525 .
- the announce intervals are periodic heart beats.
- the announce intervals are tuned to (i) reduce the load on the tracker 525 ; (ii) improve the efficiency of the swarmed transfer; and (iii) provide the appearance of responsiveness.
- the announce interval can be proportional to the number of peers in a torrent.
- the announce interval computation process 800 allows the recency of the data to be balanced with the load. In general, the larger the number of peers in a swarm, the less time that is required to keep the information up to date (i.e., there is less impact if a peer logs off, so can be tracked in longer intervals).
- the announce interval computation process 800 contains a number of conditional statements for establishing the announce interval for various situations.
- a first section 810 establishes a fixed announce interval for storage proxies. Being a critical contributor to the torrent transfer, storage proxies are tracked more closely than other peers.
- Section 820 establishes the announce interval for the situation where the storage proxy is being allocated. When a storage proxy 515 is being assigned to a torrent being uploaded (see storage proxy allocation process 700 discussed above), it is desired for the storage proxy and the sender 510 to connect quickly, so the announce interval is set to a lower value.
- Section 830 establishes the announce interval for the situation where a torrent has been inactive for a while. Generally, the announce interval can be increased for older torrents that have not been of significant interest for a period of time.
- section 840 addresses the situation discussed above, where there is a large number of peers in a torrent.
- Section 850 establishes the announce interval for the situation where the senders are not behind firewalls. When the seeds are not behind firewalls, other peers can connect to them, therefore a longer announce interval is appropriate. Likewise, if a seed is behind a firewall, a shorter announce interval is appropriate, since other peers cannot connect directly to the seeds and the peers must be given addresses (for example, of storage proxies 515 containing the desired content) to connect to.
- the tracker announce response message 660 ( FIG. 6 ) contains a list of the Internet Protocol (IP) addresses and listening ports of the peers in a torrent.
- IP Internet Protocol
- the listing is optimized to be as useful as possible for the peers. Therefore, not all possible addresses are listed.
- the listing of a peer in the tracker announce response message 660 is controlled by the following announce arguments:
- the response can be randomized in the following manner:
- FIG. 9 is a communication sequence diagram 900 in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for downloading content in the cooperative file sharing system.
- the downloading process 900 is initiated using a session start message exchange 950 between the receiver 520 and the services processor 630 , in a similar manner to the message exchange 650 of FIG. 6 , whereby the receiver 520 provides a node identifier, and the services processor 630 determines if the receiver 520 has the appropriate permissions to receive the desired file(s). If the receiver 520 is approved, the receiver 520 receives a “session start result” message containing, for example, a session identifier, and indication that the receiver node was verified. As indicated above, the services processor 630 controls authentication and database access.
- the receiver 520 After the receiver 520 is validated by the message exchange 950 , the receiver 520 attempts to start a session using message exchange 955 . Generally, the receiver 520 sends a “start” message to the services processor 630 , which executes the storage proxy allocation process 700 , discussed above in conjunction with FIGS. 7A through 7C . Upon selecting a storage proxy 515 and tracker 525 , the services processor 630 will store the information in the database 635 and provide the result to the receiver 520 , with an identification of the assigned tracker 525 and a token, discussed below in the section entitled “Tracker Tokens.” As indicated above, tracker tokens are used to control access and use of the tracker 525 , without requiring further database access. The token is a key that can be decrypted by the tracker 525 . Among other information, the token contains the last torrent update time.
- the receiver 520 announces his or herself to the tracker 525 , during a message exchange 960 .
- the receiver 520 sends an announce message to the tracker 525 .
- the announce message includes the assigned token, which allows the tracker 525 to validate the receiver 520 .
- the announce message will trigger the tracker 525 to execute the announce interval computation process 800 , discussed above in conjunction with FIG. 8 .
- the tracker 525 may be required to communicate with the services processor 630 to obtain (update) the torrent information, using the torrent identifier, during a message exchange 965 .
- the tracker 525 After implementing the announce interval computation process 800 , the tracker 525 will send an announce response to the receiver 520 .
- the announce response includes a listing of the storage proxy 515 and sender 510 associated with the file(s), as well as the assigned announce interval.
- the receiver 520 downloads the file from the assigned storage proxy 515 or sender 510 (or both). Thereafter, during message exchange 975 , the receiver 520 notifies the services processor 630 that the downloading is complete. Finally, the session is terminated during a message exchange 980 between the receiver 520 and the 630 .
- FIG. 10 is a communication sequence diagram 1000 in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities of FIG. 2 for various operations in the cooperative file sharing system.
- the tracker 525 reports its state to the services processor 630 , and the services processor 630 records the state information in the database 635 .
- each storage proxy 515 reports its state, such as its current load information, to the services processor 630 , and the services processor 630 records the information in the database 635 .
- a storage proxy deallocation process 1030 there are three possible scenarios whereby a given storage proxy can be deallocated.
- the tracker 525 recognizes that the storage proxy is not needed, for example, because there are no peers remaining in the torrent, or when there are a sufficient number of seeds and the storage proxy is no longer needed (to reduce costs).
- bit torrents can be deleted after a defined expiration period. For example, each time a file is uploaded, the expiration period can be extended by two weeks. Therefore, a bit torrent available for two weeks from the last time the BT was published. (pstart received plus 14 days).
- the services processor 630 can expire the bit torrent and deallocate the associated storage proxy 515 after the bit torrent expires.
- the storage proxy 515 self terminates by notifying the services processor 630 , if the storage proxy believes that the torrent has expired, based on the expiration interval that was indicated in the join torrent message 670 ( FIG. 6 ).
- the tracker 525 and services processor 630 can synchronize the meta data associated with a bit torrent.
- tracker tokens are used to control access to and use of the tracker 525 and reduce the number of accesses to the database(s) 635 for authentication purposes.
- the tracker tracks all peers who are participating in a torrent and help these peers to discover each other. Peers announce their presence to the tracker 525 on regular (announce) intervals, as discussed above, and are responded to with a listing of the addresses of other peers.
- peers When peers upload or download content (package containing one or more files), as discussed above in conjunction with FIGS. 6 and 9 , respectively, the package has an associated a tracker 525 .
- the sender 510 or receiver 520 send a start message 655 or 955 , which includes the torrent identifier and peer identifier, they will receive a tracker URL and a tracker token string in the start result message, bound to the tracker, torrent identifier and peer identifier.
- the peer uses the tracker URL for tracker announcements, and includes the token string in the announcements.
- an announce response message may include a “token-expired” error.
- a peer may issue a request for a token from the tracker 525 .
- the token is an encrypted binary data structure.
- the tracker 525 and 630 can share a secret key. In one implementation, 128 bits AES encryption is used.
- FIG. 11 is a sample table identifying an exemplary token format 1100 .
- the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon.
- the computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein.
- the computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used.
- the computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
- the computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein.
- the memories could be distributed or local and the processors could be distributed or singular.
- the memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices.
- the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
Abstract
Description
- The present invention relates generally to communication methods and systems, and more particularly, to cooperative and secure methods and systems for sharing one or more files among users.
- The providers of popular, large digital files, such as software, music or video files, must keep pace with the ever increasing bandwidth demands for delivering such files. As the popularity of a file increases, a larger number of users are requesting the file and more bandwidth is required to deliver the file. With conventional Hypertext Transfer Protocol (HTTP) file delivery techniques, for example, the bandwidth requirements increase linearly with the number of requesting users, and quickly becomes prohibitively expensive.
- A number of techniques have been proposed or suggested for reducing the bandwidth demands of file delivery on the server, using peer-to-peer content sharing. In a peer-to-peer content sharing model, often referred to as “cooperative distribution,” one or more users that have downloaded a file from the server can share the file with other users. A cooperative distribution model allows a server to deliver large files in a reliable manner that scales with the number of requesting users. Among other benefits, cooperative distribution models exploit the underutilized upstream bandwidth of existing users.
- The BitTorrent™ file distribution system, described, for example, in http://www.bittorrent.com/documentation.html, or Bram Cohen, “Incentives Build Robustness in BitTorrent,” http://www.bittorrent.com/bittorrentecon.pdf (May 22, 2003) is an example of a cooperative distribution technique. When multiple users are downloading the same file at the same time using the BitTorrent file distribution system, the various users upload pieces of the file to each other. In other words, a BitTorrent user trades pieces of a file that the user has with other required pieces that other users have until the complete file is obtained. In this manner, the cost of uploading a file is redistributed to the users of the file and the cost of hosting a popular file is more affordable.
- While the BitTorrent file distribution system provides an effective mechanism for distributing large files in a cost effective manner, it suffers from a number of limitations, which if overcome, could further improve the utility and efficiency of cooperative file distribution. In particular, if a BitTorrent receiver is offline, then the receiver is unable to obtain files from other users. U.S. patent application Ser. No. 11/096,193, filed Mar. 31, 2005, entitled “Method and Apparatus for Offline Cooperative File Distribution Using Cache Nodes,” discloses a cooperative file distribution system that uses one or more storage proxies to store the files that are being transferred among users.
- A need still exists for improved security techniques for a cooperative file distribution system.
- Generally, security techniques are provided for cooperative file distribution. According to one aspect of the invention, a method and system are provided for generating an encryption key or a nonce (or both) for a package containing one or more files that are to be sent in a cooperative file distribution system. Initially, samples are obtained of at least a portion of each of the files. Thereafter, a hash is applied to the samples and the encryption key or nonce (or both) are generated from a result of the hash.
- According to another aspect of the invention, random access encryption techniques are employed to encrypt a package containing one or more files to be sent in a cooperative file distribution system. The package is first separated into pieces of a predefined size, and then a random access encryption technique is applied to each of the pieces. The encrypted package is comprised of the encrypted pieces.
- According to yet another aspect of the invention, one or more storage proxies are allocated to a package to be transmitted in a cooperative file distribution system. The load of each of storage proxies is evaluated, and a weight is assigned to each storage proxy based on the evaluated load. Thereafter, a storage proxy is selected for the package using one or more predefined criteria to balance a load among the storage proxies.
- Another aspect of the invention controls access to a tracker in a cooperative file distribution system. The tracker allows peers associated with related content to discover each other. The tracker receives a request to upload or download content. Thereafter, the tracker determines if the sender of the request is authorized. The tracker will provide a security token to the sender of the request, whereby the security token can then be used to establish an authorization between the sender of the request and the tracker.
- According to further aspects of the invention, content, such as a package of one or more files, can automatically expire using a defined expiration period when the content is uploaded into the system. In addition, a variable announce interval mechanism is disclosed that allows the tracker to control how often the tracker will receive a message, such as an announcement or a heartbeat message, from peers in the system.
- A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.
-
FIG. 1 is a schematic block diagram illustrating a conventional BitTorrent file distribution system; -
FIG. 2 is a schematic block diagram of a cooperative file distribution system incorporating features of the present invention; -
FIG. 3 illustrates an exemplary key generation process for generating an encryption key and nonce in accordance with an exemplary embodiment of the present invention; -
FIG. 4 illustrates an exemplary encryption process for encrypting a package of files using the encryption key and nonce generated by the process ofFIG. 3 ; -
FIG. 5 illustrates the transmission of encrypted data in accordance with the present invention between one or more senders and one or more recipients; -
FIG. 6 is a communication sequence diagram in accordance with a Unified Modeling Language (UML) notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for uploading (publishing) content into the cooperative file sharing system; -
FIGS. 7A through 7C , collectively, are a functional specification for a storage proxy allocation process incorporating features of the present invention; -
FIGS. 8A and 8B , collectively, are pseudo code for an exemplary announce interval computation process incorporating features of the present invention; -
FIG. 9 is a communication sequence diagram in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for downloading content in the cooperative file sharing system; -
FIG. 10 is a communication sequence diagram in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for various operations in the cooperative file sharing system; and -
FIG. 11 is a sample table identifying an exemplary token format. - The present invention provides improved security techniques for a cooperative file distribution system.
-
FIG. 1 is a schematic block diagram illustrating a conventional BitTorrent file distribution system 100. As shown inFIG. 1 , asender 110, desiring to send one or morelarge files 105 to areceiver 120, interacts with atracker 130 that is part of the BitTorrent file distribution system 100. For a more detailed discussion of the BitTorrent file distribution system 100, see, for example, BitTorrent Protocol, http://www.bittorrent.com/protocol.html, or BitTorrent Guide, http://www.bittorrent.com/guide.html, each incorporated by reference herein. - Generally, to publish one or
more files 105 using the BitTorrent file distribution system 100, a correspondingstatic file 114 with extension .torrent is put on aweb server 160. In particular, as shown inFIG. 1 , a BitTorrentclient 116 executing on thesender computing device 110 typically initiates aweb browser 118, for example, via amanual post 140, to place thetorrent file 114 on the BitTorrentweb server 160. Alternatively, thetorrent file 114 can be sent by email to thereceiver 120. Theweb browser 118 communicates with the BitTorrentweb server 160, for example, by means ofconventional HTTP communications 170. The.torrent file 114 contains information about the file, including its length, name, and hashing information, and the web address (e.g., a URL) of atracker 130.Trackers 130 are responsible for helping users find each other. -
Trackers 130 communicate using a protocol that may be layered on top of HTTP in which adownloader tracker 130 responds with a list of contact information for peers that are downloading the same file.Downloaders - To make one or
more files 105 available, adownloader 110 having the complete file(s) 105 initiates aseed server 112, using the BitTorrent client116. The bandwidth requirements of thetracker 130 andweb server 160 are low, while the seed must send out at least one complete copy of the original file. - The responsibilities of the
tracker 130 are generally limited to helping peers (i.e., users) find each other. Typically, thetracker 130 returns a random list of peers to each user. In order to keep track of the files and file pieces held by eachuser downloader tracker 130, the pieces held by therespective downloader torrent tracker messages 165 to thetracker 130. To verify data integrity, a hash of each piece can be included in the .torrent file 114, and a given peer does not report that it has a given piece until the corresponding hash has been validated. - On the
receiver side 120, thereceiver 120 reads the web page on thetracker web site 160 with .torrent file 114 attached and uses thebrowser 126 to click on the .torrent file. As a result, theBitTorrent client 128 is launched on thereceiver 120 and the .torrent file 124 is provided to theclient process 128. In addition, theBitTorrent client 128 initiates a “Leech”server 122 that allows thereceiver 120 to connect to thepublic tracker 130. In this manner, thefile 105 is sent from the “seed” 112 to the “leech” 122 viaconnection 150, such as an offline peer-to-peer connection or swarm delivery, in a known manner. Thefile copy 105 can then be opened by thereceiver 120, for example, using an operating system function. -
FIG. 2 illustrates a cooperativefile distribution system 200 that employs one ormore storage proxies 260. Among other benefits, thestorage proxy 260 allows an offline receiver to obtain files or pieces thereof when the receiver comes online. -
Storage node 260 can cache communications between twonodes sender 210 deposits blocks of data into theproxy node 260 for subsequent retrieval by one ormore receivers 220. Areceiver 220 can thereafter retrieve that data from thestorage proxy 260. - The cooperative
file distribution system 200 may be implemented, for example, using the BitTorrent file distribution system 100 ofFIG. 1 , as modified herein to provide the features and functions of the present invention. As discussed hereinafter, the cooperativefile distribution system 200 includes atracker 230 that may be implemented using thetracker 130 of the BitTorrent file distribution system 100 ofFIG. 1 , as modified herein to provide the features and functions of the present invention. - In addition, as discussed further below, the
cooperative file distribution 200 employs aproxy service 250 to identify potential nodes that are available to serve asstorage proxy 260. Theproxy service 250 may be integrated with thetracker 230, as shown inFIG. 2 , or may be a stand-alone device, as would be apparent to a person of ordinary skill in the art. Theproxy service 250 may employ, for example, astorage proxy database 255 that identifies the nodes that are available to serve asstorage proxy 260. For eachpotential storage proxy 260, the exemplarystorage proxy database 255 provides a measure of the idleness, available disk space, available bandwidth, and the likelihood that the node is online (e.g., a characterization of whether the node is transient or permanent). In addition, thestorage proxy database 255 optionally provides information on the operating system employed by the node and the current IP address of the node. Thestorage proxy database 255 is optionally indexed by a global unique identifier (GUID), in a known manner. - The exemplary profile information maintained in the
storage proxy database 255 may be obtained, for example, by a profile service that can be integrated with, or independent of, theproxy service 250. For example, the profile service may obtain information directly from eachpotential storage proxy 260 regarding the state of the node (e.g., whether the node is behind a firewall) and its resources. In addition, in a further variation, after a givenreceiver 220 has received a file or a portion thereof from a givenstorage proxy 260, thereceiver 220 can provide a confirmation report to the profile service. In this manner, the validating information from thereceivers 220 reduces the likelihood of abuse by thestorage proxy 260. - According to one aspect of the invention files 205 that are transmitted in the cooperative file distribution system are encrypted in transit. In this manner, the
files 205 are not compromised by eavesdropping. In one exemplary implementation, an Advanced Encryption Standard (AES) 256 in Counter (CTR) mode is employed. -
FIG. 3 illustrates an exemplarykey generation process 300 for generating anencryption key 350 and nonce 360 in accordance with an exemplary embodiment of the present invention. The technique shown inFIG. 3 can be employed for potentially very large files. As shown inFIG. 3 , theencryption key 350 andnonce 360 for apackage 310 comprised of one or more files 320-1 through 320 n are generated in an exemplary embodiment by applying a Secure Hash Algorithm (SHA-512) hash to blocks (i.e., samples) 340 from the package. The first 256 bits of the hash are used as the key 350, and the next 128 bits of the hash are used as theinitial nonce 360. - In this manner, the
encryption key 350 depends on the content of the file(s) 320. In the exemplary implementation shown inFIG. 3 , theblocks 340 are five evenly-spaced 4K sampled blocks from each file 320. - The
process 300 produces thesame key 350 andnonce 360 for thesame package 310 of ordered files 320. In this manner, two users can package the same content (e.g., the same video) and share a torrent. The duplicate content only needs to be stored once. In addition, users who independently publish the same data can take advantage of sharing a P2P torrent without being aware of each other. - If a given file 320 is less than 20K, the whole file is used. The use of the
blocks 330 allows the key 350 and nonce 360 to be generated without reading the entire file(s), which can be long, in a similar manner to a thumbprint. Otherwise, each file would have to be scanned twice, once to generate the key and nonce, and once to hash it for torrent packaging, which would take too long. -
FIG. 4 illustrates anexemplary encryption process 400 for encrypting thepackage 310 using theencryption key 350 and nonce 360 generated by theprocess 300 ofFIG. 3 . According to one aspect of the invention, theencryption process 400 employs a random access encryption technique that allows any individual encrypted pieces that are received by areceiver 220 to be decrypted. - In one exemplary embodiment, the
encryption process 400 uses anAES 256/CTR technique based on the AES encryption scheme using 256-bit keys 350, 128-bit blocks, and a 128-bit nonce 360. As shown inFIG. 4 , for block N in the stream, (nonce+N) is encrypted using the key 350 and the result is applied to an exclusive or (XOR) gate (not shown) with the block to be encrypted to generate theencrypted data 450. As indicated above, this encryption technique allows the stream to be decrypted in random order. For a detailed description of CTR, see, for example, Wikipedia, “Block Cipher Modes of Operation,” (http://en.wikipedia.org/wiki/Block_cipher_modes_of operation). -
FIG. 5 illustrates the transmission of encrypted data in accordance with the present invention between one or more senders 510-1 and 520-2 and one or more recipients 520-1 and 520-2. As shown inFIG. 5 , data is transmitted in the exemplary cooperative file distribution system using astorage proxy 515 and atracker 525, as discussed above in conjunction withFIGS. 1 and 2 . - According to one aspect of the invention, the data is delivered through the cooperative file distribution system as encrypted data. In other words, the clear data is handed off to the Bit Torrent system as encrypted data. The
clear data 310 is encrypted intoencrypted data 450 using theexemplary encryption process 400 shown inFIG. 4 . Thestorage proxy 515 does not have the key 350 ornonce 360. As shown inFIG. 5 , thesenders 510 andreceivers 520 have the pando files appropriate for the transmitted information, such as the pando files 530-1 for the sender 510-1 and receiver 520-1. The pando file 530 includes the key 350 andnonce 360 for theencrypted data 450, which allows the recipient 520-1 to decrypt theencrypted data 450 and access the originalclear data 310. - In this manner, the
encrypted data 450 is delivered without the ability to decrypt the data midstream. Theencrypted data 450 is thus delivered with the benefits of Bit Torrent (including piece by piece integrity checks) without being able to access the original data. The data is stored by thestorage proxy 515 but thestorage proxy 515 has no ability to access the underlyingclear data 310. - Uploading Content
-
FIG. 6 is a communication sequence diagram 600 in accordance with a Unified Modeling Language (UML) notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for uploading (publishing) content into the cooperative file sharing system. As shown inFIG. 6 , thecommunication sequence 600 is initiated duringstep 650 by thesender 510 attempting to login to obtain permission to send one or more files. Thesender 510 andservices processor 630 have a “session start” message exchange, whereby thesender 510 provides a node identifier, and theservices processor 630 determines if thesender 510 has the appropriate permissions to send the desired file(s). If thesender 510 is approved, thesender 510 receives a “session start result” message containing, for example, a session identifier, and indication that the sender node was verified. Generally, theservices processor 630 controls authentication and database access. - After the
sender 510 is validated by themessage exchange 650, thesender 510 attempts to start a session usingmessage exchange 655. Generally, thesender 510 sends a “start” message to theservices processor 630, which executes a storageproxy allocation process 700, discussed further below in conjunction withFIGS. 7A through 7C . Upon selecting astorage proxy 515 andtracker 525, theservices processor 630 will store the information in thedatabase 635 and provide the result to thesender 510, with an identification of the assignedtracker 525 and a token, discussed further below in a section entitled “Tracker Tokens.” Generally, tracker tokens are used to control access and use of thetracker 525, without requiring further database access. The token is a key that can be decrypted by thetracker 525. Among other information, the token contains the last torrent update time. - After the sender 610 is notified of the
tracker 525 assigned to the bit torrent, the sender 610 announces his or herself to thetracker 525, during amessage exchange 660. As shown inFIG. 6 , the sender 610 sends an announce message to thetracker 525. The announce message includes the assigned token, which allows thetracker 525 to validate the sender 610. The announce message will trigger thetracker 525 to execute an announceinterval computation process 800, discussed further below in conjunction withFIG. 8 . In addition, based on the torrent update time included in the token, thetracker 525 may be required to communicate with theservices processor 630 to obtain (update) the torrent information, using the torrent identifier, during amessage exchange 665. - After implementing the announce
interval computation process 800, thetracker 525 will send an announce response to thesender 510. The announce response includes a listing of the peers associated with the bit torrent, discussed further below in a section entitled “Tracker Peer Listing,” as well as the assigned announce interval (two seconds in this example). If a storage proxy is required for the communication,message exchange 670 occurs between thetracker 525 and the assignedstorage proxy 515. Themessage exchange 670 includes a request for thestorage proxy 515 to join the bit torrent. Thestorage proxy 515 will respond to thetracker 525 with an announce message, which will trigger thetracker 525 to execute the announceinterval computation process 800. - After the defined announce interval, the
sender 510 will send another announce message duringmessage exchange 675. Duringmessage exchange 680, thesender 510 publishes the file on the assignedstorage proxy 515. Thesender 510 will continue to announce periodically to thetracker 525 in accordance with the assigned announce interval. Thereafter, duringmessage exchange 685, thesender 510 notifies theservices processor 630 that the uploading is complete. Finally, the session is terminated during amessage exchange 690 between thesender 510 and the 630. - Storage Proxy Allocation Process
-
FIGS. 7A through 7C , collectively, are a functional specification for a storageproxy allocation process 700 incorporating features of the present invention. As shown inFIG. 7A , the storageproxy allocation process 700 collectsstatistics 710 on each storage proxy to help determine the load experienced by each storage proxy. For example, in an exemplary embodiment, the collectedstatistics 710 include the total number of published torrents currently assigned to the storage proxy, the maximum number allowed and the amount of available disk space. The collectedstatistics 710 are stored in a storage proxies table 720, for example, along with an allocation factor, such as a user controlled number between 0 and 1. - The storage
proxy allocation process 700 includes asection 730 for selecting a storage proxy. As shown inFIG. 7B , duringsection 730, the storage proxies table 720 is evaluated, and each storage proxy is assigned a weight based on the load values indicated in the table. Each storage proxy is selected with a frequency that matches its weight. - In one exemplary embodiment, shown in
FIG. 7B , the storageproxy allocation process 700 allows storage proxies to be grouped insection 740, with weights calculated based on the assigned group. In this manner, different levels of services can be offered, such as higher quality services at a premium. - The
weight function 750 of the storageproxy allocation process 700 is shown inFIGS. 7B and 7C . As shown inFIG. 7B , the available disk space is first computed insection 760. Thereafter, in the exemplary embodiment, four types of storage proxy resources are evaluated insection 770. - Finally, the weight is computed in
statement 780. Since all of the factors are multiplied in theweight computation 780, any one factor being zero (e.g., available disk space) can prevent a storage proxy from being allocated any more torrents. Taking the weight to a fractional power (e.g., ̂0.25), for example, smooths the distribution of weights, reducing the tendency of the equation to over-allocate for the most underutilized storage proxy. This factor can be manipulated to make the allocation scheme sufficiently responsive without being over-responsive. - Announce Interval Computation Process
-
FIGS. 8A and 8B , collectively, are pseudo code for an exemplary announceinterval computation process 800 incorporating features of the present invention. The announceinterval computation process 800 is initiated whenever thesender 510,receiver 520 orstorage proxy 515 attempt to communicate with thetracker 525. The announce intervals are periodic heart beats. According to one aspect of the invention, the announce intervals are tuned to (i) reduce the load on thetracker 525; (ii) improve the efficiency of the swarmed transfer; and (iii) provide the appearance of responsiveness. For example, the announce interval can be proportional to the number of peers in a torrent. The announceinterval computation process 800 allows the recency of the data to be balanced with the load. In general, the larger the number of peers in a swarm, the less time that is required to keep the information up to date (i.e., there is less impact if a peer logs off, so can be tracked in longer intervals). - As shown in
FIG. 8A , the announceinterval computation process 800 contains a number of conditional statements for establishing the announce interval for various situations. Afirst section 810 establishes a fixed announce interval for storage proxies. Being a critical contributor to the torrent transfer, storage proxies are tracked more closely than other peers. Section 820 establishes the announce interval for the situation where the storage proxy is being allocated. When astorage proxy 515 is being assigned to a torrent being uploaded (see storageproxy allocation process 700 discussed above), it is desired for the storage proxy and thesender 510 to connect quickly, so the announce interval is set to a lower value.Section 830 establishes the announce interval for the situation where a torrent has been inactive for a while. Generally, the announce interval can be increased for older torrents that have not been of significant interest for a period of time. - As shown in
FIG. 8B ,section 840 addresses the situation discussed above, where there is a large number of peers in a torrent.Section 850 establishes the announce interval for the situation where the senders are not behind firewalls. When the seeds are not behind firewalls, other peers can connect to them, therefore a longer announce interval is appropriate. Likewise, if a seed is behind a firewall, a shorter announce interval is appropriate, since other peers cannot connect directly to the seeds and the peers must be given addresses (for example, ofstorage proxies 515 containing the desired content) to connect to. - Tracker Peer Listing
- As indicated above, the tracker announce response message 660 (
FIG. 6 ) contains a list of the Internet Protocol (IP) addresses and listening ports of the peers in a torrent. According to one aspect of the invention, the listing is optimized to be as useful as possible for the peers. Therefore, not all possible addresses are listed. - In one exemplary embodiment, the listing of a peer in the tracker announce
response message 660 is controlled by the following announce arguments: -
- NAT/external_ip—the IP address the announce message arrives from;
- IP—the internal IP address reported in the announce URL;
- port—the listening port reported in the announce URL;
- show_seeds=1|0, 0 default (indicates who has the same content (whole file));
- fw=0 not firewalled|1 firewalled|−1 don't know yet (default)
- left=0 seed|#leech|−1 don't know yet
- type=sp|peer (default)
- The response logic for the exemplary embodiment can be expressed as follows:
-
- An SP peer (type=sp) always gets an empty list (storage proxies do not make outgoing connections).
- A seed peer (left=0) only gets addresses of leeches, unless show_seeds=1 (seeds cannot communicate with other seeds).
- FW=1 is not shown to other peers (peers with firewalls are not shown to other peers), unless both are behind the same NAT.
- Peers behind different NATs don't see each other, unless peer is fw=0 (not firewalled)
- An SP is not listed if a there is a certain count of seeds or a certain count non-firewalled seeds (offload delivery from storage proxies to peers to reduce costs).
- In a further variation, if the list is longer than a specified length (such as 40-50 peers), the response can be randomized in the following manner:
-
- The SP is always the first in the response.
- X peers behind the same NAT as the requested peer are listed next.
- The other peers are uniformly selected from the complete list.
- Downloading Content
-
FIG. 9 is a communication sequence diagram 900 in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for downloading content in the cooperative file sharing system. - As shown in
FIG. 9 , thedownloading process 900 is initiated using a sessionstart message exchange 950 between thereceiver 520 and theservices processor 630, in a similar manner to themessage exchange 650 ofFIG. 6 , whereby thereceiver 520 provides a node identifier, and theservices processor 630 determines if thereceiver 520 has the appropriate permissions to receive the desired file(s). If thereceiver 520 is approved, thereceiver 520 receives a “session start result” message containing, for example, a session identifier, and indication that the receiver node was verified. As indicated above, theservices processor 630 controls authentication and database access. - After the
receiver 520 is validated by themessage exchange 950, thereceiver 520 attempts to start a session usingmessage exchange 955. Generally, thereceiver 520 sends a “start” message to theservices processor 630, which executes the storageproxy allocation process 700, discussed above in conjunction withFIGS. 7A through 7C . Upon selecting astorage proxy 515 andtracker 525, theservices processor 630 will store the information in thedatabase 635 and provide the result to thereceiver 520, with an identification of the assignedtracker 525 and a token, discussed below in the section entitled “Tracker Tokens.” As indicated above, tracker tokens are used to control access and use of thetracker 525, without requiring further database access. The token is a key that can be decrypted by thetracker 525. Among other information, the token contains the last torrent update time. - After the
receiver 520 is notified of thetracker 525 assigned to the bit torrent, thereceiver 520 announces his or herself to thetracker 525, during amessage exchange 960. As shown inFIG. 9 , thereceiver 520 sends an announce message to thetracker 525. The announce message includes the assigned token, which allows thetracker 525 to validate thereceiver 520. The announce message will trigger thetracker 525 to execute the announceinterval computation process 800, discussed above in conjunction withFIG. 8 . In addition, based on the torrent update time included in the token, thetracker 525 may be required to communicate with theservices processor 630 to obtain (update) the torrent information, using the torrent identifier, during amessage exchange 965. - After implementing the announce
interval computation process 800, thetracker 525 will send an announce response to thereceiver 520. The announce response includes a listing of thestorage proxy 515 andsender 510 associated with the file(s), as well as the assigned announce interval. - During
message exchange 970, thereceiver 520 downloads the file from the assignedstorage proxy 515 or sender 510 (or both). Thereafter, duringmessage exchange 975, thereceiver 520 notifies theservices processor 630 that the downloading is complete. Finally, the session is terminated during amessage exchange 980 between thereceiver 520 and the 630. - Maintenance Operations
-
FIG. 10 is a communication sequence diagram 1000 in accordance with a UML notation, illustrating exemplary communications and other processing performed by the various entities ofFIG. 2 for various operations in the cooperative file sharing system. - As shown in
FIG. 10 , during atracker registration process 1010, thetracker 525 reports its state to theservices processor 630, and theservices processor 630 records the state information in thedatabase 635. - During a storage
proxy registration process 1020, eachstorage proxy 515 reports its state, such as its current load information, to theservices processor 630, and theservices processor 630 records the information in thedatabase 635. - As shown in
FIG. 10 , for a storageproxy deallocation process 1030, there are three possible scenarios whereby a given storage proxy can be deallocated. In a first scenario, thetracker 525 recognizes that the storage proxy is not needed, for example, because there are no peers remaining in the torrent, or when there are a sufficient number of seeds and the storage proxy is no longer needed (to reduce costs). - In a second scenario, the
services processor 630 recognizes that a given bit torrent has expired. In one exemplary implementation, bit torrents can be deleted after a defined expiration period. For example, each time a file is uploaded, the expiration period can be extended by two weeks. Therefore, a bit torrent available for two weeks from the last time the BT was published. (pstart received plus 14 days). Theservices processor 630 can expire the bit torrent and deallocate the associatedstorage proxy 515 after the bit torrent expires. - In a third scenario, the
storage proxy 515 self terminates by notifying theservices processor 630, if the storage proxy believes that the torrent has expired, based on the expiration interval that was indicated in the join torrent message 670 (FIG. 6 ). - As shown in
FIG. 10 , for a tracker/services synchronization process 1040, thetracker 525 andservices processor 630 can synchronize the meta data associated with a bit torrent. - Tracker Tokens
- As previously indicated, tracker tokens are used to control access to and use of the
tracker 525 and reduce the number of accesses to the database(s) 635 for authentication purposes. The tracker tracks all peers who are participating in a torrent and help these peers to discover each other. Peers announce their presence to thetracker 525 on regular (announce) intervals, as discussed above, and are responded to with a listing of the addresses of other peers. - When peers upload or download content (package containing one or more files), as discussed above in conjunction with
FIGS. 6 and 9 , respectively, the package has an associated atracker 525. When thesender 510 orreceiver 520 send astart message - In one exemplary implementation, the assigned tokens are valid for a limited time period. Thus, an announce response message may include a “token-expired” error. To obtain a new token, a peer may issue a request for a token from the
tracker 525. - In one preferred embodiment, the token is an encrypted binary data structure. The
tracker -
FIG. 11 is a sample table identifying an exemplarytoken format 1100. - System and Article of Manufacture Details
- As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
- The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
- It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.
Claims (49)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/519,990 US20080066182A1 (en) | 2006-09-12 | 2006-09-12 | Security techniques for cooperative file distribution |
US12/789,837 US9900155B2 (en) | 2006-09-12 | 2010-05-28 | Security techniques for cooperative file distribution |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/519,990 US20080066182A1 (en) | 2006-09-12 | 2006-09-12 | Security techniques for cooperative file distribution |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,837 Continuation US9900155B2 (en) | 2006-09-12 | 2010-05-28 | Security techniques for cooperative file distribution |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080066182A1 true US20080066182A1 (en) | 2008-03-13 |
Family
ID=39171325
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/519,990 Abandoned US20080066182A1 (en) | 2006-09-12 | 2006-09-12 | Security techniques for cooperative file distribution |
US12/789,837 Active 2029-03-06 US9900155B2 (en) | 2006-09-12 | 2010-05-28 | Security techniques for cooperative file distribution |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,837 Active 2029-03-06 US9900155B2 (en) | 2006-09-12 | 2010-05-28 | Security techniques for cooperative file distribution |
Country Status (1)
Country | Link |
---|---|
US (2) | US20080066182A1 (en) |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080091763A1 (en) * | 2006-10-13 | 2008-04-17 | Quipa Holdings Limited | method for sharing functionality and/or data between two or more linked entities |
US20090210697A1 (en) * | 2008-01-17 | 2009-08-20 | Songqing Chen | Digital Rights Protection in BitTorrent-like P2P Systems |
WO2010033732A1 (en) * | 2008-09-17 | 2010-03-25 | Vuze, Inc. | Associative construction of multimedia subscriptions |
US20100179984A1 (en) * | 2009-01-13 | 2010-07-15 | Viasat, Inc. | Return-link optimization for file-sharing traffic |
US20100250709A1 (en) * | 2009-03-30 | 2010-09-30 | Sony Corporation | Distribution system and method of distributing content files |
US20100250917A1 (en) * | 2009-03-30 | 2010-09-30 | Sony Corporation | Distribution system and method of distributing content files |
US20110161313A1 (en) * | 2009-12-24 | 2011-06-30 | Alexandre Gerber | Method and apparatus for automated end to end content tracking in peer to peer environments |
US20120124178A1 (en) * | 2010-11-15 | 2012-05-17 | Google Inc. | Media file access |
US20130121487A1 (en) * | 2010-05-28 | 2013-05-16 | Noam Lorberbaum | System And Method For Deterministic Generation Of A Common Content Encryption Key On Distinct Encryption Units |
US8483217B2 (en) | 2009-03-10 | 2013-07-09 | Viasat, Inc. | Internet protocol broadcasting |
US8516253B1 (en) | 2010-01-18 | 2013-08-20 | Viasat, Inc. | Self-keyed protection of anticipatory content |
US8897302B2 (en) | 2011-06-14 | 2014-11-25 | Viasat, Inc. | Transport protocol for anticipatory content |
US20150006885A1 (en) * | 2013-06-28 | 2015-01-01 | Cellco Partnership D/B/A Verizon Wireless | Protecting subscriber information from third parties |
US8984048B1 (en) | 2010-04-18 | 2015-03-17 | Viasat, Inc. | Selective prefetch scanning |
US9037638B1 (en) | 2011-04-11 | 2015-05-19 | Viasat, Inc. | Assisted browsing using hinting functionality |
US9106607B1 (en) | 2011-04-11 | 2015-08-11 | Viasat, Inc. | Browser based feedback for optimized web browsing |
US20150249647A1 (en) * | 2014-02-28 | 2015-09-03 | Dropbox, Inc. | Advanced security protocol for broadcasting and synchronizing shared folders over local area network |
US9154552B2 (en) | 2007-09-06 | 2015-10-06 | Microsoft Technology Licensing, Llc | Method and apparatus for cooperative file distribution with receiver determined quality of services |
US9407355B1 (en) | 2011-10-25 | 2016-08-02 | Viasat Inc. | Opportunistic content delivery using delta coding |
US9456050B1 (en) | 2011-04-11 | 2016-09-27 | Viasat, Inc. | Browser optimization through user history analysis |
US9485615B2 (en) | 2014-09-26 | 2016-11-01 | At&T Intellectual Property I, L.P. | Local peer-to-peer network for providing recommendations and enforcing security policies |
US9912718B1 (en) | 2011-04-11 | 2018-03-06 | Viasat, Inc. | Progressive prefetching |
US10044637B2 (en) | 2012-06-15 | 2018-08-07 | Viasat, Inc. | Opportunistic delivery of cacheable content in a communications network |
GB2570214A (en) * | 2017-12-11 | 2019-07-17 | Boeing Co | Content encryption and decryption using a custom key |
US10855797B2 (en) | 2014-06-03 | 2020-12-01 | Viasat, Inc. | Server-machine-driven hint generation for improved web page loading using client-machine-driven feedback |
US11200292B2 (en) | 2015-10-20 | 2021-12-14 | Viasat, Inc. | Hint model updating using automated browsing clusters |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080066182A1 (en) * | 2006-09-12 | 2008-03-13 | Andrew Hickmott | Security techniques for cooperative file distribution |
US20090187978A1 (en) * | 2008-01-18 | 2009-07-23 | Yahoo! Inc. | Security and authentications in peer-to-peer networks |
US8533151B2 (en) | 2009-05-26 | 2013-09-10 | Microsoft Corporation | Generating a local copy of a virtualized application package from a local installation |
EP2973406B1 (en) | 2013-03-14 | 2019-11-27 | NIKE Innovate C.V. | Athletic attribute determinations from image data |
CN105850093B (en) * | 2013-09-05 | 2020-02-07 | 耐克创新有限合伙公司 | Event taking captured sports moving image data and uploading by verifiable token agent uploader |
EP3208222B1 (en) * | 2016-02-18 | 2020-06-17 | Otis Elevator Company | Anonymous and ephemeral tokens to authenticate elevator calls |
US9961139B2 (en) | 2016-05-24 | 2018-05-01 | International Business Machines Corporation | Cooperative download among low-end devices under resource constrained environment |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5548648A (en) * | 1994-04-05 | 1996-08-20 | International Business Machines Corporation | Encryption method and system |
US5963646A (en) * | 1997-03-10 | 1999-10-05 | The Pacid Group | Secure deterministic encryption key generator system and method |
US6104810A (en) * | 1997-05-15 | 2000-08-15 | International Business Machines Corporation | Pseudorandom number generator with backup and restoration capability |
US6343738B1 (en) * | 1999-05-15 | 2002-02-05 | John W. L. Ogilvie | Automatic broker tools and techniques |
US20050203851A1 (en) * | 2003-10-25 | 2005-09-15 | Macrovision Corporation | Corruption and its deterrence in swarm downloads of protected files in a file sharing network |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6412070B1 (en) * | 1998-09-21 | 2002-06-25 | Microsoft Corporation | Extensible security system and method for controlling access to objects in a computing environment |
ATE552562T1 (en) * | 2000-11-10 | 2012-04-15 | Aol Musicnow Llc | DIGITAL CONTENT DISTRIBUTION AND SUBSCRIPTION SYSTEM |
US6990656B2 (en) * | 2002-06-27 | 2006-01-24 | Microsoft Corporation | Dynamic metabase store |
US7577743B2 (en) * | 2003-08-01 | 2009-08-18 | Sentillion, Inc. | Methods and apparatus for performing context management in a networked environment |
US20060224687A1 (en) | 2005-03-31 | 2006-10-05 | Popkin Laird A | Method and apparatus for offline cooperative file distribution using cache nodes |
US7809943B2 (en) * | 2005-09-27 | 2010-10-05 | Rovi Solutions Corporation | Method and system for establishing trust in a peer-to-peer network |
US20070201502A1 (en) * | 2006-02-28 | 2007-08-30 | Maven Networks, Inc. | Systems and methods for controlling the delivery behavior of downloaded content |
US7992171B2 (en) * | 2006-09-06 | 2011-08-02 | Qurio Holdings, Inc. | System and method for controlled viral distribution of digital content in a social network |
US20080066182A1 (en) * | 2006-09-12 | 2008-03-13 | Andrew Hickmott | Security techniques for cooperative file distribution |
US20100011103A1 (en) * | 2006-09-28 | 2010-01-14 | Rayv Inc. | System and methods for peer-to-peer media streaming |
-
2006
- 2006-09-12 US US11/519,990 patent/US20080066182A1/en not_active Abandoned
-
2010
- 2010-05-28 US US12/789,837 patent/US9900155B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5548648A (en) * | 1994-04-05 | 1996-08-20 | International Business Machines Corporation | Encryption method and system |
US5963646A (en) * | 1997-03-10 | 1999-10-05 | The Pacid Group | Secure deterministic encryption key generator system and method |
US6104810A (en) * | 1997-05-15 | 2000-08-15 | International Business Machines Corporation | Pseudorandom number generator with backup and restoration capability |
US6343738B1 (en) * | 1999-05-15 | 2002-02-05 | John W. L. Ogilvie | Automatic broker tools and techniques |
US20050203851A1 (en) * | 2003-10-25 | 2005-09-15 | Macrovision Corporation | Corruption and its deterrence in swarm downloads of protected files in a file sharing network |
Cited By (84)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8196181B2 (en) * | 2006-10-13 | 2012-06-05 | Quipa Holdings Limited | Private network system and method |
US20080134316A1 (en) * | 2006-10-13 | 2008-06-05 | Quipa Holdings Limited | private network system and method |
US20080091763A1 (en) * | 2006-10-13 | 2008-04-17 | Quipa Holdings Limited | method for sharing functionality and/or data between two or more linked entities |
US9154552B2 (en) | 2007-09-06 | 2015-10-06 | Microsoft Technology Licensing, Llc | Method and apparatus for cooperative file distribution with receiver determined quality of services |
US20090210697A1 (en) * | 2008-01-17 | 2009-08-20 | Songqing Chen | Digital Rights Protection in BitTorrent-like P2P Systems |
WO2010033732A1 (en) * | 2008-09-17 | 2010-03-25 | Vuze, Inc. | Associative construction of multimedia subscriptions |
US20100094937A1 (en) * | 2008-09-17 | 2010-04-15 | Vuze, Inc. | Reverse subscriptions |
US9253143B2 (en) | 2008-09-17 | 2016-02-02 | Azureus Software, Inc. | Reverse subscriptions |
US11252210B2 (en) | 2009-01-13 | 2022-02-15 | Viasat, Inc. | Content set based deltacasting |
US8477635B2 (en) | 2009-01-13 | 2013-07-02 | Viasat, Inc. | Correlative anticipatory deltacasting |
US10187436B2 (en) | 2009-01-13 | 2019-01-22 | Viasat, Inc. | Content set based deltacasting |
US9172748B2 (en) | 2009-01-13 | 2015-10-27 | Viasat, Inc. | Deltacasting for overlapping requests |
US20100179984A1 (en) * | 2009-01-13 | 2010-07-15 | Viasat, Inc. | Return-link optimization for file-sharing traffic |
US10536495B2 (en) | 2009-01-13 | 2020-01-14 | Viasat, Inc. | Content set based deltacasting |
US10951671B2 (en) | 2009-01-13 | 2021-03-16 | Viasat, Inc. | Content set based deltacasting |
US9363308B2 (en) | 2009-01-13 | 2016-06-07 | Viasat, Inc. | Correlative anticipatory deltacasting |
US20100185730A1 (en) * | 2009-01-13 | 2010-07-22 | Viasat, Inc. | Deltacasting for overlapping requests |
US10547655B2 (en) | 2009-01-13 | 2020-01-28 | Viasat, Inc. | Deltacasting |
US8775503B2 (en) | 2009-01-13 | 2014-07-08 | Viasat, Inc. | Deltacasting for overlapping requests |
US8842553B2 (en) | 2009-01-13 | 2014-09-23 | Viasat, Inc. | Correlative anticipatory deltacasting |
US11916990B2 (en) | 2009-01-13 | 2024-02-27 | Viasat, Inc. | Content set based deltacasting |
US9762635B2 (en) | 2009-01-13 | 2017-09-12 | Viasat, Inc. | Content set based pre-positioning |
US9369516B2 (en) | 2009-01-13 | 2016-06-14 | Viasat, Inc. | Deltacasting |
US11212328B2 (en) | 2009-03-10 | 2021-12-28 | Viasat, Inc. | Internet protocol broadcasting |
US8483217B2 (en) | 2009-03-10 | 2013-07-09 | Viasat, Inc. | Internet protocol broadcasting |
US9094220B2 (en) | 2009-03-10 | 2015-07-28 | Viasat, Inc. | Internet protocol broadcasting |
US10637901B2 (en) | 2009-03-10 | 2020-04-28 | Viasat, Inc. | Internet protocol broadcasting |
US9210215B2 (en) * | 2009-03-30 | 2015-12-08 | Sony Corporation | Distribution system and method of distributing content files |
US20100250709A1 (en) * | 2009-03-30 | 2010-09-30 | Sony Corporation | Distribution system and method of distributing content files |
US8370620B2 (en) * | 2009-03-30 | 2013-02-05 | Sony Corporation | Distribution system and method of distributing content files |
US20100250917A1 (en) * | 2009-03-30 | 2010-09-30 | Sony Corporation | Distribution system and method of distributing content files |
US8935240B2 (en) | 2009-12-24 | 2015-01-13 | At&T Intellectual Property I, L.P. | Method and apparatus for automated end to end content tracking in peer to peer environments |
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 |
US20110161313A1 (en) * | 2009-12-24 | 2011-06-30 | Alexandre Gerber | Method and apparatus for automated end to end content tracking in peer to peer environments |
US8516253B1 (en) | 2010-01-18 | 2013-08-20 | Viasat, Inc. | Self-keyed protection of anticipatory content |
US9405924B2 (en) | 2010-01-18 | 2016-08-02 | Viasat, Inc. | Self-keyed protection of anticipatory content |
US9307003B1 (en) | 2010-04-18 | 2016-04-05 | Viasat, Inc. | Web hierarchy modeling |
US8984048B1 (en) | 2010-04-18 | 2015-03-17 | Viasat, Inc. | Selective prefetch scanning |
US10171550B1 (en) | 2010-04-18 | 2019-01-01 | Viasat, Inc. | Static tracker |
US10645143B1 (en) | 2010-04-18 | 2020-05-05 | Viasat, Inc. | Static tracker |
US9407717B1 (en) | 2010-04-18 | 2016-08-02 | Viasat, Inc. | Selective prefetch scanning |
US9043385B1 (en) | 2010-04-18 | 2015-05-26 | Viasat, Inc. | Static tracker |
US9497256B1 (en) | 2010-04-18 | 2016-11-15 | Viasat, Inc. | Static tracker |
US20130121487A1 (en) * | 2010-05-28 | 2013-05-16 | Noam Lorberbaum | System And Method For Deterministic Generation Of A Common Content Encryption Key On Distinct Encryption Units |
US9225520B2 (en) * | 2010-05-28 | 2015-12-29 | Adobe Systems Incorporated | System and method for deterministic generation of a common content encryption key on distinct encryption units |
US9565240B2 (en) * | 2010-11-15 | 2017-02-07 | Google Inc. | Media file access |
US20120124178A1 (en) * | 2010-11-15 | 2012-05-17 | Google Inc. | Media file access |
US9456050B1 (en) | 2011-04-11 | 2016-09-27 | Viasat, Inc. | Browser optimization through user history analysis |
US9037638B1 (en) | 2011-04-11 | 2015-05-19 | Viasat, Inc. | Assisted browsing using hinting functionality |
US11256775B1 (en) | 2011-04-11 | 2022-02-22 | Viasat, Inc. | Progressive prefetching |
US11176219B1 (en) | 2011-04-11 | 2021-11-16 | Viasat, Inc. | Browser based feedback for optimized web browsing |
US9912718B1 (en) | 2011-04-11 | 2018-03-06 | Viasat, Inc. | Progressive prefetching |
US10972573B1 (en) | 2011-04-11 | 2021-04-06 | Viasat, Inc. | Browser optimization through user history analysis |
US9106607B1 (en) | 2011-04-11 | 2015-08-11 | Viasat, Inc. | Browser based feedback for optimized web browsing |
US10789326B2 (en) | 2011-04-11 | 2020-09-29 | Viasat, Inc. | Progressive prefetching |
US10372780B1 (en) | 2011-04-11 | 2019-08-06 | Viasat, Inc. | Browser based feedback for optimized web browsing |
US10735548B1 (en) | 2011-04-11 | 2020-08-04 | Viasat, Inc. | Utilizing page information regarding a prior loading of a web page to generate hinting information for improving load time of a future loading of the web page |
US10491703B1 (en) | 2011-04-11 | 2019-11-26 | Viasat, Inc. | Assisted browsing using page load feedback information and hinting functionality |
US8897302B2 (en) | 2011-06-14 | 2014-11-25 | Viasat, Inc. | Transport protocol for anticipatory content |
US11777654B2 (en) | 2011-06-14 | 2023-10-03 | Viasat, Inc. | Transport protocol for anticipatory content |
US9935740B2 (en) | 2011-06-14 | 2018-04-03 | Viasat, Inc. | Transport protocol for anticipatory content |
US11139919B2 (en) | 2011-06-14 | 2021-10-05 | Viasat, Inc. | Transport protocol for anticipatory content |
US9407355B1 (en) | 2011-10-25 | 2016-08-02 | Viasat Inc. | Opportunistic content delivery using delta coding |
US11575738B2 (en) | 2011-10-25 | 2023-02-07 | Viasat, Inc. | Opportunistic content delivery using delta coding |
US11290525B2 (en) | 2011-10-25 | 2022-03-29 | Viasat, Inc. | Opportunistic content delivery using delta coding |
US10270842B2 (en) | 2011-10-25 | 2019-04-23 | Viasat, Inc. | Opportunistic content delivery using delta coding |
US11070490B2 (en) | 2012-06-15 | 2021-07-20 | Viasat, Inc. | Opportunistic delivery of cacheable content in a communications network |
US10594624B2 (en) | 2012-06-15 | 2020-03-17 | Viasat, Inc. | Opportunistic delivery of cacheable content in a communications network |
US11743207B2 (en) | 2012-06-15 | 2023-08-29 | Viasat, Inc. | Opportunistic delivery of cacheable content in a communications network |
US10044637B2 (en) | 2012-06-15 | 2018-08-07 | Viasat, Inc. | Opportunistic delivery of cacheable content in a communications network |
US20150006885A1 (en) * | 2013-06-28 | 2015-01-01 | Cellco Partnership D/B/A Verizon Wireless | Protecting subscriber information from third parties |
US9210132B2 (en) * | 2013-06-28 | 2015-12-08 | Cellco Partnership | Protecting subscriber information from third parties |
US20150249647A1 (en) * | 2014-02-28 | 2015-09-03 | Dropbox, Inc. | Advanced security protocol for broadcasting and synchronizing shared folders over local area network |
US11153290B2 (en) | 2014-02-28 | 2021-10-19 | Dropbox, Inc. | Advanced security protocol for broadcasting and synchronizing shared folders over local area network |
US9641488B2 (en) * | 2014-02-28 | 2017-05-02 | Dropbox, Inc. | Advanced security protocol for broadcasting and synchronizing shared folders over local area network |
US10425391B2 (en) | 2014-02-28 | 2019-09-24 | Dropbox, Inc. | Advanced security protocol for broadcasting and synchronizing shared folders over local area network |
US10855797B2 (en) | 2014-06-03 | 2020-12-01 | Viasat, Inc. | Server-machine-driven hint generation for improved web page loading using client-machine-driven feedback |
US11310333B2 (en) | 2014-06-03 | 2022-04-19 | Viasat, Inc. | Server-machine-driven hint generation for improved web page loading using client-machine-driven feedback |
US10608815B2 (en) | 2014-07-28 | 2020-03-31 | The Boeing Company | Content encryption and decryption using a custom key |
US10097629B2 (en) | 2014-09-26 | 2018-10-09 | At&T Intellectual Property I, L.P. | Methods, systems, devices, and products for peer recommendations |
US9485615B2 (en) | 2014-09-26 | 2016-11-01 | At&T Intellectual Property I, L.P. | Local peer-to-peer network for providing recommendations and enforcing security policies |
US11200292B2 (en) | 2015-10-20 | 2021-12-14 | Viasat, Inc. | Hint model updating using automated browsing clusters |
GB2570214A (en) * | 2017-12-11 | 2019-07-17 | Boeing Co | Content encryption and decryption using a custom key |
GB2570214B (en) * | 2017-12-11 | 2020-09-30 | Boeing Co | Content encryption and decryption using a custom key |
Also Published As
Publication number | Publication date |
---|---|
US9900155B2 (en) | 2018-02-20 |
US20100235641A1 (en) | 2010-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9900155B2 (en) | Security techniques for cooperative file distribution | |
Isdal et al. | Privacy-preserving p2p data sharing with oneswarm | |
Nilizadeh et al. | Cachet: a decentralized architecture for privacy preserving social networking with caching | |
US7783767B2 (en) | System and method for distributed media streaming and sharing | |
Koponen et al. | A data-oriented (and beyond) network architecture | |
CN101904136B (en) | Security modes for a distributed routing table | |
US20060236386A1 (en) | Method and apparatus for cooperative file distribution in the presence of firewalls | |
KR20080085846A (en) | Authorisation and authentication | |
US20080077938A1 (en) | Method of implementing a state tracking mechanism in a communications session between a server and a client system | |
Gawande et al. | Decentralized and secure multimedia sharing application over named data networking | |
Kamel et al. | Distributed Address Table (DAT): A decentralized model for end-to-end communication in IoT | |
Matzutt et al. | Utilizing public blockchains for the sybil-resistant bootstrapping of distributed anonymity services | |
Yang et al. | Protecting personal sensitive data security in the cloud with blockchain | |
Zali et al. | Peer-Assisted Information-Centric Network (PICN): A Backward Compatible Solution | |
Schulzrinne et al. | Security issues and solutions in peer-to-peer systems for realtime communications | |
Zheng et al. | A survey on peer-to-peer SIP based communication systems | |
Han et al. | Using blockchains for censorship-resistant bootstrapping in anonymity networks | |
Petrocco et al. | Hiding user content interest while preserving P2P performance | |
Nandini | Efficient-way of Data Storage on Decentralized Cloud using Blockchain Technology | |
Ma et al. | A Scalable Covert Communication Service For Coworkers | |
Zheng et al. | A secure architecture for P2PSIP-based communication systems | |
da Silva et al. | Mistrustful P2P: Privacy-preserving file sharing over untrustworthy Peer-to-Peer networks | |
YAOQI | TOWARDS PRIVACY-PRESERVING AND ROBUST WEB OVERLAYS | |
Ramalho et al. | Decentralized CDN for Video Streaming | |
Wood | Security and Privacy Challenges in Content-Centric Networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: PANDO NETWORKS, INC., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HICKMOTT, ANDREW;POPKIN, LAIRD A.;SCHNITMAN, YAAR;REEL/FRAME:018705/0173;SIGNING DATES FROM 20061222 TO 20061228 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PANDO NETWORKS, INC.;REEL/FRAME:031128/0871 Effective date: 20130204 |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0509 Effective date: 20141014 |