Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

81–88 of 88 posts

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

#81

Post by M2Ys4U »

the8472 wrote: post #69
rektide wrote: 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…

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

While it's only available to privileged and certified apps, Mozilla's TCPSocket Web API[0] gives you (unsurprisingly, given the name) raw TCP sockets.

The W3C also has a TCP and UDP Socket API[1] under development.

Obviously, exposing raw TCP/UDP sockets to the open web is a Bad Idea but Web Apps are more than that.

[0] https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket

[1] http://www.w3.org/2012/sysapps/tcp-udp-sockets/

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

#82

Post by M2Ys4U »

finnn wrote: post #67
u124556 wrote: 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…

> urn:btih probably means something, google it

It's a Uniform Resource Name (hence "urn"), btih (BitTorrent Info Hash) is the namespace identifier and the rest is the namespace-specific string, the actual infohash.

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

#83

Post by dragonwriter »

M2Ys4U wrote: post #81
the8472 wrote: post #69

Earlier quoted context omitted.

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

>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). While it's only available to privileged and certified apps, Mozilla's TCPSocket Web API[0] gives you (unsurprisingly, given the name) raw TCP sockets. The W3C also has a TCP and UDP Socket API[1] under development. Obviously, exposing raw…

Chrome also a set of raw socket API [1] covering UDP, TCP client, and TCP server sockets.

[1] https://developer.chrome.com/apps/app_network

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

#84

Post by finnn »

M2Ys4U wrote: post #82
finnn wrote: post #67

Earlier quoted context omitted.

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…

> urn:btih probably means something, google it It's a Uniform Resource Name (hence "urn"), btih (BitTorrent Info Hash) is the namespace identifier and the rest is the namespace-specific string, the actual infohash.

Thanks

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

#85

Post by VikingCoder »

the8472 wrote: post #70
VikingCoder wrote: post #57

Earlier quoted context omitted.

It doesn't need to be a native code extension; that's not what I'm talking about. In Chrome, you can write browser extensions that are essentially off-screen web pages (in simple HTML and JS). Two advantages of "do it in the browser" are, in theory it would run on every platform that browser is installed on with no additional run-time required (like Python or Java), and two, it could run on Chromebooks. Say, in Incog…

But in case of a browser-extension you just substitute "python" with "chrome" as a runtime.

Yeah, you're right. Do you want to compare the install base of Python versus that of browsers like Chrome and Firefox?

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

#86

Post by ante_annum »

patrickaljord wrote: post #12

This is a very cool project but it is not compatible with current bittorrent clients. It uses webrtc for the transport instead of UDP. In order for it to be compatible with traditional bittorrent clients, those clients would have to implement communication with webtorrent clients, which hopefully shouldn't be too hard, still as of now it won't work with current clients. Still very cool though and I hope traditional c…

Feross actually gave a talk about this where a lot of these questions got answered.

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

#87

Post by [deleted] »

api wrote: post #63
rakoo wrote: 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.

[deleted]

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

#88

Post by vr000m »

rakoo wrote: post #73
api wrote: post #63

Earlier quoted context omitted.

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 usi…

Yes, this is a typical feature of delay-based congestion control. Especially, when cross-traffic increases the delay because the change in observed queue size.

uTP also implements LEDBAT, which is a scavenger class of congestion control. See CC implementation details: https://tools.ietf.org/html/rfc6817

Post reply on HN