* I presume the case here is the proxy is close to the server so the handshake is faster and thus the single benefit of this setup, although that's not at all what's illustrated.
* The illustrations show the request taking longer with the proxy, although maybe the two diagrams aren't to scale
* The originating UDP packet could get lost and the client would never know
The author could improve the latency by prepping the TCP connection before the request comes in, giving a significant reduction in latency.
And yes, you get no confirmation, and no reply.
I must admit I'm hard pressed to come up with a use case for this. You could just as easily do a regular HTTP request on a separate thread and throw away the result to get "zero latency" fire-and-forget behavior.
I do this quite often, and creating another thread might be easy to code, but it's harder on capacity planning and management. It's also hard to gossip utilisation of a shared network link across a cluster, so e.g. if requests are infrequently sourced, I may want to permit a pool of 500k concurrent output HTTP requests across the entire cluster, but I don't want to give every machine a mere 10k outgoing since busy endpoints would be starved by unbusy ones (and my network link would have plenty of spare capacity). Managing all that could be a full time job if I went down the "easy" path of just creating another thread.
Using UDP means if there is network congestion, messages just get dropped and I don't waste more network and CPU traffic by sending retransmits. I have retries further up the chain anyway for other reasons, so it makes sense to me to have less code and reuse what I've already got.
Logging/analytics?
Quic already does this end to end.
The only use case I can think of might be gaming. If you had a HTTP/Websockets based game you wanted to cut latency down on you could have the FF proxy hosted near the game server.
I can tell you a real life use case that already exists because I built this exact thing already (though a closed-source version): satellite internet terminals.
With satellite internet, uplink (upload) is generally more complicated than downlink (download). This is because a terminal can just passively listen for packets intended for him, but with uplink you have to make sure you only transmit in your designated time slot.
Because uplink is more complicated than downlink, more often than not uplink will get in a degraded or broken state, while downlink is still operational.
Now say I get a call from a customer service rep saying a customer's terminal is stuck in a degraded state. How can I recover it? TCP (and therefore HTTP) is a no-go because it requires uplink to be fully functional. So I can't visit the terminal's embedded webserver or issue commands to the HTTP API.
However, using a udp to tcp proxy like this, I can issue commands to the terminal's HTTP API "blindly" which it will then execute to (hopefully) recover itself. This can also be done with other "one-way" protocols like SNMP.
I don't mean to sound smug, but I'm the author of the Jackbox Games multiplayer servers, I regularly handle hundreds of thousands of simultaneous websocket connections from players' phones. I can't for the life of me find a server implementation of webrtc data channels that I would actually put into production. I've seen a few blog posts with toy examples, but nothing that is ready for production. It sounds nice in theory, but try actually finding a production-ready server implementation of WebRTC data channels. I would LOVE to find a documented example of doing client-server communication with WebRTC data channels (a Go implementation on the server specifically). I've found no such thing. Every few months I search and don't find such a thing, and I don't need the extra few ms of latency improvement badly enough that it would be worth the engineering time to author it myself. If you know of one that's actually ready for primetime, I'd love to hear about it.
edit: after writing this comment, I did some snooping around since I haven't snooped around on this topic in a few months, this looks promising, unclear how widely used people are using it for production work: https://github.com/pion/webrtc
If the service you are sending data to is unavailable, you wouldn't get any backpressure from it.
Think of a monitoring or log system where you might want to send out millions of datapoints but you can afford to lose some, in return you don't have to worry about the system not being reachable.
I can only see being interesting if you have a workload which requires sending small requests that fit into one or a couple of datagrams.
Fire and forget logging to HTTP endpoints would be pretty useful for IoT sensors. You'd have a lot less code and could potentially save significant power. You obviously lose the ability to guarantee data arrived, but that's probably not important for all sensor situations.
It's even possible to translate CoAP directly into HTTP using a proxy such as Squid.
There's also MQTT, which was basically designed for IoT sensor reporting. This has even more supported libraries and has been around for ages.
The UDP proxy system has the benefit of not being able to fall victim to classic UDP amplification vulnerabilities (send a packet with a spoofed source and have the response bounce back), but it does allow an unsuspecting proxy server to turn into a HTTP-based DDoS. You can send a single packet towards a server and the server automatically does a full TCP handshake and payload delivery for you! That's a lot of extra traffic.
I'd stick with known protocols for IoT stuff instead of this. At least the risks have been analysed and firewalls can (should) be easily configurable to block outgoing DDoS attacks in the worst case. The same is not really true for this.
It will basically require another framing protocol on top of TCP to make it even remotely usable.
edit: root comment here is mentioning NULL checks and actually being helpful
That’s certainly a strange choice, but you do you I guess…
P.S. good to see the comment, "TODO: filter out private IP ranges". I was going to suggest this but it seems you already know. :)
* for sufficiently large values of zero
They've basically discovered TCP Performance Enhancing Proxies, used for decades for space communications.
The claim seems correct with those caveats, though is a bit "click baity" without them.
I wonder if it would be worth making this embeddable into an existing web framework for Python or Go, so that the existing service could receive UDP requests. Then again, that's what 0RTT is for so it might be a little wheel-reinventy.
Games and VoIP still have latency, they're usually structured such the data loss and duplicate responses are normal and handled appropriately.
I can't just start using this and get no handshake confirmations from any website's rest api can I?
> Docker
- Reliable delivery
- Ordering
- Congestion control
- Flow control
...and a large list of RFCs that I'll never ever read.
If you are delivering a document (like a webpage or an API response), or transferring files, you want these things.
If you are doing real-time stuff, like video, voice, real-time games... and you just need the most recent information, that's where UDP shines.
Can you imagine the amount of bandwidth saved around the world in aggregate?
TCP should be restricted based on content classification.
If you handle the SDP and SCTP handshake you can force it to only use UDP via SCTP. Chrome and FF both support it today.
It's just -- and this may be mildly out of date -- EXTREMELY hard to find a server-side setup that will let you do all of what the browsers now support with WebRTC.
My recollection from the last time I skipped across this topic was: there are 1 or 2 heavyweight open source projects that mostly focus on the video aspects but also supported data channel stuff, and then one lightweight C and one lightweight Go project that supported everything, and you were mostly out of luck otherwise.
I remember the last time I checked, a year ago or so, pieces of what's required being worked on in recent OTP releases in BEAM-land. Hmmm ... time to check again.
Unless it's a mass issue across a whole beam, it usually requires some investigation to figure out why an individual terminal state is degraded. And sometimes (more than I'm comfortable with) during the course of your investigation you make the terminal state even worse (because you tweaked some config parameter the wrong way). You can always tell when you done messed up because suddenly you get disconnected from your ssh session or you can no longer reach the embedded web server from your browser. In those cases sometimes the only way to recover is to precisely undo what you did, and an auto-ping-reset will not fix it (unless the system keeps track of most recent config changes or something). Your options are: use udp/tcp proxy or snmp to attempt to undo the config parameter you foobared or send out a technician and fix it on site...
I'm not saying our system is perfect. Surely we could improve fault detection and recovery. I'm just saying one-way communication protocols are real nice to have sometimes because of these scenarios.
( yes, I know that's a terrestrial, microwave relay dish and not a satellite antenna, but it could happen.)
I think it is a valid claim, but only for a rare set of use cases where the significant caveats regarding delivery & response are OK. Though of course those caveats are not as heavy as they might at first seem if the link between client and proxy is strong and reliable, because the proxy will be performing the full handshake and can manage redeliver on error and other such things - but the client doesn't need to worry about any of that.
I got it working far enough to handle the WebRTC handshake over SCTP and get some basic data flowing. It's still in pretty rough shape and ran out of time to document it to any degree where someone else could take it and run with it.
If there's enough interest I might pick it up again but right now I've got other priorities going on.
I'm actually a little surprised the Jackbox games aren't monetized differently. They cost so little up front and that CPU time can't be free.
Just today I set up my wife's laptop with Drawful 2 and Jackbox 6 so she can play with her coworkers tomorrow. Thanks!
I have, but I didn't use go. I wrote a webrtc server in C, and probably handled something north of a trillion event points per month this way (receiving telemetry from interactive digital advertisements).
My goal wasn't latency but capacity: I can handle maybe 100kqps in HTTP on the same kit that could handle something like 600kqps+ messages with this (Never did proper limit testing here, since I knew my supplier was limited on the network links). It took about three weeks to get operational to a point it could be added to production, which was worth it to me.