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

51–60 of 81 posts

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

#51

Post by Matthias247 »

aeyes wrote: post #27
bweitzman wrote: post #15

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

Until you get some decent amount of load on the system. Then the background thread will still make progress. And the UDP/Proxy approach will only have failing requests, because the loss of any single UDP packet will make the request fail (there are no retries).

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.

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

#52

Post by bentcorner »

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…

Just wanted to comment and say thank you for your work :). The Jackbox games work flawlessly and even when they get into a weird state a refresh usually sorts things out. Thanks for covering whatever weird corner cases you had to cover to get it to work so consistently.

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!

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

#53

Post by nineteen999 »

umvi wrote: post #49
londons_explore wrote: post #43

Earlier quoted context omitted.

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

We run a bunch of remote paging basestations that utilize satellite, however, they are also backed up with 4G routers which are used instead if the satellite link fails for any reason (rain fade, nuclear missile attack on the satellite hub/network etc). I guess TV over 4G would use a lot more bandwidth and potentially be very expensive.

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

#54

Post by [deleted] »

edoo wrote: post #6
huhtenberg wrote: post #3

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

[deleted]

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

#55

Post by kstenerud »

cosmotic wrote: post #50

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

It's about SENDING requests with "zero latency", not about completing http operations with zero 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.

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

#56

Post by 29athrowaway »

UDP doesn't implement:

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

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

#57

Post by kstenerud »

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…

Wouldn't such a system be a big security hole?

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

#58

Post by geocar »

kstenerud wrote: post #55
cosmotic wrote: post #50

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

It's about SENDING requests with "zero latency", not about completing http operations with zero 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 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.

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

#59

Post by geocar »

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…

> have you ever actually done this?

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.

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

#60

Post by ComodoHacker »

kstenerud wrote: post #55
cosmotic wrote: post #50

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

It's about SENDING requests with "zero latency", not about completing http operations with zero 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.

>a use case for this

Logging/analytics?

Post reply on HN