目前，我正在调查是否可以使用WebAssembly的BitTorrent协议。
众所周知，浏览器本身具有限制，我们不能使用纯TCP/UDP套接字，因此UDP连接由WebSocket模拟。
我还发现，WebAssembly的emscripten工具链使我们能够使用
它说
由于所有API调用都是单独代理的，因此此支持可能会很慢。这种支持主要用于开发测试基础架构和调试。
问题
该功能可以用于在WebAssembly中实现BitTorrent协议支持吗？
是否有更多可靠的方法来实施协议？
准备好生产它是“接近思想”吗？
最后
甚至可能？
Currently I'm investigating if it is possible to use BitTorrent protocol from WebAssembly.
As I know browser itself has limitation and we cannot use pure TCP/UDP Socket, so UDP connections are emulated by WebSockets.
Also I found out that there's Emscripten toolchains for webassembly that allows us to use Full POSIX Sockets over WebSocket Proxy Server
It says
Because all API calls are individually proxied, this support can be slow. This support is mostly useful for developing testing infrastructure and debugging.
Questions
Can that functionality be used for implementing BitTorrent protocol support in WebAssembly?
Are there more reliable ways for implementing the protocol?
Is it "close to the mind" to have it production ready?
and finally
Is it even possible?
发布评论
评论（1）
由于规格要求TCP需要TCP，因此无法在浏览器中实现 bittorrent 或UTP作为运输。 webtorrent 确实可以通过webrtc操作对等协议洪流规格，现有跟踪器，DHT和各种其他扩展。
WebTorrent的另一个问题是，当客户使用长寿的背景服务时，洪流效果最好，因此他们可以在上传中占有一定份额并确保长期的内容可用性。但是网站通常以较短的寿命标签运行。对于我的知识工作人员而言，在这里也无济于事，因为当依靠它们的标签被关闭时，他们会被暂停，即他们没有提供长期寿命的背景服务。
而且我怀疑由于浏览器安全策略而导致文件系统访问周围的其他问题/缺乏功能。例如，从一个本地客户端迁移到另一个客户端时，您通常可以告诉他们扫描整个文件系统中的文件，以匹配您要重新运动的洪流。
因此，一般原则是可能的，但它与适当的Bittorrent实施所能做到的那样。
另请注意，WASM不必运行浏览器，有一些WebAssembly Runtimes旨在提供系统访问，例如 wasi 或运行 nodejs in nodejs 。使用这些可以使用TCP和UDP，并具有适当的Bittorrent实现。
Implementing BitTorrent in a browser is not possible because the specification requires TCP or uTP as transport. Webtorrent does operate the peer protocol over webrtc, but it's not spec-compliant because it can't talk to clients implementing the torrent spec, existing trackers, the DHT and various other extensions.
Another issue with webtorrent is that torrents work best when clients operate as long-lived background services so they can do their fair share of uploading and ensure long-term content availability. But websites generally operate in shorter-lived tabs. To my knowledge ServiceWorkers do not help here either because they get suspended when the tabs relying on them get closed, i.e. they don't provide a long-lived background service.
And I suspect that there are other issues/lacking features around filesystem access due to browser security policies. E.g. when migrating from one native client to another you can often tell them to scan the whole filesystem for files matching a torrent that you're reimporting.
So, the general principle is possible, but it falls way short of what a proper bittorrent implementation can do.
Also note that wasm does not have to run a browser, there are webassembly runtimes that aim to provide system-access, e.g. WASI or running webassembly in nodejs. With those you can use TCP and UDP and have a proper bittorrent implementation.