Live data from Hacker News

WebTorrent now works in the browser, end-to-end

twitter.com

71–80 of 88 posts

Re: WebTorrent now works in the browser, end-to-end

#71
post #69
post #61

Earlier quoted context omitted.

What would be the benefit of a native application over using a browser extension? I don't see the advantage of "do it native" here. Nor do I see the advantage of doing in the browser. They both seem like perfectly good places to write a BitTorrent client. And I can certainly imagine some interesting cases where I would want to allow my site users to send traffic between each other over a well known, advanced P2P synd…

>They both seem like perfectly good places to write a BitTorrent client. Except they aren't. Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations. A good bittorrent client on a g…

A) you don't need a complete bittorrent stack

B) you don't NEED a more efficient implementation

C) many torrents do not have thousands of files open

You're confusing "is a complete replacement for bittorrent" with "has uses." This definitely has uses.

"Worse is better."

Re: WebTorrent now works in the browser, end-to-end

#72
post #63
post #40

Earlier quoted context omitted.

Nitpick: traditional bittorrent sits on top of TCP. utp, the protocol to make torrents run smoother, does run on UDP, but it's not the official way to do it (although most clients should do it)

uTP isn't really to make torrents run smoother. It's to allow NAT traversal.

uTP was developed to work around bufferbloat-challenged DSL/DOCSIS CPEs, smoother is a reasonable characterization for it. It has since gotten some NAT traversal abilities as a bonus.

Re: WebTorrent now works in the browser, end-to-end

#73
post #63
post #40

Earlier quoted context omitted.

Nitpick: traditional bittorrent sits on top of TCP. utp, the protocol to make torrents run smoother, does run on UDP, but it's not the official way to do it (although most clients should do it)

uTP isn't really to make torrents run smoother. It's to allow NAT traversal.

Actually (again, nitpicking because I love Bittorrent) the reason it was created is to allow smooth day-to-day operations of a computer with a long-running bittorrent client and several other shorter-terms network applications, such as web browsers, chat applications, VoIP softwares, multiplayer games...

The goal is to make sure that bittorrent automatically takes full control of the interface when nobody else is using it, yet quickly gives control to whoever needs it when needed, without manual intervention from the user (the notorious "set speeds to 10% to not slow down your web browsing").

That said, uTP being based on UDP gives the nice side effect that NAT traversal is effectively possible.

http://bittorrent.org/beps/bep_0029.html

Re: WebTorrent now works in the browser, end-to-end

#74
This looks fantastic for an idea I've been kicking around: Using BitTorrent as a way for clients to upload multi-gigabyte files to a website without using FTP.

The idea is to leverage BitTorrent's robustness in the face of random disconnections and reconnections as well as the easy-to-use throttling options that most clients expose.

The server would run a special BitTorrent client that never seeds, to prevent malicious users from using the server as a gateway to redistribute content.

So, rather than the traditional cloud of people seeding and leeching, the only participants would be one client seeding, and the server leeching. Once the transfer completes, the user could disconnect and the torrent would cease to exist.

Re: WebTorrent now works in the browser, end-to-end

#75
post #67
post #66

Is the info hash different from a magnet url? can they be translated from one to the other?

As i understand it, a magnet URL is a way of transferring an infohash as a URL scheme, so that it works with other programs. For example, the following magnet URL: magnet:?xt=urn:btih:e666231c9a34be278f6cfc390099e4084b30e023&dn=The.Giver+2014+720p+REPACK+HDRip.x264+AC3-JYK&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Fope…

Please edit or delete this comment. It's stretching the page.

Re: WebTorrent now works in the browser, end-to-end

#76
post #74

This looks fantastic for an idea I've been kicking around: Using BitTorrent as a way for clients to upload multi-gigabyte files to a website without using FTP. The idea is to leverage BitTorrent's robustness in the face of random disconnections and reconnections as well as the easy-to-use throttling options that most clients expose. The server would run a special BitTorrent client that never seeds, to prevent malicio…

Sounds more like rsync over WebRTC.

