Closed Bug 203571 Opened 22 years ago Closed 21 years ago

Mozilla has no built-in support for BitTorrent

Categories

(Core Graveyard :: File Handling, enhancement)

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 236755

People

(Reporter: bens, Assigned: law)

References

(
URL
)

Details

Attachments

(1 file)

Bit Torrent Python source
141.04 KB, application/x-gzip
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Build Identifier: Bit Torrent (example at http://torrentse.cx) requires a 3rd party plugin, which works, but doesn't allow full capability for embedding torrent-served files as images. (for example) Reproducible: Always Steps to Reproduce: 1. Click on a torrent link. Actual Results: Asks for how to handle .torrent file(s). Expected Results: Should have downloaded images using Torrent protocol, which is fairly simple.
No more additional features in Mozilla please, this is definitely something that should be provided as a third-party XPI. (plus this is used for warez 95% of the time, just look at the files on http://torrentse.cx/ ) Propose to mark WONTFIX.
What is torrent exactly? Is it a file format? Or a transfer encoding?
Bit Torrent is an efficient tool for distributing large amounts of data. It's used for warez because: 1) It's very efficient: it makes use of the upload capacity of those downloading .torrent files to distribute the load. This results in intensively reduced hostings costs for large downloads. As a result, 2) It's very cheap. Distributing the upload demands on to people who are downloading the file results in a system that scales extremely well. Recently, this was demonstrated by serving tens of thousands of RH 9 ISO images (successfully!) over a T1. Which means that 3) It works. Very well, Very efficiently. It has many perfectly legitimate uses, and just because the warez crowd has recognized these strengths doesn't negate the truth of its effectiveness!
You really do want to answer my question... ;)
> What is torrent exactly? Is it a file format? Or a transfer encoding? From my understanding, a "handled" file format. A .torrent file is easily defined as a mime type, and there's a functional plugin available (works on Windows or Linux, I haven't tried others) that works quite well. Feel free to try out the documentation from http://bitconjurer.org/BitTorrent/ - but there are basically four elements: 1) The file being transferred, 2) the .torrent file, 3) A "tracker" that co-ordinates the download/upload process from various peers, and 4) the bi-directional client. The goal of all this is an ad-hoc p2p system for distributing the load of downloading a file onto the clients downloading the file. The file being transferred is preprocessed, broken into chunks, and information about these chunks are saved in the .torrent file. Also in the .torrent file is a reference to the tracker. The tracker is responsible to ensure that clients each get their fair share of bandwidth from other clients, as well as deliver a fair share to other clients. Finally, the client delivers sections of the file as well as downloads files from the other clients identified by the tracker. I'd like to see Mozilla contain a functional client for Bit Torrent networks, it would make sense where a webpage contains a .torrent link to a group of large images, or mpg movies, (that I see all-too-often slashdotted) to be able to write "img src=bigimage.jpg.torrent"... in HTML and have it work! Does this answer your question?
OK. So the .torrent file just contains information on where to get the real data from. Which is no different than realplayer "stream" files or MP3 playlist files. Why is it bad to pass this off to a helper app again? How is it impossible to do images using torrent-served files? Isn't that what <object> is for? (Oh, and your previous comment is unreadable; whatever browser you used to make it, please stop using it. ;) )
It's not impossible to "do images" like this. It's impossible to embed them in, for example, a web page. Since the protocol is fairly simple, well documented, and an open-source solution exists, it seems that it would be advantageous to support this natively within Moz. EG: img src="blah.jpg.torreng"> -Ben PS: I *think* the browser I used was Moz 1.x! I'll find out in a second - there's no "preview" button...
> It's impossible to embed them in, for example, a web page. <object>. See my comment. <img> is deprecated in any case. The point is, <img> expects that it will get back image data from the server when it loads whatever is at the src url. That's the definition of <img>. So what you're asking for is not .torrent support but .torrent support in <img> tags... a generic .torrent support module would simply be something that grabs all the data and dumps it on the disk somewhere and then lets something else take over and do whatever it wants to with it... which is exactly what plugins do. So again, why is it a problem to do this task with a plugin? (The key here is that I fail to see the benefits, and I see drawbacks -- bloat and complexity in the codebase.)
I appreciate your feedback. As you could probably guess, I think that .torrent is an awesome technology that I think should be used. But, this may be one of those "bright ideas" that's misplaced. The problem I was specifically looking at was the case where you have a site about a homemade rollercoaster, or casemod, etc... hosted on a personal webserver on some ADSL line, but getting linked to from fark.com or slashdot.org... the effect is similar to a DDoS attack. But, if a torrent image or media file could be embedded into the HTML, this would greatly mitigate the problems of the above scenario, as the majority of the bandwidth used would be from other people downloading the file(s). But, handling it as a plugin means that you can't do this - you can't link to an mpeg of whatever and have it just play if you use Torrent as the download mechanism. This means the procedure goes: A) Click the link, B) Choose the D/L location C) Save the file to disk. D) Load Media Viewer (QT, Real, WMP, etc) E) Select file F) Watch movie As opposed to: A) Click link B) Watch movie. Perhaps the real issue here actually is that Torrent should be a protocol, handled thusly: torrent://path-to-url.torrent Thoughts? -Ben
> But, handling it as a plugin means that you can't do this Why not?
Until BitTorrent rises as a protocl to the level of standardization of ftp and http, I think it is a bit giddy to expect it to be built into the stock browser. A plugin is the way to go. > Perhaps the real issue here actually is that Torrent should be a protocol, > handled thusly: > torrent://path-to-url.torrent This seems appropriate. BitTorrent is essentially a protocol for delivering files, is it not? If you could write a pluging that would be invoked when mozilla encountered the above, then this would be a solution to the problem. The question is whether mozilla offers any way for a plugin to tell it "I should be handed control when you see a URL for protocol XYZ". Does such capability exist?
Yes, of course. You register yourself with the right contractid, then any time the relevant protocol is seen you will be asked to create the relevant URI objects, data channels, etc. See http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIProtocolHandler.idl
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 this end, I fully agree with Olivier (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.
Alright. I think that pretty much sums up the situation. Henry, thank you for the information!
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
*** Bug 222834 has been marked as a duplicate of this bug. ***
*** Bug 225051 has been marked as a duplicate of this bug. ***
*** Bug 228671 has been marked as a duplicate of this bug. ***
*** Bug 230587 has been marked as a duplicate of this bug. ***
QA Contact: chrispetersen → ian
Summary: Mozilla has no built-in support for Bit Torrent → Mozilla has no built-in support for BitTorrent
While I agree with most of the assesment of Henry James, I think his conclusion is wrong. BitTorrent *should* be included bittorrent:// would be awesome. I do agree it should be only used in a download-manager context though. I'd be fine re-serving everything in my download manager via bittorrent. I would like to re-terate my original comment: Since Mozilla is still primarily a linux geek tool (no offense to the rest of you, but I think that segment has the most penetration) us linux geeks spend a lot of bandwidth on the following formats: .ISO .gz. .zip .MP3 Also adding torrent links for large content would alleviate much of the /. effect. This is by no means a need, but the "way cool" factor is very high. Thank you for your time, And thanks for the best browser ever
There's a stratigic value to mozilla.org as well. Mozilla can offer releases (and even nightlies) as torrents. And using Mozilla, you don't need a third party product to download. That would seriously cut Mozilla.org's bandwidth consumption, and provide faster downloads to those who choose to employ them. I think Bit Torrent is a revolution in downloading (perhaps even a successor to FTP). Having a torrent protocol would be great. It would mean that Mozilla could offer a P2P download client for any site who wishes to employ it. P2P is part of downloading now, and is growing daily. We can love FTP all we want, but P2P is here to stay. This, thankfully has no legal implications. It's a pretty harmless technology. It's used by many sites, such as 3dgamer.com, which pushes downloads by the GB. Supporting this, would make serious headway in the Gamer/P2P market, who utalize such technoogy often. This also has a profound impact on Linux Distro's, which when including Mozilla have included support for P2P downloading of new ISO's. I think the community benefit of such support is great.
*** Bug 231851 has been marked as a duplicate of this bug. ***
Please reconsider this idea. I'll help to define the scope of how this can be implemented. Summary: 1) BitTorrent not to be used for embedded data. Download data, through download manager only. 2) No advantage over current BitTorrent installer if this is created as a plugin. Only advantagous as a default feature. BitTorrent will be used for download files only, not files shown inline (in browser window). The Mozilla download manager can be modified to have similar functionality to the BitTorrent download manager. Boris, this functionality can be made into a plugin. However, there is no point to make it a plugin because the BitTorrent installer is so easy to use. The real power of the technology will shine if it's installed by default in mozilla. I suggest this be included into Mozilla by default. I posted request for this feature as have a few others. Please do not reject this idea because the poster of this specific bug # may have not understood the idea fully. BitTorrent could be the next killer app. To help mozilla evangelize it's really important for us to have features which are "in your face" better than IE. I hope I've helped clear up the questions about BitTorrent.
I sorta agree with Kroll, but don't. I think it could be used for embedded data, like movies and audio. The current bittorent method is a clever hack - download a file with a torrent URL in it and that gets handed off to the configured viewer. I'd prefer to see the torrent protocol added as torrent:// Think of it this way, how much utility s ther in only being able to download avi/qt/avi/PDFs? Now we can have the PDF open in a browser window or embed and view it in a web page. For 99% of sites, its prolly useless. But for CNN.com, slashdot, ISO/deb/rpm mirrors, and the like, the utility would be huge! I think the iso/deb/rpm thing alone would justify its inclusion. I'm also suggesting we add some kind of central (or distributed, but one) tracker service so that ftp:// and http:// can be converted to torrent:// on the fly when content-length headers (in http) report lengths over X MB. Hell, I'd pay to use a tracker service! 1) Start regular d/l 2) Check tracker for the same file 3) Start torrenting the remaining part of the file
Alias: BitTorrent
While I agree that technically, BitTorrent support is unnecessary, I think strategically it could help Mozilla. Bug #184452 acknowledges that it will not be long before > 4Gb downloads become commonplace. If things continue as is, Mozilla will be forced into a premature and painful change to its core APIs to support > 4Gb downloads. But Mozilla could head off this forthcoming apocalype by putting its weight behind BitTorrent. BitTorrent is already the de-facto standard among the technically inclined for downloading big files. If Mozilla pushes it out to the general populace then the day when someone says "Mozilla is **** because it won't download this software" could be postponed almost indefinitely. Technical issues: A refactored, bare-bones BitTorrent client built on the Mozilla platform could be really, really tiny. It would need access to the OS's underlying 64-bit file APIs. I think the torrent: URL scheme is a dumb idea. If the URL was to contain all the information from the .torrent file, then it would be several kilobytes of hex-encoded gibberish. If it was just a pointer to the real .torrent file, then it would look something like torrent:http://somesite.com/somefile.torrent, and what exactly is the point of that? BitTorrent currently interacts poorly with firewalls. I don't know if this is being worked on. BitTorrent has performance problems on asymmetric connections. These can be completely fixed by prioritising ACK packets with a traffic shaper.
Adam, your comments are best suited for the bittorrent discussion group, rather than Mozilla.org
Status: RESOLVED → VERIFIED
What possible value would my comments have in a bittorrent discussion group? It's not like any bittorrent developers would be unfamiliar with any of the things I mentioned. However, it is clear that some of the people commenting on this bug are unfamiliar with bittorrent. And noone has yet brought up its strategic value with respect to Mozilla's 4Gb limitation. Hence why I felt my contribution was worthwhile. Since you clearly don't value my contribution, I will leave you to your 32-bit file-offset hell.
Adam, It's not that your contribution isn't respected or appreciated. Mozilla is not in any position to rewrite, or help author the next generation of BitTorrent. It's up to the BitTorrent group to do that. This bug is regarding Mozilla including a BitTorrent client of it's own. In any regard it would need to be compatible with the current BitTorrent 1.0 specifications. What you are discussing is a change to the standards. That's not Mozilla's place. You need to talk to those involved about doing that.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Gerv is trying to have another attempt at getting this confirmed... let's see if he has any more success... *** This bug has been marked as a duplicate of 236755 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
Alias: BitTorrent
Opera now has native bittorrent support built-in. The behaviour is the same as with FTP-/HTTP-Downloads in Opera. http://www.opera.com/bittorrent/
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: