@KentonVarda when will we be able to read/write websockets (within workers), and not just proxy them? We also need UDP support from the workers. With UDP support I can take advantage of sendmmsg/recvmmsg or specialized kernel bypass nics within my backend.
There are two tricky questions to answer with WebSocket support:
What’s the API? Service Workers in the browser today actually can’t intercept WebSockets, and so there’s no standard API defined for doing so. We’ll need to make up something new, hopefully with some chance that it will be accepted into the standard later.
How should WebSockets affect the per-request CPU time limit? Is a whole WebSocket just one request, with the same CPU limit as any other? Or do we treat it as multiple requests (and bill accordingly)?
I can’t make any firm promises, but I would expect WebSocket termination support to show up in the next month or two, but probably treated as a single request with a single CPU time limit. From there we’ll have to see in practice whether changes to the time limits are needed.
Wouldn’t it be better to leave websocket open and bill max(bandwidth, time) per minute?
@jdavis Workers are billed on number of “requests”, not on bandwidth nor CPU time. I don’t think we’d want to add CPU or bandwidth metering that applies only to WebSocket. So we need to turn WebSockets into “requests” somehow…
Wasted effort, probably best to just forget websockets in that case. Maybe push this effort into TCP anything?
I think we can find a reasonable way to count WebSockets as requests for billing purposes.
So we’re talking about being able to keep websockets open for an extended period of time? If not, what’s the point?
On another note, when is CloudFlare going to purchase ZeroTier and use it’s kernel-bypass expertise to make ZT run screaming fast? In addition, making ZT run within websocket framing on 443 would also be quite disruptive.