Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 81 posts

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

#41

Post by ycombobreaker »

dspillett wrote: post #24
fourmyle wrote: post #19

Earlier quoted context omitted.

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.

Anything (hardware or software) in the network stack advertising "zero latency" is a lie. The idea or implementation may have merit, but it is best to avoid opening with a trivial impossibility.

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

#42

Post by why_only_15 »

ycombobreaker wrote: post #41
dspillett wrote: post #24

Earlier quoted context omitted.

"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.

Anything (hardware or software) in the network stack advertising "zero latency" is a lie. The idea or implementation may have merit, but it is best to avoid opening with a trivial impossibility.

i don't think most people read "zero latency" and think literally 0 ns of latency, because, as you said, it is trivially impossible. If you read any length of documentation you will see how the latency is orders of magnitude less than sending it out directly. That's close enough to zero latency for me.

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

#43

Post by londons_explore »

umvi wrote: post #16
jaimex2 wrote: 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…

I feel like the real solution is your terminal should ping every hour, and if a ping test fails it should auto-reset itself and file a bug for the developers with whatever state information is needed for them to fix the bug.

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

#44

Post by kortex »

dspillett wrote: post #30
TechBro8615 wrote: post #29

Earlier quoted context omitted.

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

I take it as a tongue-in-cheek spec, much like Capn Proto's claim of infinity times faster than gRPC.

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

#46

Post by J_tt »

zemo wrote: post #38
vvanders wrote: post #13

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.

have you ever actually done this? 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 f…

One thing I've always been curious about with JackBox is if it does anything when everyone's on the same LAN?

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

#47

Post by vvanders »

zemo wrote: post #38
vvanders wrote: post #13

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.

have you ever actually done this? 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 f…

Had to write the SDP handshake and re-build a subset of SCTP from scratch since the only SCTP implementation uses a global listener which doesn't play nice for a clean server implementation(it was also a royal pain to compile in a way that played nice with Rust).

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.

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

#48

Post by zemo »

J_tt wrote: post #46
zemo wrote: post #38

Earlier quoted context omitted.

have you ever actually done this? 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 f…

One thing I've always been curious about with JackBox is if it does anything when everyone's on the same LAN?

not sure what you have in mind, but no not currently

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

#49

Post by umvi »

londons_explore wrote: post #43
umvi wrote: post #16

Earlier quoted context omitted.

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

I feel like the real solution is your terminal should ping every hour, and if a ping test fails it should auto-reset itself and file a bug for the developers with whatever state information is needed for them to fix the bug.

Unfortunately satellite internet systems are way more complicated than you probably think. It can be very hard to tell why a terminal is experiencing issues. Sometimes it's because of a nearby cell phone tower and you have to adjust some terminal configurations to shift frequencies slightly. Maybe there's just a lots of bad weather in that particular part of the country and rain fade is degrading the signal and the terminal isn't transmitting at max power like it should. Maybe your neighbor has a police radar detector in his car interfering with the signal. Maybe a horse has bumped the dish and it's slightly mispointed at the satellite now. Maybe it's an issue on the gateway side. (all true stories).

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.

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

#50

Post by cosmotic »

This doesn't just magically remove the latency.

* 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.

Post reply on HN