Talk:BitTorrent/Archive 3

From Wikipedia, the free encyclopedia

Contents 1 Protocol specification 2 Legality section 3 Reverting Talk Page 4 Hiding System Tray 5 Talk page archival 6 TCP/IP not mentioned anywhere 7 Inappropriate tone 8 Piracy is a mess 9 Too long? 10 Sources? 11 History? 12 Do not link to irrelevant information 13 Acronym not linked 14 TorrentBytes 15 Encouraging illegal download 16 DHT type is based on Kad 17 Speed of Bittorrent 18 Time for a split? 19 Can someone clarify why down is way faster than up 20 Various 21 Torrent filenames 22 55% of upstream traffic dubious, real stats needed

[edit] Protocol specification

try http://www.bittorrent.org/protocol.html and also look a the open source bittorent client (see downloads page on bittorent.com) Trapper 21:24, 30 July 2006 (UTC)

thx , i will look at ctorrent, do u think it is nice one to look at in the beginning? -- 2 August 2006

Why there is no RFC for BitTorrent or is there any close tcp/ip based protocol? -- 18 October 2006 —The preceding unsigned comment was added by V4vijayakumar (talk • contribs) .

BitTorrent runs over tcp/ip - there is no RFC becasue there is no IETF working group to write one. Trapper 06:30, 22 November 2006 (UTC)

[edit] Legality section

...nice summary, I enjoyed reading it, but if it gets any bigger it might merit its own wiki article Silent0 05:26, 5 August 2006 (UTC)

The link to datagalaxy.net does not work. (83.71.110.112 00:17, 16 January 2007 (UTC))

[edit] Reverting Talk Page

Why are we reverting comments that seemed to make sense out of the talk page? Trapper 00:31, 9 August 2006 (UTC)

I reverted the deletion of those comments, you silly. [1] :) -- intgr 01:06, 9 August 2006 (UTC)

It was the initial deletion that I was questioning Trapper 03:23, 10 August 2006 (UTC)

[edit] Hiding System Tray

Is there someway to minimize the Bittorrent donwloader to the system tray and hide it? Currently, if you move your cursor over the icon, you can see what program you are downloading. Is there anyway to hide what yo are downloading? Jamesino 20:22, 19 August 2006 (UTC)

Sorry, this is not the place for asking this question. The guidelines state that you should talk about the article, not the topic. -- ReyBrujo 03:48, 20 August 2006 (UTC)

[edit] Talk page archival

Since this page was getting hideously huge, I archived messages from 2004 up until last month. Some of the conversations that are still continuing have been copied onto this page as well. Regards, Ladida 12:28, 25 August 2006 (UTC)

[edit] TCP/IP not mentioned anywhere

BitTorrent uses TCP/IP as the underlying transport and network protocols. This is mentioned nowhere in the article. Neither are the default ports mentioned (e.g. 6969 for the tracker). I would add this information myself, but I don't know where to put it. Aragorn2 19:15, 26 August 2006 (UTC)

I agree. I came here looking to find out what ports this protocol uses - which seems a pretty basic piece of information for any internet protocl - and yet "port" appears nowhere in the article. A brief discussion of the technology seems appropriate. The article does point to http://www.dessent.net/btfaq/ , which does discuss some of this stuff. Jim Mahoney 01:05, 25 September 2006 (UTC)

BitTorrent may also use UDP, and port 80 may be used for the tracker port. -expert01 —The preceding unsigned comment was added by 71.196.146.68 (talk • contribs) .

Actually the protocol itself has no defined ports. The tracker url (with port) is specified in the .torrent file and the actual ports used by the clients are entirely arbitrary since they announce themselves to the tracker. So while it does use TCP there are no defiend ports. Trapper 19:21, 6 November 2006 (UTC)

[edit] Inappropriate tone

I have made improvements to the Limitations and security vulnerabilities section and removed this notice:

...since I believe it's OK now. Any questions? :) --220.233.190.26 11:58, 5 September 2006 (UTC)

[edit] Piracy is a mess

