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?
Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
11–20 of 81 posts
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#12WOW. This is such a fascinating project. (near) zero latencies are relatively hard to achieve especially over network connections. Will definitely try this out once I get the time. Oh and thanks for the various pre-built client libraries, will definitely come in useful.
Using the term "zero" is not the best choice. UDP packets have the same latency as TCP packets, you're just saving the handshake. Games and VoIP still have latency, they're usually structured such the data loss and duplicate responses are normal and handled appropriately.
You're also saving the time of network latency and waiting for a response. With the proxy, once the packets are out on the network, you're done and can move on.
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#13Finding 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.
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#14Earlier quoted context omitted.
Using the term "zero" is not the best choice. UDP packets have the same latency as TCP packets, you're just saving the handshake. Games and VoIP still have latency, they're usually structured such the data loss and duplicate responses are normal and handled appropriately.
You're also saving the time of network latency and waiting for a response. With the proxy, once the packets are out on the network, you're done and can move on.
That's also true in Games and VoIP, only things that need to be reliable have acks for them.
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#15What would be the use case of this versus say making an HTTP request over TCP in a background thread?
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#16Finding 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.
> Finding a use case for this would be tricky...
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.
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#17Good stuff. Could use some asserts and checks for NULL here and there, but overall it's a nicely organized C code (and with proper bracing and indentation style :)). Always a pleasure to read through something like this.
Actually it has the wrong indentation style. Should be tabs left spaces right. I run tab width of 3 in my editors. To each their own, if you use tabs left of course.
Well then you're also "wrong" for 3 spaces. Student project, and spaces/tabs argument is for teenagers.
edit: root comment here is mentioning NULL checks and actually being helpful
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#18"Zero Latency"?
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#19"Zero Latency"?
Didn't even read it after seeing that in the headline
Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency
#20Finding 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.
Wait webrtc uses udp? Is this new? I thought there was no way to send udp packets through client side Javascript?