Re: WebTorrent now works in the browser, end-to-end

#77
post #74

This looks fantastic for an idea I've been kicking around: Using BitTorrent as a way for clients to upload multi-gigabyte files to a website without using FTP. The idea is to leverage BitTorrent's robustness in the face of random disconnections and reconnections as well as the easy-to-use throttling options that most clients expose. The server would run a special BitTorrent client that never seeds, to prevent malicio…

Sounds more like rsync over WebRTC.

Re: WebTorrent now works in the browser, end-to-end

#78
post #69
post #61

Earlier quoted context omitted.

What would be the benefit of a native application over using a browser extension? I don't see the advantage of "do it native" here. Nor do I see the advantage of doing in the browser. They both seem like perfectly good places to write a BitTorrent client. And I can certainly imagine some interesting cases where I would want to allow my site users to send traffic between each other over a well known, advanced P2P synd…

>They both seem like perfectly good places to write a BitTorrent client. Except they aren't. Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations. A good bittorrent client on a g…

Sounds like a whole lot more bellyaching. Why so serious? Dial down your zeal friend.

BitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps).

Who cares if you're using mmap, epoll, or inotify? Are you intimate with the performance limitations of IndexedDB in all browsers? How versed are you on the performance hit taken by File API? When do these limits become problems? Why would a browser need to keep open a filehandle for every "every" in the first place? That's certainly not at all how https://github.com/js-platform/filer works, on either it's IndexedDB or it's WebSQL backend.

As for your networking dilemmas, I recommend you check out: The network discovery api (which can enumerate UPnP and DNS-SD), WebRTC's TURN/Stun for correctly choosing from available addresses, and a whole bunch of other web stuff that you obviously don't know anything about but think is explicitly the domain of Real Serious Programming With Real Applications.

Not everyone needs to be operating at the fantastical extremes you are concocting, not all use cases are gigantic seedboxes on fat pipes. It's ok to deliver capabilities that someone else might already have, and maybe not even have some quirks or possible points of poor comparison.

You're throwing a whole bunch of technical minutia at the problem you want to have. You're picking a false fight (and one that the web has plenty of good repostes you didn't know/omitted to retort with). The web might not be the best choice for using a gigabit ethernet connection (or maybe it actually does it fine in some conditions!): the act of finding these particular points to dive deep deep into as an excuse to ignore, shun, and spit upon the expansion of human technical capabilities is a close-minded injustice. It's bigotry, simpleminded technical bigotry showing off your inability to open your mind to possibilities, unwilling to open your arms to new improved things becoming available to people who want them and will benefit from their use, it's your own intransigence in the face of the ongoing adaption and mutation going on in the world. You're in for a bumpy ride if you are going to cling so tightly to your notion of what things are for and how they ought be.

Re: WebTorrent now works in the browser, end-to-end

#79
post #33

Earlier quoted context omitted.

> It's sad that BitTorrent is otherwise basically dead (as a way to obtain content). Where I live (Germany) you often get immediately subpoenaed (or the German equiv.) if you use it to download something. That's just plain wrong. Maybe if you are downloading the latest hollywood flick from TPB you'll get a "Abmahnung" but that's about it. It's nowhere near "dead". If you are not using one of the big public trackers y…

do they attack you for using btsync between your own PCs?

Of course not, nobody's attacking anyone for using a protocol. The only group targeted are people downloading certain movies or music where the company owning the content instructed another company to grab the peerlist of said torrent (in this case) and to get the info on the peers so they can send them scary letters extorting money.

Re: WebTorrent now works in the browser, end-to-end

#80
I can't get it to work, hope this helps:

Firefox 32:

ICE failed, see about:webrtc for more details

Nightly 35a1:

Mandatory/optional in createOffer options is deprecated! Use {} instead (note the case difference)!

setLocalDescription called without success/failure callbacks. This is deprecated, and will be an error in the future.

ICE failed, see about:webrtc for more details

this._pc is null bundle.js:25705

Chrome 37:

Uncaught, unspecified "error" event. bundle.js:9134

Post reply on HN