Okay, I have been trying for some time now to consolidate all information in piracy into one comprehensive article. Originally this was through significant additions to the article on copyright infringement, but piracy lies somewhat beyond the scope of that article. I just discovered the article on copyright infringement of software, and VCD peddler yesterday. As well, you can find significant discussions in the articles on Bittorrent, RIAA and related articles. I was in the process of creating a proposed article in my user namespace to be at Piracy (information), but in light of the widespread discussion of this issue I've realized that this is not something that I can do alone.

So, I'm asking for help, or at least discussion of ways to clear up the present situation. Please comment on the proposed article's talk page, so that we can keep discussion centralized... despite the insanity that attempts to cover this rather complex topic. --IntrigueBlue 06:46, 22 September 2006 (UTC)

[edit] Too long?

Why did someone put a length tag on this article? I've seen much longer articles. Nothing here seems pointless, and it's well organized.

I suppose the terminology could be separated into another entry, but that seems unnecessary to me.

What do others think?

Aroundthewayboy 03:38, 26 September 2006 (UTC)

I too think it's too long - perhaps time for a split. I suggest taking all the legal related stuff (legal uses etc) and putting it on a new page and leaving the protocol article discussing just the actual protocol not the politics that surround some of it's uses. Trapper 19:35, 30 October 2006 (UTC)

[edit] Sources?

Clients incorporate mechanisms to optimize their download and upload rates, for example using a tit for tat scheme. Peers download pieces in a random order, to increase the opportunity to exchange data. This is both BS and ill worded. tit for tat brings up a battle strategy which is vastly unrelated to sharing, saying it uses a trading scheme is much better. Second, I know enough about the protocol to say that peers download baised on avaliability, if a particular section is only one one seeder then the primary effort of the protocol would be get that section onto other peers. —The preceding unsigned comment was added by 131.247.242.76 (talk • contribs) .

[edit] History?

There's a "new developments" section, but shouldn't there be a History section near the top explaining the protocol's origins and rise in popularity? —pfahlstrom 02:43, 9 October 2006 (UTC)

I agree, I came looking for the day it was launched and couldn't easily find it. 68.42.91.242 06:28, 16 February 2007 (UTC)

[edit] Do not link to irrelevant information

For the users that keep posting links to TBSource and TBDev, these links belong in the BitTorrent Tracker article.

-expert01

[edit] Acronym not linked

Could someone please link the acronym HBO to indicate what it is referring to? —The preceding unsigned comment was added by 213.206.133.13 (talk • contribs) .

I would say it is HBO, according to reference 18, but I am not sure how good that reference is. -- ReyBrujo 04:56, 21 October 2006 (UTC)

[edit] TorrentBytes

The link to the TorrentBytes FAQ should be removed. As a member, I highly doubt the admins want links to their member only bittorrent tracker posted on a highly browsed public website. —The preceding unsigned comment was added by Bleu`dove (talk • contribs) .

[edit] Encouraging illegal download

Not you guys! But I knew I would get your attention. Do you think that if the owner of an intellectual property has pulled it from distribution due to having violated copyright in creating it (i.e. he created something that he cannot legally distribute), that wikipedia should mention in the article on the property that torrents are available? The torrent being illegal of course and against the stated wishes of the rights owner. --Justanother 19:21, 1 November 2006 (UTC)

The answer is "yes", Wikipedia should mention it if it is a significant fact, which in this case it is. Policy makers, copyright owners, and the non-infringing public also benefit from the knowledge that it "is available". The article does not suggest, encourage, or enable illegal behavior, but it does do a great job of what is intended to do: inform.

ACGoris 6 January 2006 —The preceding unsigned comment was added by 216.17.176.97 (talk • contribs).

[edit] DHT type is based on Kad

The DHT type in the article is listed as being based off of Bamboo DHT. However, if you look in the actual source itself, the DHT is based off the Khashmir DHT source base which is an implementation of Kademila. Furthermore, the actual Kademila article gets the usage right. 66.233.137.79 08:28, 4 November 2006 (UTC)

[edit] Speed of Bittorrent

The article says "BitTorrent transfers are typically very fast, because all nodes in a group concentrate on transferring a single file or collection of files." -- what is the comparison? I think few would dispute that a Bittorrent download is actually incredibly slow compared to a webserver. Indeed, it doesn't actually get "fast" until after a very long ramping period, and it doesn't stay "fast" up to the very end (speed ramps down to a crawl toward the end and it often says "ETA: 1 hour" for several hours straight). When its speed is actually measured objectively (total bytes / total time), even for the most well-seeded file, it's rarely fast at all. Furthermore, is it actually any faster than Kazaa or eMule or any other P2P platform? Is there any data to support this claim? And finally, the reasoning given for why it's supposedly fast doesn't make sense: nothing prevents nodes from participating in multiple simultaneous downloads, and thus this reasoning holds for BitTorrent no more than other P2P services. I'd propose a clarification:

"After a moderate ramping period, BitTorrent transfers of well-seeded files can achieve very high speeds, though this speed falls off toward the end of the transfer.

Quinthar 09:01, 6 November 2006 (UTC)

Actually if a client implements the fast extensions (see bittorrent.org) it will start up much faster and if it's well designed will not slow at the end (that's a client issue not a protocol issue) Trapper 09:02, 6 November 2006 (UTC)

Ok, that's cool. However, "much faster" still isn't that fast. A good webserver (say, Akamai) "starts up" incredibly fast and remains that way all the way to the end of the file. It should be made clear that BitTorrent behaves in a very different way (ie, starts slow, ramps up to fast, and then falls off to slow again). Quinthar 03:09, 7 November 2006 (UTC)

no file sharing protocol is going to beat a web server co-located with your ISP becasue the limiting factor is your last mile connection. When the web server is under powered or the owner doesn't want to pay a CDN like Akamai then the overall efficiency of BitTorrent is very hard to beat. Trapper 05:41, 12 November 2006 (UTC)

There's no reason a P2P download can't be as fast or faster than a webserver. Given enough peers, you should be able to saturate any downlink. But really, while the cost-savings of BitTorrent and whether it would be possible to build a P2P network faster than a webserver are interesting topics, they're separate to my core point that BitTorrent is fundamentally slower than a good webserver, and the article should state as much. I think we agree on this point, and I haven't heard any dispute on this point, so I'm going to update the main article. Quinthar 20:23, 12 November 2006 (UTC)

cut from article: Though both ultimately transfer files over a network, BitTorrent differs from HTTP in several fundamental ways. First, BitTorrent makes many small P2P requests over different TCP sockets, while HTTP makes a single request over a single TCP socket. Second, the BitTorrent protocol limits a client's download speed to roughly its upload speed, while HTTP gives no preferential treatment to cooperative nodes. And third, BitTorrent downloads in a random or "rarest-first" approach that ensures high availability, while HTTP downloads in a contiguous manner. Taken together, BitTorrent achieves much lower cost, much higher redundancy, and much greater resistance to abuse or "flash crowds" than a regular HTTP server. However, this protection comes at a cost: downloads take time to ramp up to full speed because these many peer connections take time to establish, and it takes time for a node to get sufficient data to become an effective uploader. As such, a typical BitTorrent download will gradually ramp up to very high speeds, and then slowly ramp back down toward the end of the download. This contrasts with an HTTP server that, while more vulnerable to overload and abuse, ramps up to full speed very quickly and maintains this speed throughout. Furthermore, BitTorrent's non-contiguous download methods prevent it from supporting "progressive downloads" or "streaming playback", as is possible with HTTP.

removed this section. You can also use the http protocol to download a file from multiple mirrors in multiple pieces. Getright did this a long time ago. This confuses the client and the behaviour again. A comparison whit a traditional sequential download can be made, be it either ftp or http, but the current text is just not correct. :Leuk he 12:06, 13 November 2006 (UTC)

What specifically is incorrect, and how would you correct it? That's a fair point that it oversimplifies HTTP and discounts the possible use of Range-Requests for non-contiguous downloads. With this in mind, how about we clarify the first sentence with: "Though both ultimately transfer files over a network, a BitTorrent download differs from a classic full-file HTTP request in several fundamental ways." I've gone ahead and re-added the section with this and other clarifications. Rather than yanking it back out again, can you just correct it in place? Quinthar 07:15, 18 November 2006 (UTC)

[edit] Time for a split?

As has been mentioned the article is quite long. How about we split it into two: the technical stuff about the protcol itself and the political stuff about it's uses? Trapper 05:46, 12 November 2006 (UTC)

I agree It might be time for a split. Maybe BitTorrent (protocol) can keep the introduction and headings 1, 2, a (very) small part of 3 (just note the fact that is is used that way), 5, 6, 7 and 8, and move the rest to something like BitTorrent legal issues. That page would require some work including a new introduction, and could include the headings I just left out. I will put up the tag. Martijn Hoekstra 20:02, 3 January 2007 (UTC)

I also aggree. This page has too much non technical sections that could be placed into a seperate article; maybe placing it in with the BitTorrent client article? IMO this article should lean more twards the technical workings of the BitTorrent protocol. Sections I propose to be removed (or moved to somewhere else) from this article are:

2. Comparison with other file sharing systems

3. Legal use of BitTorrent

4. Legal Issues

7. BitTorrent-related applications

There needs to be more information as to how BitTorrent works in the TCP/IP or OSI model and also more of the technical aspects. I feel this article is confusing the fact that there is a BitTorrent "application" and a BitTorrent "protocol". There needs to be a clear cut definition in the opening paragraph and throughout the rest of the article. --Pchov 11:14, 21 January 2007 (UTC)

There is also the BitTorrrent "social phenomenon". I would say that, to the general Wikipedia readership, that is by far the most important viewpoint. Therefore I would suggest that sections like (1) Torrents, (3) Legal uses and (4) Legal issues and a general overview should stay here in the main article and there should be technical spin-off articles like BitTorrent (client) and/or BitTorrent (protocol). The vast majority of WP readers and browsers are most likely non-technical people. --Nigelj 12:11, 21 January 2007 (UTC)

[edit] Can someone clarify why down is way faster than up

Supposedly, total down = total up. I've set up bittorrent for maybe 5 friends, and we all get 100-200 down, and 10-30 up. Why can't this article explain that? It's possible, but I seriously doubt for everyone like me, there's someone getting 10 down and 200 up. What's the deal? I asked at the help desk once, and all I received were comments from people who experience the same thing, but no explanation. - Peregrinefisher 18:47, 20 November 2006 (UTC)

Though "total down = total up" is true across the whole network (after all, every byte received must have been sent by somebody), it won't necessarily be true for every individual download. In particular, if you join a torrent that has many seeds and few leachers, then most of the people you're connected to already have the file and don't need anything from you (thus the low upstream). However, if you join a torrent that has very few seeders and very many leachers, then all of your peers will want data back from you, and thus you'll find that "up = down" more regularly. Does this make sense? Quinthar 23:41, 20 November 2006 (UTC)

It makes sense, but I would like to learn about whoever is uploading way more than they download. Maybe the internet connections are different in Europe or Asia, where they can easily upload at speeds much greater than in the US. I've had experience with US dsl and cable modems, and if everyone had that type of connection, it seems the download would max out around 25. I guess I want to know where the bits are coming from, because they aren't coming from people like me with a comcast cable connection. - Peregrinefisher 00:07, 21 November 2006 (UTC)

but I would like to learn about whoever is uploading way more than they download. 1> People hire/have access to "seedboxes", commercial grade connections that can upload megabytes/sec 2> Goodish home connections that upload 24/7 3> A willingness to upload on a particular for weeks or months, even if the upload isn't fast. People do this to manage their ratios (as mentioned in the Equiette section) and also in the spirit of sharing. So yes, people upload when they're not downloading, in the best communities, at any given time, there are considerably more people uploading than downloading. —The preceding unsigned comment was added by 202.161.11.199 (talk) 17:35, 7 December 2006 (UTC).

Just glancing at some tomshardware.com forums [2] [3], and everyone who mentions upload speed quotes a number about 1/10 of their download. I know this would be original research if we used it, but can someone find a legitamate source for this and explain it? - Peregrinefisher 01:15, 21 November 2006 (UTC)

It's common sense. There isn't a need for a legitimate source. In regards to bit torrent, there are two factors that will determine your upload speed. First, how fast your internet service provider will let you upload. Especially in the United States, your download will be much more faster than your upload. Charter, in my hometown for an example, allows a 400kB/s download, and a 30kB/s upload. Second, it depends on the amount of seeders/leechers. If your internet provider lets you upload at 1MB/s, but there's 1,000 seeders and only 2 leechers, the chances of you uploading at the full 1MB/s is very unlikely, unless you're the only individual connected to the leecher. This article need not explain bandwidth limitations, because that isn't what it is about. It's about a form of downloading. The situation your describing isn't uncommon. Look into your internet service provider, and find out the information on the bandwidth services they provide. That will hold the key to your answer. Bleu`dove 01:29, 21 November 2006 (UTC)

