Add WebTorrent tracker and WebRTC peer support

[QuixThe2nd]

Summary

This adds optional WebTorrent support to rakshasa/libtorrent.

The implementation adds WebSocket tracker support, WebRTC DataChannel peer transport, and runtime capability/control APIs so clients such as rtorrent can detect and toggle WebTorrent support.

This is inspired by the WebTorrent support in arvidn/libtorrent, but implemented against rakshasa/libtorrent's tracker, peer, and protocol architecture rather than imported as a direct patch.

What Changed

• Add autotools support for WebTorrent:

  • --enable-webtorrent
  • --disable-webtorrent
  • WebTorrent is enabled by default at configure time when dependencies are available
  • clear configure errors when dependencies are missing and WebTorrent is enabled
  • USE_WEBTORRENT
  • LIBTORRENT_HAS_WEBTORRENT=1 in pkg-config cflags for consumers

• Add runtime WebTorrent capability/control APIs:

  • torrent::runtime::webtorrent_supported()
  • torrent::runtime::webtorrent_enabled()
  • torrent::runtime::set_webtorrent_enabled(bool)

• Add WebSocket tracker support:

  • TRACKER_WEBSOCKET
  • TrackerWebsocket
  • ws:// and wss:// tracker URL dispatch
  • WebTorrent announce JSON generation/parsing
  • offer/answer routing
  • tracker error/failure handling
  • tracker status integration through existing tracker state paths

• Add WebRTC DataChannel peer support:

  • webtorrent::RtcSignaling
  • webtorrent::DataChannelStream
  • webtorrent::PeerConnector
  • WebTorrent peers are promoted into the existing peer connection layer after signaling/handshake
  • BitTorrent piece/request/choke/message handling remains in the existing peer protocol machinery

• Add peer metadata for consumers:

  • WebTorrent peer flag exposed through peer/peer-info APIs

• Add tests for WebSocket tracker parsing/building/signaling behavior.

Dependencies

When WebTorrent is enabled, this expects system-installed dependencies:

• libdatachannel
• nlohmann_json

No vendored submodules are added.

Note for review: libdatachannel is documented upstream as MPL-2.0 licensed. Since rtorrent/libtorrent are GPLv2+, this should get an explicit compatibility review by maintainers/package maintainers.

Compatibility

Existing tracker behavior is unchanged for:

• http://
• https://
• udp://
• dht://

--disable-webtorrent builds do not require libdatachannel and continue to build/test without WebTorrent dependencies.

Testing

Tested locally on macOS:

• ./configure --enable-webtorrent

• make -j4

• make check

  • all 7 libtorrent test binaries passed

• ./configure --disable-webtorrent

• make -j4

• make check

  • all 7 libtorrent test binaries passed

End-to-end smoke tested with rtorrent built against this branch:

• rtorrent seeded a torrent containing a wss:// tracker
• browser WebTorrent client connected over WebRTC
• browser received the piece and completed the file

[rakshasa]

There's too much if/defs all over, just use a class with empty functions when not defined so the code looks clean.

And not seeing the reason why you're adding things to PeerConnectionBase, it should not be integrated with the code there.

[QuixThe2nd]

Thanks for the fast feedback @rakshasa

I'll move the WebRTC/DataChannel path behind a generic peer transport adapter, so PeerConnectionBase only talks to a transport interface and no longer owns WebTorrent-specific state or init.

I’ll also replace the scattered USE_WEBTORRENT guards with disabled-build stub/no-op classes, keeping ifdefs only at the dependency/factory boundary where libdatachannel headers and implementation details are involved.

[QuixThe2nd]

I pushed a refactor that moves WebRTC/DataChannel I/O behind a generic peer transport adapter. PeerConnectionBase now only talks to the transport interface and no longer owns WebTorrent-specific state or initialization.

I also moved the disabled-build path to stubs/no-op classes where possible, leaving USE_WEBTORRENT guards around the libdatachannel-facing implementation boundary.

Verified:

• libtorrent WebTorrent-enabled build: make check
• libtorrent --disable-webtorrent build: make check
• rtorrent --enable-webtorrent build against this libtorrent branch: make check

[rakshasa]

To put you in the right direction; your code should not touch anything in src/protocol.

It should be a WebtorrentManager in src/protocol/webtorrent, providing a clean interface for downloads to request parts of a torrent be downloaded.

Easiest first step is to do it (a bit sub-optimally) by getting thread-net to grab your blocks of the torrent, and using the same mechanism that PeerConnectionLeech uses. (but not the same code/base-classes)

[QuixThe2nd]

Thanks, I pushed a rework in the direction you suggested.

The WebRTC/DataChannel path is no longer promoted into PeerConnectionBase / ConnectionList peers. It now goes through a download-owned WebtorrentManager under src/protocol/webtorrent.

That manager receives streams from WebSocket tracker signaling and uses download-layer state (ChunkSelector, TransferList, BlockList, ChunkList) to request/write blocks, without sharing the peer connection classes.