Sure, but in this context, unless you are able to use the same source port for TCP and UDP (and likely from the load balancer to the application server too) you'll still need another way to identify a client/session when switching from TCP to UDP.
Doing that with NAT is even trickier. Take a look at the way some firewalls need to configure a DMZ for gaming, or SIP for some examples.
I'd like to point out that getting SIP through firewalls is a massive headache even today. If you're embedding connection information into a control channel, then the firewall needs to do DPI to figure out what is a valid communication stream vs. some attacker. And then people start encrypting the control channel and it's game over unless you can hook your firewall up to whatever the controlling software is or your firewall is super fancy and can MITM the control channel traffic because you've installed the cert chain on the firewall.
WebRTC is best option for media streams today for peer-to-peer cases.
The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery.
WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.
Given the kind of feedback happening (and my initial reaction admittedly was similar), maybe a different name would help with perception (I'm already not a big fan of "WebSockets", but "WebTCP" would have been worse), promoting the goals over the implementation detail of UDP?
It just seems like most real-life usages of WebRTC are either media-centric where TCP does more harm than good, or multiplayer scenarios where it's a wash since TCP's ordering is a pro while TCP's overhead is a con.
Worth mentioning again: this effort is to explore server-client low-latency, not peer-to-peer scenarios which WebRTC solves well.
And this is collaborative effort, not personal. So all input is welcome.
I've used WebRTC for p2p and server-client cases, and it is nightmare for later. And many other developers have expressed very similar experience when it comes to server-client cases.
Even more, after many years we see very little adoption of WebRTC for server-client cases due to it's complexity. WebSockets on the other hand took very little time to get adopted by many back-end platforms as well as browser vendors.
I wrote my own WebSockets solution long time ago on .Net before 4.5 .Net was released (includes own WebSockets implementation).
The reasoning there is kind of lame, every filter knows how to pass SCTP or UDP and doesn't pass SCTP since it is unpopular and UDP because stopping it is most of why you are filtering.
Making an SCTP web standard would improve endnode support (and actual app use) which is beginning to wane and are SCTPs adoption problems.
The point of providing SCTP instead is not to open up UDP and all of the baggage of existing services that will answer expecting you to be you and not a relay for a malicious ad in your browser.
Similarly, once you have a userspace SCTP stack you have allowed the garbage to reach userspace resources.
Everyone knows how to not be a jerk while using UDP or SCTP, but people who have the goal of being a jerk are more manageable if you only give them remote SCTP access.
Your security scenario only really works if you are happy with a symmetric firewall, that is one with the same filters in both directions.
My home firewall is set up to allow anything originating here to pass but block most things from outside. For this to work the firewall needs to be able to track the state of the protocol exchange which will be different for each protocol. Few firewalls can do this for SCTP or DCCP yet, I'm in the process of adding SCTP support to the one that I use.
Generally, yes. I suppose if the client were unable to override the default recipient port for DCCP-UDP Encapsulation (6511) and the DCCP implementation were enforcing rules such as back off on the client then it is still a better option to give a client a DCCP socket that can enable UDP encapsulation rather than giving inspecific access to UDP.
The point that seems to be getting lost is not that I want SCTP or DCCP support. Its that I don't think anyone should accept anything that could become a UDP arbitrary access loophole. The point of the current path is to replace the problem techs and add use cases safely as we go to gradually pay for a better network by making standards that aren't just the easiest thing for web-devs.
Every time someone tries to walk too close to the edge in a way that can open security problems for people who aren't running a server fully opted-in to web 2.0/etc, they risk a security backlash that could ban browser updates and effectively delay/kill unrelated innocent features and fixes with ripples for ~5-10 years.
It is indeed a bit like chicken-and-egg situation here.
But SCTP implements reliability and ordered delivery making it more of an alternative to TCP, than a solution for low-latency communication with cases where reliability and/or ordered delivery is not required.
I'm not familiar with DCCP, but as long as browsers don't get access to DCCP-UDP encapsulation without some work by the user it seems like another alternative to use to use web security considerations as leverage to ween a critical mass off of UDP.
> SCTP supports the transportation of user messages that have no
> application-specified order, yet need guaranteed reliable delivery.
But most people don't really care (that insisting on re-delivering out of date packets will use some bandwidth,) they just have an existing UDP app they want to port to the web and converting it to SCTP is easy enough (I think I've even used an LD_PRELOAD to convert for that? But I may be confusing a different ULP substitution.)
Making them do that and set everything up is actually a good mechanism for protecting the rest of the internet and allowing a web SCTP that browsers could enable even by default, with less risk of in page ad hijackings, etc. Allowing UDP is something that I hope every browser leaves as impossible to allow without going into configuration or being in an entirely different use context of web APIs than a browser.
Well, the problem is that I currently think WebRTC 1.0 is sufficient. For the example I gave, I think a simple JS library to write out the SDP is a perfectly fine solution. So I'm more asking, what did you find wrong with WebRTC?
Simply look at present state of WebRTC adoption by back-end services for use in server-client cases. Fist of all it is not designed for server-client cases. Second, after so many years, it is still not well adopted and used for server-client cases due to it's complexity on both sides - back-end implementation and front-end usage.
If you compare it to speed of adoption of WebSockets, variety of WebSockets implementations and how much it is used commercially.
There are many conversations by many developers who as well attempted using WebRTC for server-client communications, and it is apparent trend.
One of the developers of WebRTC team at Google who worked on DataChannel and network code admits himself that their team is aware of complexity and difficulties with WebRTC in server-client cases: https://news.ycombinator.com/item?id=13266874
>Fist of all it is not designed for server-client cases.
WebRTC is specifically designed for server-client cases. In the case of video and audio, the server is called a "mixer" or MCU. This is extremely important for large multi-user conferences - if it weren't for a mixer, you'd have to upload your video once for every user, burning all of your upload bandwidth. Examples of services using this are Appear.in Premium and Cisco Spark.
Note that games are the #1 use case mentioned in the Datachannel draft [1]. It's perfectly fine to argue that the standard is bad, but it was designed for these use cases.
The Google developer you linked seems to be arguing for improving the WebRTC C++ library, not changing the protocol.
> You can't compare WebSockets with WebRTC because the first one has a much larger implementation base across browsers than the later.
This is exactly what I pointed out: WebSocket has much larger implementation base across browsers and back-end due it's simplicity.
> There is also a list of various transparent fallbacks that can be implemented like long polling which WebRTC doesn't have.
Those fallbacks were temporary solutions during adoption of WebSockets which today are obsolete as WebSockets are well adopted and pure WebSockets implementation is fairly simple.
This is what we want from WebUDP for server-client cases, which we can fallback to WebSockets if WebUDP is not supported.
This spec been there for very long time, and has been adopted by FirefoxOS (deprecated platform). Which exposes low-level access to establish pure TCP and UDP connections with permissions flow by environment.
It exposes many security concerns, that's why WebSockets were more favourable over TCPSocket.
We want similar for UDP.
Not having raw TCP means you can't speak to any existing TCP protocol through a browser. It might not be a useful feature but I think that not taking it into account is an issue because most use cases can't be implemented with WebSockets.
Ability to connect to raw TCP or UDP from a browser is a major security hole.
Due to that, WebSockets were created were handshake is handled by browser transparently from developer ensuring port scanning is not possible.
As well as to preserver origin-based security model of HTTP. Which we want for WebUDP as well.