According to Broadband Internet access worldwide, almost all ISPs have higher download than upload. It doesn't seem like up would equal down. Is it that a bunch of people leave their client running even while not downloading? - Peregrinefisher 01:55, 21 November 2006 (UTC)

You understand that bit torrent isn't a replica of the internet, right? Almost all ISP's do offer a faster download speed than upload speed. What don't you understand about this in regards to bittorrent? I really don't know what your confused about? The fact that ISP's offer a faster download in comparison to upload is just a fact. Bleu`dove 03:19, 21 November 2006 (UTC)

Think of the total torrent swarm as a large pool that has bits added to it by every participant and bits taken out of it by every downloader. In theory you could have a case where all participants have exactly one piece of the file and everybody will end up with all of the file - in that case the average download will equal the average upload. However in real life there are often many clients who have completed their download and are just uploading (seeds) - those clients contribute bits to the pool but don't consume so the average upload rate is higher. Things get confused further by the heuristics of some clinets (such as the official BitTorrent client) which when seeding tend to favor peers that can download fast. Modeling the behavior is further complicated by the fact that many users have asymetric connnections (*cable, adsl) and are often downloading multiple torrents. All of these effects interact to create a very complex model. The math get realy interesting really fast. Trapper 06:28, 22 November 2006 (UTC)

