I don't know whether you can establish a WebSocket connection in a service worker. This might be interesting as inactive/background tabs do throttle the transfer right now.
I might consider introducing a service worker for PWA functionality though.
@rysiek @fribbledom I'm not to deep into the BitTorrent protocol. All I know is, the initial seeder keeps the file(s) in memory and creates a metadata (.torrent file -> infohash) files which is (temporarily) registered on the public tracker via WebSocket connection.
Other peers connect to the tracker as well via the infohash. STUN server allow a direct connection between those peers (with WebRTC I guess).
@rysiek looks like the newest webkit is supporting transferring RTCDataChannel to a service worker: https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned although I imagine that’s not very useful atm, since other browsers completely lack support, and RTC connections cannot be created in the worker itself at any case
you’re probably already familiar with the relevant webrtc issue: https://github.com/w3c/webrtc-pc/issues/230 which explicitly highlights peer-to-peer content delivery as a use-case. interestingly, the last comment says that transferring to a service worker is not yet implemented even in safari, but things seem to have changed since then according to wpt
unfortunately, google seems to have blessed their http3-only webtransport https://web.dev/webtransport/#is-webtransport-an-alternative-to-webrtc-data-channels as a way to open datagram connections in workers, which doesn’t support peer-to-peer connections at all. so I wouldn’t hold my breath for service worker webrtc support in chrome
@rysiek btw, this is a bit silly, but could a service worker just use
sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?
this idea comes from the fact that the current API (as implemented by Safari) needs a webpage to establish the RTC channel, which then gets sent to the worker (and probably only lives as long as the page is open). so in practice, the worker first has to serve some kind of shim webpage and script, which establishes the channel and sends in to the worker – then the worker could use the channel to answer further requests
so the silly thing to do would be to (in absence of RTC channel transfer support) establish the channel in the shim webpage, and notify the worker of this fact via a message. subsequently, on any fetch request the worker would send a message to the webpage, and the webpage would answer with another message transferring some buffer with the request data. this is of course completely backwards, but
FetchEvent.respondWith does take any promise, and
Response objects can be created from scratch (albeit with some CORS caveats)…
@kristof @midzer @fribbledom
> btw, this is a bit silly, but could a service worker just use sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?
In general terms: sure, this is actually used by an js-ipfs example somewhere.
Specifically for my project: no, the point is to have a way to fetch content even before any HTML is loaded (provided that the SW has been installed before):