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.
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.