Live data from Hacker News

Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

github.com

21–30 of 81 posts

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#22

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?

Yup, it's been a while since I read the spec but I believe it leaves the transport up to what can be negotiated for maximum compatibility.

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.

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#24

"Zero Latency"?

Didn't even read it after seeing that in the headline

"I didn't bother to listen, but I think it is wrong so there" is never really a useful discussion position.

The linked page describes a fairly specific set of needs that the claim is effectively true for, though only from the client's point of view.

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#26

"Zero Latency"?

Yes, but only for a specific set of circumstances (when you can live without reliable & timely delivery, and do not need any sort of response) and only from the PoV of the client.

The claim seems correct with those caveats, though is a bit "click baity" without them.

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#27

What would be the use case of this versus say making an HTTP request over TCP in a background thread?

Well obviously you don't need to maintain a background thread and a connection so you would be able to send out much more data using the same resources by offloading the TCP workload to the proxy.

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.

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#28
post #16
post #9

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.

> 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 ma…

Wow. I was literally about to reply with the same exact thing (built my own as well)! No value in this comment other than to validate your comment.

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#29

"Zero Latency"?

Yes, but only for a specific set of circumstances (when you can live without reliable & timely delivery, and do not need any sort of response) and only from the PoV of the client. The claim seems correct with those caveats, though is a bit "click baity" without them.

I don't see how the claim is technically correct in any way. Unless they've figured out how to circumvent the speed of light, there is no such thing as "zero latency."

Re: Show HN: A UDP to TCP proxy server for sending HTTP requests with zero latency

#30

Earlier quoted context omitted.

Yes, but only for a specific set of circumstances (when you can live without reliable & timely delivery, and do not need any sort of response) and only from the PoV of the client. The claim seems correct with those caveats, though is a bit "click baity" without them.

I don't see how the claim is technically correct in any way. Unless they've figured out how to circumvent the speed of light, there is no such thing as "zero latency."

The client just jets out a single UDP packet. There is no TCP setup latency, effectively no latency at all though only from that client's point of view.

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.

Post reply on HN