31–40 of 81 posts
Is this only possible if the server you are communicating with is setup to work with ff-proxy in the first place, I imagine? I can't just start using this and get no handshake confirmations from any website's rest api can I?
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. :)
"Zero Latency"?
* for sufficiently large values of zero
Earlier quoted context omitted.
You can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.
Wait webrtc uses udp? Is this new? I thought there was no way to send udp packets through client side Javascript?
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.
Finding a use case for this would be tricky... 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.
You can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.
Can you imagine the amount of bandwidth saved around the world in aggregate?
TCP should be restricted based on content classification.
Finding a use case for this would be tricky... 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.
You can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.
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
"Zero Latency"?
They've basically discovered TCP Performance Enhancing Proxies, used for decades for space communications.