Please refer to Wikipedia:Talk page guidelines This is not a forum about bittorent and it's functionality. --Pchov 10:44, 21 January 2007 (UTC)

[edit] Various

Hi, Possible to give a little brief of why you deleted the various section and how it could be done properly? —The preceding unsigned comment was added by 62.236.111.16 (talk • contribs) .

[edit] Torrent filenames

The article states:

However, a torrent file always has the suffix .torrent.

As far as I'm aware, this would be more accurately stated:

However by convention, a torrent file always has the suffix .torrent.

I'm pretty certain there's nothing anywhere that demands the torrent file be named anything in particular. I could easily modify the "official" client python code to look for files called .foobar and it would still work fine since that's just the file that contains the actual metadata that the client wants to know about the associated download.

208.26.45.85 23:21, 30 November 2006 (UTC)

Change made. Next time, you should feel free to be bold, and make the change yourself :-) splintax ^(talk) 14:11, 3 December 2006 (UTC)

[edit] 55% of upstream traffic dubious, real stats needed

The first reference, cited in the opening paragraph in support of "CableLabs...believes that BitTorrent represents 55% of the upstream traffic on the cable company's access network", actually says:

"BitTorrent uses tremendous amounts of bandwidth, especially in the upstream (home outward) direction. How much? Try 10 BitTorrent users gumming up 55% of the upstream signal path, per neighborhood node."

and is refering to a simulation based on a small sample of BitTorrent behavior. It is not an actual traffic measurement as is implied, and my reading is that the "10 BitTorrent users...per neighborhood node" is pure supposition - if the actual number of users is unknown, the simulation does not reveal the extent to which links will be saturated. Surely someone must have some up-to-date measured figures - even if it is only from one typical ISP? In fact, the cited article ([4]) says "some 18% of all broadband traffic carries the torrents of BitTorrent" which may be worth including, especially if anyone can turn up the original paper, rather than just this article about it. 81.79.242.103 13:31, 31 December 2006 (UTC)

Today the 18% number in the article was changed to 18% carries the bittorrent files to initiate. The above source looks indeed like it is only the bittorrent files. Unfortunately, the source is not very clear on it. I hope someone can fish up the actual paper to check what it says exactly, and we'll be out of this pickle for a while. I won't change it straight away, but I propose a change to "the estimates on the amount of bandwith used range between 18% and 55%" or something similar, untill someone finds the paper itself. Martijn Hoekstra 19:58, 10 January 2007 (UTC)