71–80 of 81 posts
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?
Fire and forget logging to HTTP endpoints would be pretty useful for IoT sensors. You'd have a lot less code and could potentially save significant power. You obviously lose the ability to guarantee data arrived, but that's probably not important for all sensor situations.
I'm going to sacrifice my karma for this: the solution is not to make TCP use UDP, but instead to allow TCP to behave like UDP by giving it the option to ignore out-of-order. All operatives have flawed implementaions of this, but we need it to be in the TCP RFC.
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…
( yes, I know that's a terrestrial, microwave relay dish and not a satellite antenna, but it could happen.)
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…
> 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 testin…
I'm going to sacrifice my karma for this: the solution is not to make TCP use UDP, but instead to allow TCP to behave like UDP by giving it the option to ignore out-of-order. All operatives have flawed implementaions of this, but we need it to be in the TCP RFC.
It will basically require another framing protocol on top of TCP to make it even remotely usable.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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 testin…
when you say http do you mean a roundtrip per data point? curious if you went from 1 http request per data point to webrtc or from something more like 1 websocket message per data point to webrtc.
I wonder if the author wrote this with something in mind? Fire and forget logging to HTTP endpoints would be pretty useful for IoT sensors. You'd have a lot less code and could potentially save significant power. You obviously lose the ability to guarantee data arrived, but that's probably not important for all sensor situations.
It's even possible to translate CoAP directly into HTTP using a proxy such as Squid.
There's also MQTT, which was basically designed for IoT sensor reporting. This has even more supported libraries and has been around for ages.
The UDP proxy system has the benefit of not being able to fall victim to classic UDP amplification vulnerabilities (send a packet with a spoofed source and have the response bounce back), but it does allow an unsuspecting proxy server to turn into a HTTP-based DDoS. You can send a single packet towards a server and the server automatically does a full TCP handshake and payload delivery for you! That's a lot of extra traffic.
I'd stick with known protocols for IoT stuff instead of this. At least the risks have been analysed and firewalls can (should) be easily configurable to block outgoing DDoS attacks in the worst case. The same is not really true for this.