WEBTORRENT ALTERNATIVES HOW TO
Anyhow, no one contacted me on how to use it for WebTorrent or to provide feedback. Okay, granted, I have not posted that in this particular issue but I did in the libtorrent issue. I've offered RAWRTC which aims to be easy to use.
Here are the two arguments I've seen (let me know if there is something I've overseen): 1. But then it would probably still make more sense to wait for QUIC in WebRTC and see if that's any better before jumping onto Sure I read the whole thread. In the end, you may still conclude that WebRTC data channels are insufficient for whatever reason. But it will not if we keep away from it because of bugs. However, the lack of interest or priority may change if we keep using it and WebTorrent becomes more popular.
At the moment, none of the browser vendors seem to have an interest in resolving such issues. But you have a point regarding CPU usage which hasn't been investigated thoroughly yet, see sctplab/usrsctp#245. The way Jitsi Meet delivers video streams is entirely different to the way PeerTube does. And frankly, WebRTC A/V is very different to WebRTC data channels. You're applying your experience with one particular application (PeerTube), for one specific implementation, on your specific device onto a whole technology.
WEBTORRENT ALTERNATIVES MANUAL
And I'm sorry, but WebSocket with manual hole punching on one side and the workaround to get around the insecure origin problem on the other side is, from an application perspective, more complex than WebRTC on both sides and thereby loses its elegance (which it undoubtedly has, but not in a P2P environment). (I originally brainstormed this idea with and I was inspired by work on One person said that. But if a desktop client does not want to support WebRTC (understandably), then they can still provide value to browser peers by running a WebSocket server to allow browser peers to initiate connections to them. Browser to browser connections, as well as desktop to browser connections would continue to require WebRTC.It's just a DNS server that maps to the IP address 12.34.56.78. They're generic and have nothing to do with the BitTorrent protocol, so it's likely risk-free to just run one of these as a public service, not unlike a DHT bootstrap node. Anyone could run one of these "force TLS" services cheaply. This is just a hack to help secure origins ( connect to WebSocket servers running in desktop peers without requiring those desktop peers to buy a domain name and get a TLS certificate that is trusted by the browser peers' browsers.ģe. So, in this system, TLS isn't actually being used for security.
WEBTORRENT ALTERNATIVES TORRENT
The secret key for this certificate would be public and any torrent app could use it in their WebSocket server.ģd. The domain would use wildcard certificate to ensure that all of these domains are signed. So the DNS for would resolve to 12.34.56.78. The domain would have DNS set up to return whatever IP is passed in the subdomain. Say a user on a secure web origin wants to connect to a desktop peer at 12.34.56.78. However that requires the WebSocket server to have a domain name and a certificate signed by a CA.
One complication is that the browser blocks connections to insecure origins ( ws://) from secure origins ( So ws:// can't be used all of the time. Browser peers connect to desktop peers using WebSocket using an address like ws://12.34.56.78 when possible.ģb. Here's a rough sketch.ĭesktop peers would run a WebSocket server and do whatever NAT hole punching they normally do (UPnP, NAT-PMP, tell the user to set up static port mapping, or just hope that the user has a public IP).īrowser peers would discover desktop peers through normal means, so probably trackers and PEX for now (and eventually we could extend the DHT to support WebSocket in addition to UDP).ģa. It's probably possible to make something work over WebSockets. See transmission/transmission#47, for example. This is slowing WebTorrent adoption in traditional desktop torrent clients. Lots of torrent clients can't add WebRTC support because the protocol is too complicated and difficult to integrate.
0 kommentar(er)
