48

There isnt much more to add. Is it possible to build a torrent client using only HTML and JavaScript. You can not use things like Java, ActiveX, NaCl... If yes, please give a high level description.

I dont have much knowledge about front end dev, but I think websockets will be able to do the networking (is it possible to connect one client to another without having all data go through a server?). I know that you cant write files using JavaScript so I think the file thats being downloaded will either have to be saved completely in the memory, or the client will have to use one of the new APIs in HTML5 for storing content.

quilby
  • 3,141
  • 4
  • 26
  • 21

7 Answers7

33

No. It's not.

This is because the WebSocket specification falls outside of HTML5 and JavaScript ;-) That being said, opening up the question to "using features supported natively in [progressive/upcoming] browsers" then...

...still no :-)

This is because WebSocket requires a special handshake to setup with restrictions. It's not a free-for-all open-TCP-fest. The approach would require either

  1. clients to be modified to accept WebSocket requests (as well as dealing with any cross-site access issues)

  2. or, more realistically, a server to bounce through

  • 1. Will I be able to do this modification or will it have to be done by the developers of the browsers? 2. Will all information go through the server (as in every single bit of every file indexed by the tracker) or only the handshake? Thanks! – quilby Jan 23 '11 at 20:30
  • @quilby 1. The modification would need to be *per client accepting WebSocket requests* (read: *other torrent clients* -- there is "cross-domain" restrictions imposed, as with XHR etc., which would still render this approach unusable) 2) All information, possibly encrypted via TLS from *client to server* (but not from server to other clients). In addition, WebSocket does not establish a mechanism to accept incoming requests (although with the server in play lots of interesting things can be done). Some torrent clients will balk at not being able to make back-connections and refuse to even play. –  Jan 23 '11 at 21:00
  • @quilby Some torrent clients do support various encryption methods (on either the header or entire stream). This should not be taken as providing any sort of real privacy though and would just be *another* issue to deal with. –  Jan 23 '11 at 21:06
  • 2
    It seems this problem has been solved in recent browsers with support for WebRTC: https://github.com/feross/webtorrent – Laurent VB Oct 28 '14 at 16:31
18

There's a recent implementation based on WebRTC that works in node and the browser: https://github.com/feross/webtorrent

Laurent VB
  • 1,187
  • 9
  • 18
17

This is possible using Chrome Apps APIs: chrome.socket and chrome.fileSystem.

There is at least one pure JavaScript implementation for Google Chrome: JSTorrent.

Yahor
  • 639
  • 8
  • 16
10

There's no good reason why this can't be done today. BitTorrent/uTorrent both have code to support websocket connections with binary frames. However, they are currently compiled without support (due to political/product reasons I think). I used to work at BitTorrent and another engineer (Arty) wrote the support. For a while it was really cool being able to download torrents onto iPads from mobile Safari. (saving directly to Google Drive funnily enough)

HTTP trackers could be configured to send Access-Control-Allow-Origin headers.

Also the tracker announce protocol could use a bit in the "key" field to indicate that the client accepts websocket connections. Then a special argument like "typewant" could indicate that the announce response should only return clients who have sent that bit.

The tracker protocol could also be extended similarly to support negotiation of WebRTC P2P DataChannel connections, so that connections could be made directly browser<->browser.

For now, we have the chrome.socket platform API, and jstorrent, a chrome packaged app (designed for ChromeOS mainly)

kzahel
  • 2,765
  • 1
  • 22
  • 31
9

You can't with WebSockets because those are strictly client-server. But the upcoming WebRTC standard, while being mostly targeted at audio/video conferencing, has a provision for generic client-client data transfers. If this provision makes it to the final version, then you'll have a viable way to implement generic peer-to-peer data transfers between browsers.

CAFxX
  • 28,060
  • 6
  • 41
  • 66
4

A few:

https://github.com/superafroman/node-torrent

https://github.com/deoxxa/bittorrent.js

jkeogh
  • 49
  • 1
  • 3
    how is it possible that these lib's exists event though the answers above state that it is impossible to build it ? Edit: i guess it's because they depend on node.js and that can't run client side in the browser (nativly) ... – Nick Russler Nov 26 '12 at 13:28
  • It's because these are web browser torrent clients, they are node (server side Javascript) scripts. – adalal Jun 15 '16 at 23:01
4

I'm late to the party, but since this question is still among the top on Google's results, I'll answer anyway.

You may write BitTorrent-related web apps or browser extensions with Btapp.js, which uses a Javascript interface provided by BitTorrent Torque. When you call the connect method, the user will be prompted to install BitTorrent Torque, that's all. Some cool stuff going on if you check out existing projects using it—streaming media, drag-and-drop sharing, etc.

As for solutions without any dependency, the ones mentioned by Nick Russler still seem to be the only feasible options.

Daniel Nordström
  • 41
  • 4