Closed Bug 203571 Opened 21 years ago Closed 21 years ago

Mozilla has no built-in support for BitTorrent

Categories

(Core Graveyard :: File Handling, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 236755

People

(Reporter: bens, Assigned: law)

References

()

Details

Attachments

(1 file)

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: 21 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: 21 years ago21 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: