Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
BitTorrent
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Design == [[File:Torrentcomp small.gif|thumb|Animation of [[Communications protocol|protocol]] use: The colored dots beneath each computer in the animation represent different parts of the [[file sharing|file being shared]]. By the time a copy to a destination computer of each of those parts completes, a copy to another destination computer of that part (or other parts) is already taking place between users.]] The BitTorrent protocol can be used to reduce the server and network impact of distributing large files. Rather than downloading a file from a single source server, the BitTorrent protocol allows users to join a "swarm" of hosts to upload and download from each other simultaneously. The protocol is an alternative to the older single source, multiple mirror sources technique for distributing data, and can work effectively over networks with lower [[bandwidth (computing)|bandwidth]]. Using the BitTorrent protocol, several basic computers, such as home computers, can replace large servers while efficiently distributing files to many recipients. This lower bandwidth usage also helps prevent large spikes in [[internet traffic]] in a given area, keeping internet speeds higher for all users in general, regardless of whether or not they use the BitTorrent protocol. The file being distributed is divided into segments called ''pieces''. As each peer receives a new piece of the file, it becomes a source (of that piece) for other peers, relieving the original seed from having to send that piece to every computer or user wishing a copy. With BitTorrent, the task of distributing the file is shared by those who want it; it is entirely possible for the seed to send only a single copy of the file itself and eventually distribute to an unlimited number of peers. Each piece is protected by a [[cryptographic hash]] contained in the torrent descriptor.<ref name="Protocol1.0"/> This ensures that any modification of the piece can be reliably detected, and thus prevents both accidental and malicious modifications of any of the pieces received at other nodes. If a node starts with an authentic copy of the torrent descriptor, it can verify the authenticity of the entire file it receives. Pieces are typically downloaded non-sequentially, and are rearranged into the correct order by the BitTorrent client, which monitors which pieces it needs, and which pieces it has and can upload to other peers. Pieces are of the same size throughout a single download (for example, a 10 MB file may be transmitted as ten 1 MB pieces or as forty 256 KB pieces). Due to the nature of this approach, the download of any file can be halted at any time and be resumed at a later date, without the loss of previously downloaded information, which in turn makes BitTorrent particularly useful in the transfer of larger files. This also enables the client to seek out readily available pieces and download them immediately, rather than halting the download and waiting for the next (and possibly unavailable) piece in line, which typically reduces the overall time of the download. This eventual transition from peers to seeders determines the overall "health" of the file (as determined by the number of times a file is available in its complete form). The distributed nature of BitTorrent can lead to a [[Flooding algorithm|flood-like]] spreading of a file throughout many peer computer nodes. As more peers join the swarm, the likelihood of a successful download by any particular node increases. Relative to traditional Internet distribution schemes, this permits a significant reduction in the original distributor's hardware and bandwidth resource costs. Distributed downloading protocols in general provide [[wikt:redundancy|redundancy]] against system problems, reduce dependence on the original distributor,<ref>{{cite journal |arxiv=1004.0395|title=Estimating Self-Sustainability in Peer-to-Peer Swarming Systems |journal=Performance Evaluation |volume=67 |issue=11 |pages=1243–1258 |last1= Menasche |first1=Daniel S. |last2= Rocha |first2=Antonio A. A. |last3= de Souza e Silva |first3=Edmundo A. |last4= Leao |first4=Rosa M. |last5=Towsley |first5=Don |last6=Venkataramani |first6=Arun |year=2010 |doi=10.1016/j.peva.2010.08.013 |s2cid=9361889 |issn = 0166-5316 }} by D. Menasche, A. Rocha, E. de Souza e Silva, R. M. Leao, D. Towsley, A. Venkataramani.</ref> and provide sources for the file which are generally [[Transient (computer programming)|transient]] and therefore there is no single point of failure as in one way server-client transfers. Though both ultimately transfer files over a network, a BitTorrent download differs from a one way server-client download (as is typical with an [[Hypertext Transfer Protocol|HTTP]] or [[File Transfer Protocol|FTP]] request, for example) in several fundamental ways: * BitTorrent makes many small data requests over different [[Internet Protocol|IP]] connections to different machines, while server-client downloading is typically made via a single [[Transmission Control Protocol|TCP]] connection to a single machine. * BitTorrent downloads in a random or in a "rarest-first"<ref name="Rarest First and Choke Algorithms Are Enough">{{cite web | url=http://conferences.sigcomm.org/imc/2006/papers/p20-legout.pdf | title=Rarest First and Choke Algorithms Are Enough | date=December 2006 | last=Urvoy-Keller | publisher=Sigcomm | access-date=9 March 2012 | archive-url=https://web.archive.org/web/20120523055500/http://conferences.sigcomm.org/imc/2006/papers/p20-legout.pdf | archive-date=23 May 2012 | url-status=live | df=dmy-all }}</ref> approach that ensures high availability, while classic downloads are sequential. Taken together, these differences allow BitTorrent to achieve much lower cost to the content provider, much higher redundancy, and much greater resistance to abuse or to "[[Slashdot effect|flash crowds]]" than regular [[Server (computing)|server software]]. However, this protection, theoretically, comes at a cost: downloads can take time to rise to full speed because it may take time for enough peer connections to be established, and it may take time for a node to receive sufficient data to become an effective uploader. This contrasts with regular downloads (such as from an HTTP server, for example) that, while more vulnerable to overload and abuse, rise to full speed very quickly, and maintain this speed throughout. In the beginning, BitTorrent's non-contiguous download methods made it harder to support "streaming playback". In 2014, the client [[Popcorn Time]] allowed for streaming of BitTorrent video files. Since then, more and more clients are offering streaming options. === Searching === The BitTorrent protocol provides no way to index torrent files. As a result, a comparatively small number of websites have hosted a large majority of torrents, many linking to copyrighted works without the authorization of copyright holders, rendering those sites especially vulnerable to lawsuits.<ref>{{cite web| url=http://torrentfreak.com/publicbt-tracker-set-to-patch-bittorrents-achilles-heel-090712/| title=PublicBT Tracker Set To Patch BitTorrent' Achilles' Heel| date=12 July 2009| publisher=Torrentfreak |author=Ernesto |access-date=14 July 2009 | archive-url = https://web.archive.org/web/20140326093356/http://torrentfreak.com/publicbt-tracker-set-to-patch-bittorrents-achilles-heel-090712/ | archive-date = 26 March 2014| url-status=live}}</ref> A BitTorrent index is a "list of [[Torrent file|.torrent files]], which typically includes descriptions" and information about the torrent's content.<ref>Chwan-Hwa (John) Wu, J. David Irwin. ''Introduction to Computer Networks and Cybersecurity''. Chapter 5.4.: Partially Centralized Architectures. [[CRC Press]]. 4 February 2013. {{ISBN|9781466572133}}</ref> Several types of websites support the discovery and distribution of data on the BitTorrent network. Public torrent-hosting sites such as [[The Pirate Bay]] allow users to search and download from their collection of torrent files. Users can typically also upload torrent files for content they wish to distribute. Often, these sites also run [[BitTorrent tracker]]s for their hosted torrent files, but these two functions are not mutually dependent: a torrent file could be hosted on one site and tracked by another unrelated site. Private host/tracker sites operate like public ones except that they may restrict access to registered users and may also keep track of the amount of data each user uploads and downloads, in an attempt to reduce "[[leech (computing)|leeching]]". [[Web search engine]]s allow the discovery of torrent files that are hosted and tracked on other sites; examples include The Pirate Bay and [[BTDigg]]. These sites allow the user to ask for content meeting specific criteria (such as containing a given word or phrase) and retrieve a list of links to torrent files matching those criteria. This list can often be sorted with respect to several criteria, relevance (seeders to leechers ratio) being one of the most popular and useful (due to the way the protocol behaves, the download bandwidth achievable is very sensitive to this value). [[Metasearch engine]]s allow one to search several BitTorrent indices and search engines at once. The [[Tribler]] BitTorrent client was among the first to incorporate built-in search capabilities. With Tribler, users can find .torrent files held by random peers and taste buddies.<ref>Zeilemaker, N., Capotă, M., Bakker, A., & Pouwelse, J. (2011). "Tribler P2P Media Search and Sharing." Proceedings of the 19th ACM International Conference on Multimedia - MM ’11.</ref> It adds such an ability to the BitTorrent protocol using a [[gossip protocol]], somewhat similar to the [[eXeem]] network which was shut down in 2005. The software includes the ability to recommend content as well. After a dozen downloads, the Tribler software can roughly estimate the download taste of the user, and recommend additional content.<ref>{{cite web|url=https://www.tribler.org/DecentralizedRecommendation |title=DecentralizedRecommendation – |publisher=Tribler.org |access-date=9 July 2012 | archive-url = https://web.archive.org/web/20081202143338/http://www.tribler.org/DecentralizedRecommendation | archive-date = 2 December 2008| url-status=live}}</ref> In May 2007, researchers at [[Cornell University]] published a paper proposing a new approach to searching a peer-to-peer network for inexact strings,<ref> {{cite web|url=https://www.cs.cornell.edu/people/egs/papers/hyperspaces.pdf|title=Hyperspaces for Object Clustering and Approximate Matching in Peer-to-Peer Overlays|author=Wong, Bernard|author2=Vigfusson, Ymir|date=2 May 2007<!-- from PDF-->|publisher=Cornell University|url-status=live|archive-url=https://web.archive.org/web/20120617065142/http://www.cs.cornell.edu/People/egs/papers/hyperspaces.pdf|archive-date=17 June 2012|access-date=7 April 2013|author3=Gun Sirer, Emin|df=dmy-all}} </ref> which could replace the functionality of a central indexing site. A year later, the same team implemented the system as a plugin for [[Vuze]] called Cubit<ref>{{cite web |url=http://www.cs.cornell.edu/~bwong/cubit/index.html |author=Wong, Bernard |title=Cubit: Approximate Matching for Peer-to-Peer Overlays |year=2008 |access-date=26 May 2008 |publisher=Cornell University | archive-url = https://web.archive.org/web/20121231060445/http://www.cs.cornell.edu/~bwong/cubit/index.html |archive-date = 31 December 2012| url-status=live}}</ref> and published a follow-up paper reporting its success.<ref> {{cite web |url=http://www.cs.cornell.edu/~bwong/cubit/tr-cubit.pdf |title=Approximate Matching for Peer-to-Peer Overlays with Cubit |author=Wong, Bernard |access-date=26 May 2008 |publisher=Cornell University |archive-url=https://web.archive.org/web/20081029084030/http://www.cs.cornell.edu/~bwong/cubit/tr-cubit.pdf |archive-date=29 October 2008 |url-status=live |df=dmy-all }}</ref> A somewhat similar facility but with a slightly different approach is provided by the [[BitComet]] client through its "Torrent Exchange"<ref>{{cite web |url=http://wiki.bitcomet.com/Torrent_Exchange |title=Torrent Exchange | archive-url = https://web.archive.org/web/20131005065144/http://wiki.bitcomet.com/Torrent_Exchange | archive-date = 5 October 2013| url-status=live |quote=The torrent sharing feature of BitComet. Bitcomet.com. |access-date=31 January 2010}}</ref> feature. Whenever two peers using BitComet (with Torrent Exchange enabled) connect to each other they exchange lists of all the torrents (name and info-hash) they have in the Torrent Share storage (torrent files which were previously downloaded and for which the user chose to enable sharing by Torrent Exchange). Thus each client builds up a list of all the torrents shared by the peers it connected to in the current session (or it can even maintain the list between sessions if instructed). At any time the user can search into that Torrent Collection list for a certain torrent and sort the list by categories. When the user chooses to download a torrent from that list, the .torrent file is automatically searched for (by info-hash value) in the [[Distributed hash table|DHT Network]] and when found it is downloaded by the querying client which can subsequently create and initiate a downloading task. === Downloading and sharing === Users find a torrent of interest on a torrent index site or by using a search engine built into the client, download it, and open it with a BitTorrent client. The client connects to the tracker(s) or seeds specified in the torrent file, from which it receives a list of seeds and peers currently transferring pieces of the file(s). The client connects to those peers to obtain the various pieces. If the swarm contains only the initial seeder, the client connects directly to it, and begins to request pieces. Clients incorporate mechanisms to optimize their download and upload rates. The effectiveness of this data exchange depends largely on the policies that clients use to determine to whom to send data. Clients may prefer to send data to peers that send data back to them (a "[[tit for tat]]" exchange scheme), which encourages fair trading. But strict policies often result in suboptimal situations, such as when newly joined peers are unable to receive any data because they do not have any pieces yet to trade themselves or when two peers with a good connection between them do not exchange data simply because neither of them takes the initiative. To counter these effects, the official BitTorrent client program uses a mechanism called "optimistic unchoking", whereby the client reserves a portion of its available bandwidth for sending pieces to random peers (not necessarily known good partners, or "preferred peers") in hopes of discovering even better partners and to ensure that newcomers get a chance to join the swarm.<ref name = "Tamilmanistudy" >{{cite web| url=http://mnl.cs.stonybrook.edu/home/karthik/BitTorrent/Robustness_of_BT.doc |title=Studying and enhancing the BitTorrent protocol |first=Karthik |last=Tamilmani |publisher=Stony Brook University |date=25 October 2003 |access-date=6 May 2006 |format=DOC |archive-url=https://web.archive.org/web/20041119150847/http://mnl.cs.stonybrook.edu/home/karthik/BitTorrent/Robustness_of_BT.doc |archive-date=19 November 2004}}</ref><!-- mnl.cs.stonybrook.edu down, subst archive.org link --> Although "swarming" scales well to tolerate "flash crowds" for popular content, it is less useful for unpopular or [[niche market]] content. Peers arriving after the initial rush might find the content unavailable and need to wait for the arrival of a "seed" in order to complete their downloads. The seed arrival, in turn, may take long to happen (this is termed the "seeder promotion problem"). Since maintaining seeds for unpopular content entails high bandwidth and administrative costs, this runs counter to the goals of publishers that value BitTorrent as a cheap alternative to a client-server approach. This occurs on a huge scale; measurements have shown that 38% of all new torrents become unavailable within the first month.<ref>{{cite arXiv |eprint=0912.0625 |title=Unraveling BitTorrent's File Unavailability: Measurements and Analysis |last=Kaune |first=Sebastian |display-authors=etal |class=cs.NI |year=2009 }}</ref> A strategy adopted by many publishers which significantly increases availability of unpopular content consists of bundling multiple files in a single swarm.<ref>{{cite conference |url=http://conferences.sigcomm.org/co-next/2009/papers/Menasche.pdf |title=Content Availability and Bundling in Swarming Systems |author=D. Menasche |display-authors=etal |publisher=ACM via sigcomm.org |work=CoNEXT'09 |date=1–4 December 2009 |location=Rome, Italy |isbn=978-1-60558-636-6 |access-date=18 December 2009 |archive-url=https://web.archive.org/web/20110501082904/http://conferences.sigcomm.org/co-next/2009/papers/Menasche.pdf |archive-date=1 May 2011 |url-status=live |df=dmy-all }}</ref> More sophisticated solutions have also been proposed; generally, these use cross-torrent mechanisms through which multiple torrents can cooperate to better share content.<ref>{{cite web |url=http://www.eecs.qmul.ac.uk/~tysong/files/ICCCN09.pdf |title=The Seeder Promotion Problem: Measurements, Analysis and Solution Space |last=Kaune |first=Sebastian |display-authors=etal |publisher=Queen Mary's University London |access-date=20 July 2017 |archive-url=https://web.archive.org/web/20140809010501/http://www.eecs.qmul.ac.uk/~tysong/files/ICCCN09.pdf |archive-date=9 August 2014 |url-status=live |df=dmy-all }}</ref> === Creating and publishing === {{see also|Torrent file}} {{Update|date=January 2022|reason=Some extensions described in this section as experimental have been standardized. This section is factually incorrect about some aspects of v1 and v2}} The peer distributing a data file treats the file as a number of identically sized pieces, usually with byte sizes of a power of 2, and typically between 32 KB and 16 MB each. The peer creates a [[Hash function|hash]] for each piece, using the [[SHA-1]] hash function, and records it in the [[torrent file]]. Pieces with sizes greater than 512 KB will reduce the size of a torrent file for a very large payload, but is claimed to reduce the efficiency of the protocol.<ref>{{cite web |url=http://wiki.theory.org/index.php/BitTorrentSpecification |title=BitTorrent Specification |publisher=Wiki.theory.org |access-date=9 July 2012 | archive-url = https://web.archive.org/web/20130626195027/https://wiki.theory.org/index.php/BitTorrentSpecification | archive-date = 26 June 2013| url-status=live}}{{dubious|reason=Wikis are not citable sources – find a better source-Lexein|date=April 2013}}</ref> When another peer later receives a particular piece, the hash of the piece is compared to the recorded hash to test that the piece is error-free.<ref name = "Protocol1.0" /> Peers that provide a complete file are called seeders, and the peer providing the initial copy is called the initial seeder. The exact information contained in the torrent file depends on the version of the BitTorrent protocol. By convention, the name of a torrent file has the suffix <code>.torrent</code>. Torrent files use the [[Bencode]] file format, and contain an "announce" section, which specifies the [[Uniform Resource Locator|URL]] of the tracker, and an "info" section, containing (suggested) names for the files, their lengths, the piece length used, and a [[SHA-1]] [[hash code]] for each piece, all of which are used by clients to verify the integrity of the data they receive. Though SHA-1 has shown signs of cryptographic weakness, Bram Cohen did not initially consider the risk big enough for a backward incompatible change to, for example, [[SHA-3]]. As of BitTorrent v2 the hash function has been updated to SHA-256.<ref>{{cite web|title=» BitTorrent v2|url=https://blog.libtorrent.org/2020/09/bittorrent-v2/|access-date=2020-09-27|language=en-US|archive-date=27 September 2020|archive-url=https://web.archive.org/web/20200927063545/https://blog.libtorrent.org/2020/09/bittorrent-v2/|url-status=live}}</ref> In the early days, torrent files were typically published to torrent index websites, and registered with at least one tracker. The tracker maintained lists of the clients currently connected to the swarm.<ref name="Protocol1.0"/> Alternatively, in a ''trackerless system'' (decentralized tracking) every peer acts as a tracker. Azureus was the first<ref name="DHT-turns-10">{{cite web|title=BitTorrent's DHT Turns 10 Years Old|last=Jones|first=Ben|url=https://torrentfreak.com/bittorrents-dht-turns-10-years-old-150607/|date=7 June 2015|access-date=5 July 2015|website=[[TorrentFreak]]|archive-url=https://web.archive.org/web/20150611011335/http://torrentfreak.com/bittorrents-dht-turns-10-years-old-150607/|archive-date=11 June 2015|url-status=live|df=dmy-all}}</ref> BitTorrent client to implement such a system through the [[distributed hash table]] (DHT) method. An alternative and incompatible DHT system, known as [[Mainline DHT]], was released in the Mainline BitTorrent client three weeks later (though it had been in development since 2002)<ref name="DHT-turns-10"/> and subsequently adopted by the [[μTorrent]], [[Transmission (BitTorrent client)|Transmission]], [[rTorrent]], [[KTorrent]], [[BitComet]], and [[Deluge (BitTorrent client)|Deluge]] clients. After the DHT was adopted, a "private" flag – analogous to the [[broadcast flag]] – was unofficially introduced, telling clients to restrict the use of decentralized tracking regardless of the user's desires.<ref>{{cite web|url=https://wiki.theory.org/index.php/BitTorrentSpecification#Info_Dictionary|title=Unofficial BitTorrent Protocol Specification v1.0|url-status=live|archive-url=https://web.archive.org/web/20061214094732/http://wiki.theory.org/BitTorrentSpecification|archive-date=14 December 2006|access-date=4 October 2009}}{{dubious|reason=Wikis are not citable sources – find a better source-Lexein|date=April 2013}}</ref> The flag is intentionally placed in the info section of the torrent so that it cannot be disabled or removed without changing the identity of the torrent. The purpose of the flag is to prevent torrents from being shared with clients that do not have access to the tracker. The flag was requested for inclusion in the official specification in August 2008, but has not been accepted yet.<ref>{{cite web|url=https://www.bittorrent.org/beps/bep_0027.html|title=Private Torrents|author=Harrison, David|date=3 August 2008|publisher=Bittorrent.org|url-status=live|archive-url=https://web.archive.org/web/20130324181003/http://www.bittorrent.org/beps/bep_0027.html|archive-date=24 March 2013|access-date=4 October 2009}}</ref> Clients that have ignored the private flag were banned by many trackers, discouraging the practice.<ref>{{cite web| url=http://www.slyck.com/news.php?story=1021| title=BitComet Banned From Growing Number of Private Trackers| access-date=4 October 2009 | archive-url = https://web.archive.org/web/20140326093846/http://www.slyck.com/news.php?story=1021 | archive-date = 26 March 2014| url-status=live}}</ref> === Anonymity === BitTorrent does not, on its own, offer its users anonymity. One can usually see the [[IP address]]es of all peers in a swarm in one's own client or firewall program. This may expose users with insecure systems to attacks.<ref name="Tamilmanistudy" /> In some countries, copyright organizations scrape lists of peers, and send takedown notices to the [[internet service provider]] of users participating in the swarms of files that are under copyright. In some jurisdictions, copyright holders may launch lawsuits against uploaders or downloaders for infringement, and police may arrest suspects in such cases. Various means have been used to promote anonymity. For example, the BitTorrent client [[Tribler]] makes available a [[Tor (anonymity network)|Tor]]-like [[onion routing|onion network]], optionally routing transfers through other peers to obscure which client has requested the data. The exit node would be visible to peers in a swarm, but the Tribler organization provides exit nodes. One advantage of Tribler is that [[Clearnet (networking)|clearnet]] torrents can be downloaded with only a small decrease in download speed from one "hop" of routing. [[i2p]] provides a similar anonymity layer although in that case, one can only download torrents that have been uploaded to the i2p network.<ref>{{cite web|url=https://geti2p.net/en/comparison/tor|title=I2P Compared to Tor - I2P|access-date=16 December 2015|archive-url=https://web.archive.org/web/20151222000747/https://geti2p.net/en/comparison/tor|archive-date=22 December 2015|url-status=live|df=dmy-all}}</ref> The bittorrent client [[Vuze]] allows users who are not concerned about anonymity to take [[Clearnet (networking)|clearnet]] torrents, and make them available on the i2p network.<ref>{{cite web|url=https://wiki.vuze.com/w/I2PHelper_HowTo#Network_Mixing|title=I2PHelper HowTo - VuzeWiki|access-date=16 December 2015|archive-url=https://web.archive.org/web/20171020084042/https://wiki.vuze.com/w/I2PHelper_HowTo#Network_Mixing|archive-date=20 October 2017|url-status=live|df=dmy-all}}</ref> Most BitTorrent clients are not designed to provide anonymity when used over Tor,<ref>{{cite web|url=https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea|title=Bittorrent over Tor isn't a good idea - The Tor Blog|access-date=2 October 2016|archive-url=https://web.archive.org/web/20161013120154/https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea|archive-date=13 October 2016|url-status=live|df=dmy-all}}</ref> and there is some debate as to whether torrenting over Tor acts as a drag on the network.<ref>{{cite web|url=https://www.torproject.org/docs/faq.html.en#FileSharing|title=Tor Project: FAQ|publisher=[[The Tor Project]]|access-date=2 October 2016|archive-url=https://web.archive.org/web/20161022004822/https://www.torproject.org/docs/faq.html.en#FileSharing|archive-date=22 October 2016|url-status=live|df=dmy-all}}</ref> Private torrent trackers are usually invitation only, and require members to participate in uploading, but have the downside of a single centralized point of failure. [[Oink's Pink Palace]] and [[What.cd]] are examples of private trackers which have been shut down. [[Seedbox]] services download the torrent files first to the company's servers, allowing the user to direct download the file from there.<ref>{{cite web|url=https://gizmodo.com/this-website-could-be-the-ultimate-all-in-one-torrent-m-1677265492|archive-url=https://web.archive.org/web/20160408154942/http://gizmodo.com/this-website-could-be-the-ultimate-all-in-one-torrent-m-1677265492|url-status=dead|archive-date=8 April 2016|title=This Website Could Be The Ultimate All-In-One Torrent Machine|date=8 April 2016}}</ref><ref>{{cite web|url=https://torrentfreak.com/torrent-from-the-cloud-with-seedr-160117/|title=Torrent From the Cloud With Seedr - TorrentFreak|date=17 January 2016|access-date=8 April 2016|archive-url=https://web.archive.org/web/20160419231351/https://torrentfreak.com/torrent-from-the-cloud-with-seedr-160117/|archive-date=19 April 2016|url-status=live|df=dmy-all}}</ref> One's IP address would be visible to the Seedbox provider, but not to third parties. [[Virtual private network]]s encrypt transfers, and substitute a different IP address for the user's, so that anyone monitoring a torrent swarm will only see that address.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)