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
There is no such length. Length, usage patterns, and network connection speed are all fundamental factors.
The calculations are not exact -- they assume a perfect network, generally. This will be perturbed by the real-world data, but they generally aren't more than an order of magnitude off. The reason is because connection speed doesn't matter unless you have highly asynchronous connections. The client will stay on the swarm as long as it needs to in order to receive the entire file, and subsequently will send out data during that time.
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.
I am not arguing this - I am simply saying that it doesn't work *well* for small files. There are situations in which it will still improve the load on the source server, but these situations only occur when there are more than one person downloading the file at the same time (only for high-traffic sites). That being said, most of the web isn't comprised of high-traffic sites, and they will be just as slow if not slower if they were BitTorrent-enabled.
The original source tends to send out around the bandwidth of a single upload at any one time.
Unless there are multiple clients which are just starting. In this case it will send out twice the normal bandwidth.
Sockets have nothing whatsoever to do with the NIC. They exist at a higher level, and will not cause the card to break.
My wording was off. The large amount of sockets and specific network pattern of BitTorrent tends to cause bugs to appear in network card drivers (or firmware). There are numerous problems on the BitTorrent-help list which have been solved by upgrading or downgrading the driver (or firmware). So they don't cause the card to break, rather they cause the drivers to not work.
You can't see this if you have sigs turned off.
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.
So if someone wants to have say, a video blog, they shouldn't have to pay for the zillions of megabytes in bandwith
What?!? Of course they should. If someone wants to have a video blog they sure as hell are going to have to host it somehow. bandwidth doesn't grow on cat5 trees.
slashdotters obviously have no clue how bittorrent works and the actual details about what bandwidth it can actually partially recover. so i'll explain something to all of your deaf ears and eyes:
it is only going to be useful when the bandwidth load on the server is high due to sudden large instant demand (ie: slashdotting) for large objects (cd images, large distributions, hi-hi-red images, videos, etc). at that point many of the peers downloading will help save bandwidth by serving the portion they have already downloaded to others. but after the initial rush is off, not many seeds will be left as most people have downloaded it and bittorrent has been closed or exited on its own (nor should there be any) as the server has plenty of bandwidth to satisfy requests itself at that point. that's the servers job. to be the reliable source of content. bittorrent just helps lower the peaks during high load (peaks over short periods of time are often what server-colo sites charge for).
quit trying to use bittorrent as your sole hosting solution so that you never have to use any bandwidth. that's what MNet is for (distributed storage and hosting) or possibly freenet.
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.
The web server needs to send out the correct content-type info. Does BitTorrent have a mime type? Or just an extension?
For example, on some sites if you click on a file that ends in .wmv it doesn't open in windows media player. .wmv is not in the mime.types file of your standard RH distro (at least as of 7.3). The solution is to add..."
" to the mime.types file on the server, apache then sends out the correct content-type, and if Mozilla has the wmp client registered for that mime type, all works wbell.The reason IE works is that Microsoft will trust a file extension to determine content type over content-type info, and that little tidbit has been the source of many an exploit over the years...
One thing that pisses me off, however, is that every time I want to download something with bit torrent I have to open up Internet Explorer.
Why is that? I've been using BitTorrent with Mozilla for several weeks now, and it works great! Just set up the MIME-type (and file extension) correctly and it should work fine!
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Protocols are pluggable. It's easy to write a component that implements nsIProtocolHandler and define any URL format you want. So yeh, torrent://hostname/filename would work fine, and the torrent protocol handler would be written to do the magic right thing with hostname and filename. Isn't Mozilla c00l?