Slashdot Mirror
Mozilla and BitTorrent?
mcrbids asks: "Recently, I submitted this bug report to Mozilla's bugzilla requesting the additional feature that Mozilla should support BitTorrent files natively, so that Moz could support inline image tags with BitTorrent, among other things, so that high-bandwidth sites can survive the dreaded 'Slashdot effect'. However, Torrents (and many other P2P suites) have been used largely for warez and porn. Do you think the potential politics behind this outweigh the benefits of BitTorrent, such as getting a full Linux distro with record download speeds?" Update: 04/29 16:16 GMT by C :One of the links in this article was removed at the request of a site administrator.
Providing inline support of a protocol does not a political issue make. That's like saying "FTP is mostly used for warez but also an excellent place to get distros."
First.
BitTorrent generally doesn't work very well on small files. This is because clients tend to drop off too fast. In fact, you can calculate the "optimal filesize", that is, the length when even if the client exits right after finishing the file, the torrent will survive and sustain itself. I believe it is at around 1GB, but I don't have the figures handy. Mabye the guy who did the calculations will chime in sometime.
This brings another problem with BitTorrent - it doesn't work well unless clients are connected for a while after they finish the file. This could be "quick-fixed" by leaving the client open until it has sent at least one copy of the file out (or that many bits, your choice).
The third problem that it would have is that BitTorrent generally opens a whole bunch of network connections. Many of those are incoming (NAT people won't work as well), and many are outgoing. This large amount of sockets tends to make some of the cheaper commodity cards break. You see alot of these problems on the BitTorrent mailing lists.
Also, Porn has always been an early adopter of new technology. VCR tapes, DVDs and the internet are excellent examples. Because porn uses it isn't a reason to count the technology out.
You can't see this if you have sigs turned off.
The discussion hasnt even teterred out, and its far from a clear thing. At best, its a misunderstanding/disagreement over how best to handle a new file format.
.torrent files is the same as any other media app - via a plugin.
At worst, its the Mozilla team saying (rightly) that the best way to handle
From the discussion on the bug report, it sounds like the torrent dev's havent made a plugin, dont realize the power of plugins, or dont want to make a plugin.
If there was a fully functional plugin that couldnt do some particular thing, that would be different. Instead, its just a standalone app, asking for the Moz team to 'link it up'.
Again, just my take on it.
GPL'd web-based tradewars themed space game
the length when even if the client exits right after finishing the file, the torrent will survive and sustain itself. I believe it is at around 1GB, but I don't have the figures handy. Mabye the guy who did the calculations will chime in sometime
There is no such length. Length, usage patterns, and network connection speed are all fundamental factors.
This brings another problem with BitTorrent - it doesn't work well unless clients are connected for a while after they finish the file.
It works *better* if this is the case, but it's not really a problem.
If someone is downloading from the original source, and another person begins, then the first immediately becomes another source.
BitTorrent isn't designed to make the original source unnecessary...it's designed to simply reduce load on the original source. Which it does quite well. The original source tends to send out around the bandwidth of a single upload at any one time.
Many of those are incoming (NAT people won't work as well), and many are outgoing.
As a result, they'll get slower transfers. This is simply a problem with NAT -- NATted users are using a broken network, and have problems with many, many protocols. FTP is included in mozilla, and NAT is even worse with FTP.
This large amount of sockets tends to make some of the cheaper commodity cards break.
Sockets have nothing whatsoever to do with the NIC. They exist at a higher level, and will not cause the card to break.
May we never see th
Well, first off, BitTorrent isn't a P2P system. It is a P2P protocol. It doesn't search for your favorite MP3s. You can't even "surf" through it. You give it a .torrent file (analogous to a URL, though with some interesting features), and it gives you the file(s) that "URL" points at.
It's unique in that it is a highly efficient and secure cooperative system -- and is very low-profile, as well. It is capable of delivering large amounts of data that is originating from a source which cannot normally afford that sort of bandwidth. It can move more bandwidth than even large companies can afford; when Red Hat 9 was released through BT, traffic peaked at nearly 1.5 gigabits per second, or the full bandwidth of ten OC3 connections.
It redirects to Tubgirl now.
This RFE does not make much sense.
First, I like to point out that the name of the protocol/application in question is not "Bit Torrent", but "BitTorrent".
This aside, let's differ between two kinds of possible content to be handled via BitTorrent: web content (HTML, images, Flash animations, etc.) and offline content (software, music, video, etc.).
The first kind of data is not suitable for BitTorrent because they are too small. (This is a "basic knowledge" about BitTorrent, if you don't understand why, please refer to general technical readings regarding the protocol.) The second kind of data is mostly not suitable for being embedded into a website, people normally download them and proceed with them outside of their webbrowser.
But even if any data of the second kind is indeed embedded into a website (like a video, although I never watch video embedded in my webbrowser), it's not a good idea to bind this embedding process to BitTorrent, because every "BitTorrent connection" has a lifespan which need to be specifed by the user himself. A file keeps being uploaded after its download completes within BitTorrent, until the user decides to "finish" this file. If a video embedded into a webpage is downloaded via BitTorrent, when should the upload of this same video stop? Immediately after the download completes? Or when the user leaves the website? Both are rather too soon to keep the file healthy alive.
What would make sense, however, is to write a BitTorrent download manager plugin, perhaps a sidebar, similar to the new download manager of Phoenix/Firebird. The user could handle his BitTorrent downloads within the interface of the webbrowser, and at the same time keep control over the lifespan of each of the files being transfered.
In the end, I fully agree with Olivier (Bugzilla comment #1), this is a plugin issue and WONTFIX.
No offense here, but I think the original "bug reporter" has not understood BitTorrent's field of application and mode of operation quite well (and, has not got the name "BitTorrent" right).
Henry 'Pi' James
BitTorrent dev team member
PS: My opinion here is personal and does not represent Bram (the author of BitTorrent) or any other co-developers, although I'm pretty sure they would agree with me.
First of all, torrents are not that useful for small files. If a website had a LOT of images it might be reasonable since you can create a torrent of a number of files and somewhat avoid the small file penalty.
Second, the BT protocol is far from established and stable. Bram mades non-trivial changes in minor release numbers, eg the 3.1 to 3.2 changes. He is very interested in backwards compatibility but things are still at the stage where that is not guaranteed and there are all kind of extensions that people would like to add to the protocol.
Finally, BT would be of little use to the "average joe who has a few pictures of his backyard roller coaster" that gets posted to slashdot and dies. First of all, he or she would not know that a slashdotting was coming, and therefor would have to have a tracker running all the time, ready to serve the torrents. Currently the "reference" tracker is written in Python, which means joe schmoe needs to somehow get that running on their server... in the case of peoples' homepages that are susceptible to slashdotting, usually it's lightweight/free hosting and they don't have the option of saying "Hey sysadmin, can I run this Python server on some funky port (that will need to be opened on your firewall)?"
Also, any change in the web site would require the torrent to be rebuilt, and the old one removed.
Finally, the tracker would die under a slashdotting. While BitTorrent allows the "heavy lifting" of the transfer to be spread out amongst the swarm, every user that wishes to join must contact the tracker... indeed, as users download they constantly contact the tracker to get updated peer lists and keep the tracker's info fresh. If a site cannot survive serving a slashdotting through Apache (which is highly tuned for what it does) then it's certainly not going to be able to provide the CPU and Ram that the poor little python tracker is going to require to manage a swarm of tens of thousands. Go to any of the illicit trackers (such as torrentse.cx) and note that while the web pages may be relatively snappy, the tracker is what gets killed and always has very long connect times and LOTS of timeouts. The admins of torrentse say that they are getting about 4000 hits a day, and they are pulling their hair out writing custom trackers in php and mysql (and spread over multiple ports) to cope with the load. Now, how for the love of god is joe average's tracker supposed to support a near-instantaneous 50,000 hits or more? It makes no sense.