5 ms·

> Can we expect in Workers Unbound support for Websockets, WebRTC, HTTP Connect, and Server Sent Events? Definitely yes on WebSocket. In fact, the only reason

> Can we expect in Workers Unbound support for Websockets, WebRTC, HTTP Connect, and Server Sent Events? Definitely yes on WebSocket. In fact, the only reason we haven't rolled out WebSocket support already is because it's not very useful without long-running CPU. Workers Unbound fixes that so I'll be dusting off my old WebSocket implementation PR soon. I think Server Sent Events are just streaming HTTP? That should work today (but with the same caveat that CPU limits may cause trouble). WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea. By "HTTP connect", I assume you mean the CONNECT HTTP method, usually used to tunnel TLS connections through forward proxies? That's a request I haven't heard before, but it's interesting. I guess what you'd get, basically, is the ability to establish TCP-like connections that are addressed to HTTP URLs and connect over port 80/443? Is this commonly used for things other than forward proxies? > Would there be support for protocols other than HTTP? Say, a raw TCP / UDP connection that is handed off by Spectrum to a Worker [1]? Not part of the current plan but definitely something we'd like to do eventually. > Inability to rate limit Workers in a cost effective way gives me sleepless nights Yeah, our rate limiting product is not really intended to be used to rate-limit the whole site to control costs. It is more intended to, say, rate-limit your login form to prevent brute-force password guessing. That said, we do have layer 7 DDoS protections, and those run in front of your worker. If an attack gets past them and hits your worker, I'd encourage you to raise a support ticket asking for compensation for the attack traffic that we failed to block. I am not personally in a position to promise that we'd refund you but I believe it has happened in the past. > Will the same isolate (Unbounded Worker), if kept running for long, be able to handle multiple connections/requests concurrently, JavaScript is inherently single-threaded, so an isolate can only be executing code on behalf of one request at a time. That said, it is already the case that multiple concurrent requests may be handled by the same isolate (one request may be executing while another is e.g. waiting for a response from a remote server). But today you can't really take advantage of that, because you have no control over exactly which isolate receives any particular request, no any way to communicate between neighboring isolates. This is definitely something we're working on but nothing to announce at this time.

ignoramous 6y ago
Thanks a lot Kenton. Appreciate the reply and excited to see what the Workers team build next. > WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea. The reason I asked is, since overlay distributed networks are being built on top of WebRTC (like u/feross' https://WebTorrent.io https://WebTorrent.io), Workers Unbound, if it supported WebRTC, could potentially then be a participant in such distributed networks. May be, I can seed torrents through Workers Unbound or build a P2P CDN on top of it which is at least as fast as usual CDNs when there are not very many connectable peers nearby. Or, have Workers Unbound participate as a host in a P2P database / filesystem like GunDB [0], for example. > Is this commonly used for things other than forward proxies? Yep, pretty much the use-case I was going for with Workers Unbound, tunneling traffic through HTTP to bypass firewalls and navigate NATs. A TURN over HTTPS of sorts, like Tailscale's DERP [1] but with servers worldwide. Will this be supported out-of-the-box? Thanks again! [0] https://github.com/amark/gun https://github.com/amark/gun [1] https://tailscale.com/blog/how-tailscale-works/ https://tailscale.com/blog/how-tailscale-works/
- kentonv 6y ago
  At present we don't have any specific plans around WebRTC or HTTP CONNECT, but I'll keep those in mind. It might be easy to support CONNECT if/when we support raw TCP; it'd just be another entry point to the same subsystem. WebRTC would take a lot more effort. If you can manage to tunnel over WebSocket, though, that'll be supported a lot sooner.
jbergstroem 6y ago
> JavaScript is inherently single-threaded, so an isolate can only be executing code on behalf of one request at a time. That said, it is already the case that multiple concurrent requests may be handled by the same isolate (one request may be executing while another is e.g. waiting for a response from a remote server). But today you can't really take advantage of that, because you have no control over exactly which isolate receives any particular request, no any way to communicate between neighboring isolates. This is definitely something we're working on but nothing to announce at this time. I've seen this used in a few contexts, for instance batching requests to a origin (logflare: https://github.com/Logflare/cloudflare-app/blob/master/workers/worker.js https://github.com/Logflare/cloudflare-app/blob/master/worke...). Is this generally seen as ok? I'm planning on building similar things for sending page metrics in parallel to serving traffic. > > Inability to rate limit Workers in a cost effective way gives me sleepless nights Agreed, there is something very challenging with the current design of how requests flow through cloudflare. I have played around with dynamic rules in firewall by manually handling "firewall rules" in a worker as part of a request flow and using KV to share this state. I would then update the cloudflare firewall with api. I had to create a separate service to poll both API and KV to maintain them though.

ignoramous 6y ago

Thanks a lot Kenton. Appreciate the reply and excited to see what the Workers team build next. > WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea. The reason I asked is, since overlay distributed networks are being built on top of WebRTC (like u/feross' https://WebTorrent.io https://WebTorrent.io), Workers Unbound, if it supported WebRTC, could potentially then be a participant in such distributed networks. May be, I can seed torrents through Workers Unbound or build a P2P CDN on top of it which is at least as fast as usual CDNs when there are not very many connectable peers nearby. Or, have Workers Unbound participate as a host in a P2P database / filesystem like GunDB [0], for example. > Is this commonly used for things other than forward proxies? Yep, pretty much the use-case I was going for with Workers Unbound, tunneling traffic through HTTP to bypass firewalls and navigate NATs. A TURN over HTTPS of sorts, like Tailscale's DERP [1] but with servers worldwide. Will this be supported out-of-the-box? Thanks again! [0] https://github.com/amark/gun https://github.com/amark/gun [1] https://tailscale.com/blog/how-tailscale-works/ https://tailscale.com/blog/how-tailscale-works/

kentonv 6y ago
At present we don't have any specific plans around WebRTC or HTTP CONNECT, but I'll keep those in mind. It might be easy to support CONNECT if/when we support raw TCP; it'd just be another entry point to the same subsystem. WebRTC would take a lot more effort. If you can manage to tunnel over WebSocket, though, that'll be supported a lot sooner.

jbergstroem 6y ago

> JavaScript is inherently single-threaded, so an isolate can only be executing code on behalf of one request at a time. That said, it is already the case that multiple concurrent requests may be handled by the same isolate (one request may be executing while another is e.g. waiting for a response from a remote server). But today you can't really take advantage of that, because you have no control over exactly which isolate receives any particular request, no any way to communicate between neighboring isolates. This is definitely something we're working on but nothing to announce at this time. I've seen this used in a few contexts, for instance batching requests to a origin (logflare: https://github.com/Logflare/cloudflare-app/blob/master/workers/worker.js https://github.com/Logflare/cloudflare-app/blob/master/worke...). Is this generally seen as ok? I'm planning on building similar things for sending page metrics in parallel to serving traffic. > > Inability to rate limit Workers in a cost effective way gives me sleepless nights Agreed, there is something very challenging with the current design of how requests flow through cloudflare. I have played around with dynamic rules in firewall by manually handling "firewall rules" in a worker as part of a request flow and using KV to share this state. I would then update the cloudflare firewall with api. I had to create a separate service to poll both API and KV to maintain them though.