mrmoka

This is where DCCP or alternative protocols come in play.

In case of DCCP it can be implemented over UDP utilising existing firewall support for UDP traffic.

The main goal of this effort is to explore server-client communication scenarios.

You probably have not read the document. It's clearly stating - there is no need for reliability and ordered delivery of data. The only requirement from security point of view is congestion control. Please, do read the topic content before making assumptions.

UDP over IPv4 and IPv6 has source IP and source Port in header. This can be used for sticky routing through Load Balancers.

You are absolutely right. But we need to remember - our motivation is to get a solution without most of TCP mechanisms to suit cases where it is not required. SCTP - is more of an alternative to TCP and implements mechanisms that are not required by our motivation. DCCP - is more close to what we want as it solves security concern: congestion collapse.

And you are right - we do not want reinvent the wheel.

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.

If there is alternative transport protocol to enable low-latency delivery as efficient as UDP, then it is worth exploring.

UDP - is something been used by many industries for long time and is well known protocol to make a foundation from.

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

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.

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

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

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.

This is something that worth exploring further to identify if it is a requirement for a WebUDP implementation.

> I'm very[1] familiar with the IP family of protocols.

Great, you have an expertise to contribute. And with this discussion you already are.

> If you don't know what your requirements are, you shouldn't be choosing a transport technology. It sounds like you want an library that wraps WebSockets or WebRTC and handles most of the complexity. There are "libraries" that wrap over some protocols. They don't make adoption of underlying technology easier, WebRTC in this case.

This effort is to establish clear requirements, not yet to propose exact solution. So this discussion is just a process of establishing those requirements.

High level requirements are clearly stated in the document, and important one is: simplicity. Currently there is no simple solution for low-latency server-client communication.

> > WebUDP could implement it's own [transport] layer over pure UDP > Then you want TCP. The only reason to use UDP is to avoid the complexities of a transport layer. Transport reliability is very hard; this isn't something that is easy to re-implement by yourself in UDP.

Layer on top doesn't have to involve full on replication of TCP techniques or alternatives. Just like WebSockets only adds very little to pure TCP in form of a data framing (header) for messages.

> More importantly, I take it you don't know what your MTU is? The Maximum Transmission Unit[2] the maximum packet size. On ethernet-based networks, it's probably ~0-100 octets less than ethernet's 1500 octet MTU. You need to keep UDP packets under this limit, or they will fragment. Fragmented IP packets may not arrive at all and even when they do, the OS will wait until all fragments arrive before passing the data up to the app. If you're insane and send HTTP headers in each packet, you've wasted most of your data space. Each packet? Shouldn't we send headers in the first packet only? Except that every packet IS the "first packet" in stateless protocol like UDP. It's the transport features of TCP that create ordered-data semantics.

This is really valuable input, and is exactly what is needed to fuel further requirements for an implementation.

You know, you can provide valuable input without trying to "argue" ;)

SCTP have been mentioned in the repo: https://github.com/Maksims/web-udp-public/issues/1#issuecomm...

This is valuable input, you are welcome to contribute in form of PR!

Just looking at the complexity of "minimal" implementation only highlights the need for different solution.

And with WebUDP life for those guys would be much easier.

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.

This is collaborative effort. I act from my capabilities, but people with certain skillset are welcome to contribute with proper RFC.

As mentioned in the doc, one of the options is to simplify WebRTC by making some components optional to enable it's better adoption and easier to implement on the back-end as well as on front-end.

Those implementations were created to be utilised within FirefoxOS where applications are granted permissions by user when installing them. And access to several API would be strictly regulated by OS it self.

In Web context this approach wouldn't work and would lead to security issues. Just like there was need or WebSockets (TCP), there is need for similar API for UDP but it cannot be pure access for creating UDP connections as this leads to many security concerns.

> There is a lot more to security than transport-layer encryption and authentication.

You are welcome to PR.

> Connection based

This could be explored: starting from simple handshake, all the way to fully connection based protocol. Open for discussion based on developer needs.

> The already-stated "requirements" are asking for something more complex than WebRTC.

You are welcome to highlight specifics that makes you think that way.

> Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?

UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons.

> > WebRTC suffers from complexity

> That complexity exists for reason.

For P2P type communications, this complexity is perhaps reasonable.

For Server-Client type communications not at all.

> Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors.

This document is initial effort to bring public discussion to form a reasonable shape of what WebUDP could look like. You are welcome to participate.

If it is implemented with handshake mechanics same as WebSockets, then it would be no more harmful than WebSockets.

It's a shield, gives you extra points to handle damage.

You can indeed, feel free to do so. Here is source of server side code: https://github.com/Maksims/tanx And here is client side: https://playcanvas.com/project/45093/overview/tanx And my email if you want to contact directly: core[at]moka.co

Server went down, should be good now :)