Repository navigation
Webtorrent support #138
Description
Does this client by any chance support webtorrent?
If no, anyone know of a go torrent solution that does?
thanks!
IssueHunt Summary
anacrolix has been rewarded.
Backers (Total: $250.00)
steelbrain ($50.00)
- $200.00 have been anonymously funded.
Submitted pull Requests
Tips
- Checkout the Issuehunt explorer to discover more funded issues.
- Need some help from other developers? Add your repositories on IssueHunt to raise funds.
IssueHunt has been backed by the following sponsors. Become a sponsor
Reacted by Peter Grassberger, Jaime Pillora, Hosh, Jimmy Wärting, Paul Waldmann, David LOIRET, lypwig, Vladislavik, Eugene Manaev and Florian Hermouet Joscht
Reacted by Matt Joiner
Activity
anacrolix commentedon Dec 12, 2016
Do you refer to https://github.com/feross/webtorrent ? Can you link to a spec on bittorrent clients interacting with webrtc clients?
faddat commentedon Dec 15, 2016
Not offhand, but I'm happy to google for it....
To leverage existing WebRTC implementations a dedicated instance of a Chromium browser is used. This 'bridge' mediates communication between Vuze and WebTorrent peers.
For the original implementation see https://webtorrent.io/
....ouch.
Maybe I can find better in the node.js?
anacrolix commentedon Dec 19, 2016
That's as much as I found. If you found specifics in the node.js code, that may expedite adding support for this.
faddat commentedon Jan 2, 2017
@feross
feross commentedon Jan 21, 2017
Hey! We'd love to help make WebTorrent support happen here. We're working on a spec. I'll share here when it's complete. At the moment you can check out the following files, to see what's going on:
To sum up what it would take to support this:
When a
ws://orwss://tracker is detected, create a websocket connection to that server. There are a few extra announce message types to facilitate establishing webrtc connections"offer"and"answer", but everything else is essentially the same.Once connected to a peer over WebRTC, you can treat the remote peer exactly the same -- the wire protocol is exactly the same.
faddat commentedon Feb 7, 2017
Referenced in:
https://github.com/dawn-network/glogchain/issues/#10
https://github.com/dawn-network/glogchain/issues/#11
mattlepacek commentedon Apr 17, 2017
Webtorrent support here would be amazing. The current node.js implementations are limited by chromes implementation of webrtc causing cpu time to multiply with each torrent being seeded. I'm interested in sponsoring Webtorrent support
anacrolix commentedon Apr 21, 2017
I'll revisit this when there's a spec.
KeizerDev commentedon Jun 1, 2017
anacrolix commentedon Jun 2, 2017
No progress. There's no spec, and WebRTC is abysmal to work with.
Sean-Der commentedon Jul 7, 2018
Hey @anacrolix !
I have been working on Go native WebRTC https://github.com/pions/webrtc and would love to get it to the point that you could use it!
It currently has full support for Audio/Video (send and recv) and I am maybe two weeks out from finishing DataChannels. We have ~5 developers involved, so things are moving pretty quick! If you are interested would love to chat/figure out what is most important to you. All the devs are on the Gophers slack in the #pion channel
anacrolix commentedon Jul 7, 2018
That sounds great @Sean-Der . I'm guessing WebRTC is not so simple as a stream of bytes, when data-channels are ready we can look at integrating those. Specifically dial/accept interfaces are required, and a way to send/receive bytes. A spec on how the peer protocol operates over WebRTC is still required.
Unrelated, there was a comment earlier about websocket trackers, I've yet to see any in the wild. Some examples of those will be helpful. Implementing those should be very easy.
jimmywarting commentedon Jul 23, 2018
anacrolix commentedon Jul 24, 2018
Sean-Der commentedon Jul 24, 2018
40 remaining items
anacrolix commentedon Feb 25, 2020
The Dialer and Listener interfaces have been abstracted out in #380, which is the first step toward implementing this. I've created https://github.com/anacrolix/torrent/milestone/2 to track any issues and PRs that progress this issue.
Sean-Der commentedon Mar 18, 2020
Anything I can do to help @anacrolix ? Happy to get involved with any of the WebRTC stuff.
anacrolix commentedon Mar 19, 2020
@Sean-Der I've created issues the next 2 items we need. I think it may be possible to do them concurrently, so long as the
addr stringis agreed upon by the tracker and Dialer implementations. See those issues for more information. I've not had time myself to progress further yet due to work and other constraints.anacrolix commentedon Apr 5, 2020
I did some more investigating. This looks exceptionally difficult to integrate into the existing code. The tracker and connection management are tightly coupled. It's also probably not appropriate just to maintain state at the Torrent level for trackers, it might be necessary at the Client level in order to scale to many Torrents with the same tracker URLs specified. The potential for disconnection from the trackers is a real kicker, I think there will be need to be many events flowing around the system.
backkem commentedon Apr 5, 2020
I think disconnecting form the tracker isn't the end of the world. Once established, the WebRTC connections don't need the tracker's Websocket connection to stay alive.
However, losing the connection before signaling is complete does mean you won't be able to complete the setup of a WebRTC connection.
Managing the tracker Websocket connections globally is probably a good idea since they will have more overhead than regular UDP ones.
backkem commentedon Apr 5, 2020
The WebRTC connection setup is likely even more tricky. Normally WebRTC will allocate random ports for both sides of the connection. In addition, there are two steps: signaling (tracker) and the actual connections (torrent). This would require a bunch of back-and-fort between the tracker and connection logic and it's quite inefficient for this use-case.
However, unlike in the browser we have more control over the network stack. You could potentially address these downsides as follows:
This would mean:
The pion/webrtc library should be flexible enough to make this happen.
anacrolix commentedon Apr 7, 2020
Thanks for the assistance again @backkem. I have a in-progress branch at https://github.com/anacrolix/torrent/tree/webtorrent that's able to download. Within the
torrentrepo, you can test it withGOPPROF=http go run -race -v ./cmd/torrent -dht=false 'magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10&dn=Sintel&tr=wss://tracker.btorrent.xyz&tr=wss://tracker.fastcast.nz&tr=wss://tracker.openwebtorrent.com'. It's very rough for now, but I'll continue to mold it to thetorrentarchitecture, and take suggestions and improvements from people more familiar with WebRTC and webtorrent.anacrolix commentedon Apr 13, 2020
That command is now
$ GOPPROF=http go run -v ./cmd/torrent download -dht=false -tcpPeers=false -utpPeers=false 'magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10&dn=Sintel&tr=wss://tracker.btorrent.xyz&tr=wss://tracker.fastcast.nz&tr=wss://tracker.openwebtorrent.com'.issuehunt-oss commentedon Apr 15, 2020
@anacrolix has rewarded $225.00 to @anacrolix. See it on IssueHunt
anacrolix commentedon Apr 15, 2020
I'm closing this as done. There are further improvements to be made, but now that Webtorrent is supported on master, those will come over time.
jpillora commentedon Apr 16, 2020