5 ms·

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/Websocke

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.

vvanders 7y ago
You can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.
- penagwin 7y ago
  Wait webrtc uses udp? Is this new? I thought there was no way to send udp packets through client side Javascript?
  - vvanders 7y ago
    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.
  - mr_luc 7y ago
    Yeah with WebRTC data channels can be UDP! It's just -- and this may be mildly out of date -- EXTREMELY hard to find a server-side setup that will let you do all of what the browsers now support with WebRTC. My recollection from the last time I skipped across this topic was: there are 1 or 2 heavyweight open source projects that mostly focus on the video aspects but also supported data channel stuff, and then one lightweight C and one lightweight Go project that supported everything, and you were mostly out of luck otherwise. I remember the last time I checked, a year ago or so, pieces of what's required being worked on in recent OTP releases in BEAM-land. Hmmm ... time to check again.
  - fulafel 7y ago
    There is no raw udp or tcp access from browser js, just higher lwvel protocols that are implemented over tcp or udp.
- mypalmike 7y ago
  Just strip out TCP ICE candidates from the SDP and it won't use TCP.
- zemo 7y ago
  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 for production. It sounds nice in theory, but try actually finding a production-ready server implementation of WebRTC data channels. I would LOVE to find a documented example of doing client-server communication with WebRTC data channels (a Go implementation on the server specifically). I've found no such thing. Every few months I search and don't find such a thing, and I don't need the extra few ms of latency improvement badly enough that it would be worth the engineering time to author it myself. If you know of one that's actually ready for primetime, I'd love to hear about it. edit: after writing this comment, I did some snooping around since I haven't snooped around on this topic in a few months, this looks promising, unclear how widely used people are using it for production work: https://github.com/pion/webrtc https://github.com/pion/webrtc
  - J_tt 7y ago
    One thing I've always been curious about with JackBox is if it does anything when everyone's on the same LAN?
    - zemo 7y ago
      not sure what you have in mind, but no not currently
      - blackflame7000 7y ago
        What about household vs household games? Bring a new meaning to keeping up with the Jones’s :)
  - vvanders 7y ago
    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.
umvi 7y ago
> 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.
- withinboredom 7y ago
  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.
- londons_explore 7y ago
  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.
  - umvi 7y ago
    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.

vvanders 7y ago

You can already do this with WebRTC, you just need and implementation that won't fall back to TCP if the UDP negotiation fails.

penagwin 7y ago
Wait webrtc uses udp? Is this new? I thought there was no way to send udp packets through client side Javascript?
- vvanders 7y ago
  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.
- mr_luc 7y ago
  Yeah with WebRTC data channels can be UDP! It's just -- and this may be mildly out of date -- EXTREMELY hard to find a server-side setup that will let you do all of what the browsers now support with WebRTC. My recollection from the last time I skipped across this topic was: there are 1 or 2 heavyweight open source projects that mostly focus on the video aspects but also supported data channel stuff, and then one lightweight C and one lightweight Go project that supported everything, and you were mostly out of luck otherwise. I remember the last time I checked, a year ago or so, pieces of what's required being worked on in recent OTP releases in BEAM-land. Hmmm ... time to check again.
- fulafel 7y ago
  There is no raw udp or tcp access from browser js, just higher lwvel protocols that are implemented over tcp or udp.
mypalmike 7y ago
Just strip out TCP ICE candidates from the SDP and it won't use TCP.
zemo 7y ago
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 for production. It sounds nice in theory, but try actually finding a production-ready server implementation of WebRTC data channels. I would LOVE to find a documented example of doing client-server communication with WebRTC data channels (a Go implementation on the server specifically). I've found no such thing. Every few months I search and don't find such a thing, and I don't need the extra few ms of latency improvement badly enough that it would be worth the engineering time to author it myself. If you know of one that's actually ready for primetime, I'd love to hear about it. edit: after writing this comment, I did some snooping around since I haven't snooped around on this topic in a few months, this looks promising, unclear how widely used people are using it for production work: https://github.com/pion/webrtc https://github.com/pion/webrtc
- J_tt 7y ago
  One thing I've always been curious about with JackBox is if it does anything when everyone's on the same LAN?
  - zemo 7y ago
    not sure what you have in mind, but no not currently
    - blackflame7000 7y ago
      What about household vs household games? Bring a new meaning to keeping up with the Jones’s :)
- vvanders 7y ago
  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.

umvi 7y ago

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

withinboredom 7y ago
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.
londons_explore 7y ago
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.
- umvi 7y ago
  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.