A solution for enabling UDP in the web
new.gafferongames.com
new.gafferongames.com
> UDP packets are not encrypted, so any data sent over these packets could be sniffed and read by an attacker, or even modified in transmit. It would be a massive step back for web security to create a new way for browsers to send unencrypted packets.
TCP packets are not encrypted, either. That data is transmitted via UDP or TCP doesn't make it encrypted; encryption is handled elsewhere.
Now if you insist that the contents of the transmitted UDP packets are encrypted--as the author does with the documented proposal--then that's one thing. But the data transport mechanism (UDP vs. TCP) doesn't inherently mean encryption.
(Fun fact I learned while writing words about TLS: Use of TLS does not automatically imply confidentiality--that is, encryption--of the data being transported. TLS supports a NULL cipher[0] that ensures integrity and authenticity but the payload is "in the clear.")
It's been 10 years since I worked on a VPN stack, but naming pedantry dies hard.
(Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)
Most implementations (eg. WebRTC) involve pulling in truck loads of C libs; it's insane. And then you want to support other clients? Good luck.
It "works" in the case of EAP because you're never sending more than a few datagrams at a time, and if one gets lost it's not a huge tragedy to have to start the whole process again ... but, I can't imagine this being feasible for more continuous data-transfers such as streaming data "oops you lost a packet - sorry you'll have to re-establish your TLS session again"
I did notice the DTLS thing lying around when I was browsing the OpenSSL source but as another commenter says it's not that popular and presumably suffers many of the same complications.
But kind of related to your point, TTLS does in fact use the "cryptographic material" derived as part of session establishment to derive a shared secret for hashing in CHAP, MS-CHAP and MS-CHAP-v2! [1] The nifty thing about that is it "binds" the ensuing authentication process to the actual TLS session. With MS-CHAP-v2 it also provides for mutual authentication without either party ever having to exchange sensitive info (neither client nor server ever has to know the password).
This was actually a real pain to do with Open SSL as that information wasn't readily available with the standard API. I had to implement some horrific cludge to get the necessary info nested within 3 layers of structs.
I personally think, it will see wider usage in upcoming decade.. but it is just a guess.
how does QUIC do encryption?
https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...
What the problem with doing it the current way? Massive routing inefficiency at scale. Since the layers for persistence and routing (L2-4) don't carry all the info needed to connect to a server (some like headers and URL are up in HTTP - L7) it's mandatory to "unwrap" through the protocol layers before you can determine where a stream/packet/HTTP req is supposed to go.
This means you can use something like IPVS as your L2-3 load balancer, but once the streams are divided out by IP/port you need to do the TLS+HTTP in one step. There's also some hard limits on how much traffic a single IVPS instance can handle because balancing TCP even at low level requires the router to keep track of connection state (conntrack). So we have this situation where there's a main low-level balancer with some arbitrary traffic limit imposed from TCP overhead, and behind that we have a bunch of child balancers doing way more work than they should be handling the connection from the TCP level through TLS and HTTP before they can pass on the connection to a back-end app server.
This could all be avoided if HTTP was a stateless UDP based protocol, and TLS was baked in rather than being an additional layer. It would make routing and load balancing far more effective at scale. You probably wouldn't see nearly as many DDoS attacks succeeding, because the vast majority of them exhaust CPU power far before they actually flood you off the net.
It also makes it possible to swap out parts more easily. For example, to put SSL under HTTP. Or QUIC under HTTP/2 when people realized TCP is not a good fit for it. You could, if you wanted to, run HTTP over UDP. Although you'd quickly realize you actually want many things that TCP and TLS give you for free, so you'd have to start re-implementing the same functionality on top of UDP.
It's a hard distributed problem: how do you coordinate many independent flows of traffic to efficiently utilise the many network links in the internet? Do this wrong at scale, and even broadband internet will feel like you're on a 2G mobile network.
Also I don't think it makes sense for HTTP to be on UDP. While it's stateless, you still can't tolerate packet loss with HTTP. Otherwise you'll try loading a page and maybe nothing comes back, or only part of it comes back. What then?
The CoAP protocol for embedded devices tries to achieve HTTP semantics on top of UDP. But it's a lot harder to implement correctly, especially if you want to support large request payloads. And I think it isn't easier to load balance or proxy then the TCP based HTTP, since it's also not sufficient to look at a packet header but you would also need to parse and keep around the whole request response states between packets - only now the state is no longer associated to a TCP connection but to a plain UDP socket which must handle dozens of parallel requests.
Edit: Oh he mentions this, but invalidates it due to the complexity of typical P2P:
> But from a game developer point of view, all this complexity seems like dead weight, when STUN, ICE and TURN are completely completely unnecessary to communicate with dedicated servers, which have public IPs.
I don't remember this being complex (there was some off-the-shelf library for getting a data connection on the server-side), but YMMV.
> I don't remember this being complex (there was some off-the-shelf library for getting a data connection on the server-side), but YMMV.
I've implemented all of these protocols before for use in VOIP. It's only necessary to discover an open port. Once you have that, it's clear sailing -- you never need to do it again. So I have no idea what the author means. If you have a connection on the open internet, then all of these protocols will realise that they need to do nothing.
Having said that, I have never used WebRTC, so possibly the author is confusing some other WebRTC issue with this.
https://news.ycombinator.com/item?id=13264952
with the top comment claiming all of this was required:
https://chromium.googlesource.com/external/webrtc
and other options that may be newer:
Its still new, but we're starting to pick up some steam in the pace of development, and we have a pretty easy demo in the repo.
It's not complex because it's already built-in to the browser, but if your network architecture is client-server (not p2p), you have to implement that entire stack even though none of it is strictly necessary when communicating to a public IP.
https://github.com/cjb/serverless-webrtc/
EDIT:
Aha! I based my code on: https://github.com/js-platform/node-webrtc/blob/develop/exam...
I do also now prefer to use other languages than C++ to build servers, let it be Go, Java or C#. In all of those getting native webrtc data channel support is a giant effort, because there's neither sctp nor dtls support available. You could fallback on C libraries for this functionality, but that complicates the build process. Establishing HTTP, websocket or even HTTP/2 support is all easier than webrtc.
Replacing DTLS+SCTP with QUIC would be a good reduction in complexity, and we (the WebRTC team) are experimenting with doing so (https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...). It has a long way to go, but hopefully someday just having QUIC on your server will be enough.
(I work on WebRTC)
(ICE means trying STUN and falling back on TURN).
The ICE RFC does a good job of explaining it: https://tools.ietf.org/html/rfc5245#section-2.7
The two best implementations on npm are `wrtc`: https://www.npmjs.com/package/wrtc and `electron-webrtc`: https://www.npmjs.com/package/electron-webrtc
Both have serious shortcomings. `wrtc` uses the Google webrtc.org library which is overly complex since it includes lots of code for dealing with complex video/audio codec stuff that isn't needed to open a simple data channel. And if you're unlucky enough to be on a platform that they haven't made a prebuilt binary for, then you have to wait an hour for a bunch of Chrome-specific build tools to download and compile the library locally. Not fun to wait an hour after typing 'npm install'.
The other library, `electron-webrtc` literally launches a hidden instance of Electron and communicates with it over IPC from Node.js, which means it runs everywhere that Electron does (without waiting for anything to compile!), but it's a pretty heavy-handed approach. Launching a whole Chromium instance when you need a socket is, like, not ideal.
Another idea: how about implementing just the parts needed for Data Channel in JavaScript? A former Mozilla engineer, now Google engineer, actually tried this but gave up before finishing. His code is here: https://github.com/nickdesaulniers/node-rtc-peer-connection It's also not trivial since it requires a DTLS (TLS over UDP) implementation, and it's not exactly trivial to write one of those in JS. There is a chance that Node.js could expose the DTLS implementation from OpenSSL, since that's already part of Node. Then we could probably achieve a "pure JS" (no npm compile step) implementation of Data Channel. But there's still quite a bit more code needed to finish off this implementation. Discussion here: https://github.com/nodejs/node/issues/2398
I'm grateful to all the awesome folks that worked on these implementations, and this isn't meant to snub any of them. WebRTC is hard!
We actually use `electron-webrtc` in `webtorrent-hybrid`, a CLI version of WebTorrent that can talk to "web peers" in browsers (https://github.com/feross/webtorrent-hybrid). Fortunately, most users can just install WebTorrent Desktop (https://webtorrent.io/desktop/) which works nicely.
But this all goes to show just how overly complex WebRTC is, and why we really do need something like this post suggests, a low-level UDP API for the web.
Honestly, most of the difficulty back in 2012 was because all of it was poorly documented and the standards were changing with every Chrome release, so it was partially a reverse-engineering effort. If I had to do it again from scratch (even though it's been at least 2 years since I've touched it), I could probably get something working in a week or two, and production-ready in a month or so.
I think a large part of the difficulty you describe is because you're trying to do this in Javascript. Doing it in a language that already has some library support for the various components cuts out a lot of the pain.
Once you realize its just ICE + DTLS + SCTP, and that each layer has a corresponding library, the work getting it up and running is mainly just 'plumbing'.
Here's a link to the library I've been working on: https://github.com/chadnickbok/librtcdcpp
As I was working on getting electron-webrtc running on my AWS Ubuntu instance, it occurred to me that it should be relatively easy (in other words, probably hours of tedious work) to abstract out the dependencies for everything that isn't required for only running WebRTC DataConnection. (I could produce a list of libraries to shim with placeholders. Call it 'drtc'?) If you are willing to give me some pointers, I'm willing to do the scut-work. (Contact info in my HN profile.)
We are aware that it's a pain to use just the data channel, and we're working on it. We're refactoring the native API to be more ORTC-like and make it possible to compile without all the audio/video parts. It will take time, but it should become easier as we make progress.
I disagree that the solution is to expose UDP API to the web. Writing good congestion control is very hard, and it would not be safe to let web apps do that; doubly so for crypto. As for native apps (even JS/node ones): you already have a UDP API.
The solution is to make the WebRTC API easier to use and simplify the protocol stack. We're working on the first, as I mentioned. And we're experimenting with the second (by using QUIC instead of SCTP+DTLS). Again, it will take time, but eventually we'll get there (probably).
In addition, the SDP exchange also sets up DTLS, making sure that whoever the WebRTC SDP was exchanged with is the same as whoever connects at a low-level. While you can implement this as a messaging exchange over UDP once the connection is established, its a nice property that WebRTC doesn't even allow the connection to be established with a non-secured link.
I think the hardest part of the stack is getting a decent, stand-alone implementation. With things like Websockets creating a server is straightforward, but libraries for low-level webrtc are much harder to build.
Use the simple-peer library to hide away all that complexity. Just deactivate "trickle" for negotiation, then you get a simple Answer-Offer exchange with just one message each. I am using this to have WebRTC as a client-server proxy for UDP for my MMO game written in Golang.
> New security holes would be created as JavaScript running in web pages could craft malicious UDP packets to probe the internals of corporate networks and report back over HTTPS.
Is this the same reason that the "raw" TCP is not supported on the web? When I first learned WebSocket I was surprised that it is a message-based protocol. What I imagined was a protocol that utilizes HTTP only as a means of negotiation, and the actual transfer is done just as the raw TCP does. But it's not, so I had to create another layer to be interoperable with the existing (raw) TCP server. What was the exact reason?
Edit: Another reason I can think of is the encoding issue, cause TCP is byte-based. But the current WebSocket spec already assumes UTF-8 for textual data, and is also capable of sending bytes using `ArrayBuffer`. I don't see how this would matter in practice.
If you aren't aware, the FTP protocol lets one specify a port and address to connect to; it was not that long ago that servers would not check if the address for the data connection was the same as the address for the control connection, and so one could send data to any port on the internet from an anonymous FTP server. This caused all sorts of headaches.
What I meant when I said "utilizing the legacy TCP sever" was creating some plugin that is attached to the server, effectively acting as a lightweight HTTP server that just does the upgrade process (within the same connection). In this way the remaining communication doesn't have to involve message encapsulation/decapsulation each time a message is transferred.
See eg https://support.microsoft.com/en-us/help/247132/how-to-perfo...
The downside: A lot of websocket APIs (and most especially the one in the browser) don't support this and will only send/receive complete messages. Which means if you want streaming support you better implement it as a layer on top of messages, since it works everywhere.
It's a little bit sad that the websocket spec is complicated through the continuation frame feature while in reality noone has a reason to use it.
And back to the question: The masking "feature" of websockets is also there to prevent browsers from speaking raw TCP. Without it Javascript could craft exact TCP payloads, which might in certain situations be used to directly talk and manipulate internal services. The masking guarantees that the remote on the TCP connection will get some random data after the websocket header.
The entire websocket code should have never existed in the first place — just use standard TCP with standard TLS, like any other system, too.
Maybe require a browser permission for that, and that issue is solved, too.
And yeah, I now remember that masking was also a problem at the time. So even if web browsers adopt a new API to send fragmented messages, it would still not be possible to directly plug in them to legacy servers. Sad.
Edit: It would also be possible to send a single giant message, which contains a single giant continuation frame sent for the lifetime of the session, which is followed by a FIN frame. Am I correct?
One downside: Getting node-electron to run takes some wading through shared library installs to satisfy Chrome dependencies. However, this turns out to be a series of straightforward responses to error messages. Another downside: I'm wasting some memory and swap on Chrome dependencies I'm not using. In the case of my game, I'm always going to be more CPU/bandwidth bound than memory bound, so this turns out to be a non-issue. A third downside: WebRTC uses up 72 bytes of each packet with its own header information.
All that said, it appears to be running like a champ. It also makes a big difference in the play-ability of my game in poor network conditions.
(I work on WebRTC and implemented much of the data channel; I'm always interested when someone uses it)
ECMAscript/JavaScript should NOT be blindly run within corporate networks, and web 2.0 is insane for making all websites expect that.
This would take a few pieces, but port scanning is pretty feasible considering I have already done it more painfully using XSS exploitation frameworks to demonstrate XSS risks for customers before.
1.) You need some javascript running in a browser on the corporate network all set up for the corporate proxy to get out to "the internet". This browser would be on a machine on the internal LAN.
2.) UDP access enabled in JavaScript somehow.
3.) A user wanting to purposefully tunnel traffic would then set up a local UDP listener and build a proxy that would communicate with the JS using UDP. You would then need an HTTPS end point "on the internet" that would make your legitimate requests. You can do long lived streaming connections. The machinery isn't that important.
4.) That is it. [Special HTTP Proxy]<--->[Corp HTTP Proxy]<--->[Browser]<--->[UDP Proxy]<--->[Your apps that want to escape]
5.) You would of course reuse existing protocols and there are a ton of ways to flow all of this at each step. But it is just one more hole.
Side note: You can perform sort of crude TCP port scanning already with a meaty enough XSS exploit. An unfettered UDP connection would let you do UDP scanning to an internal LAN then as well.
Anyway this whole scenario is really complex, it would be much easier to just use Corkscrew and the existing corporate HTTPS proxy, because you need to invent a browser to UDP proxy scheme and a browser to "your HTTP proxy" scheme that can ultimately do generic UDP/TCP requests traffic. But your system listening on HTTP and or HTTP/S on the Internet would get requests and make the actual generic UDP/TCP connections for you. Honestly this whole scheme sounds complex and annoying and there are already other schemes like proxying TCP via DNS that are more accessible for exfiltrating data :)
The general point is code in a browser is inherently "permitted" and easy to get going on an internal corporate network. The more ways that code can reach out of its sandbox the larger the attack and defense surface you have as a corporate network trying to keep machines locked down and "under control".
There was a you tube video awhile ago showing java-script able to run an operating system in a web browser as well as games inside the OS. Recently, Chrome added a task manager and user logins. Chrome is no longer a web browser, it's an operating system, and what enables an entire ecosystem of abuse is java-script.
In a few years hence, someone will figure out a technology that will disable java-script from running on client machines via firewall filter. It will break a lot of websites. Let it.
It's totally possible today to create a filter that will scan for JS and remove it from sites with one of those man-in-the-middle corporate proxies.
But it'll break pretty much every site. If you're talking about a company, that's as conductive to security as mandating weekly password changes requiring no repetition, symbols, lower + upper case and 15 characters.
Users will find ways around it. Like bringing unmanaged devices to browse the internet.
In terms of broken websites, corporate users don't have the influence as they did in years past.
Since we're trending towards pretty much every person in more economically developed countries having smart phones.
If a website doesn't work for a business's users I don't see how site owners will care.
On the development of web browsers becoming an OS of their own. Sure there's work to be done to improve security. For example, fingerprinting needs to be properly mitigated [1].
The web is open. Anyone can implement a web browser. Chrome, Safari, Firefox, Edge are trending towards writing one webpage/app and having it run everywhere.
Windows, OSX, Linux, Intel, ARM, Desktop/Laptop, Mobile/Tablet. Aren't a concern past display/formatting.
There are known attacks from the last year, and probably a huge pile of 0-days waiting to be used.
What's a shame is that there is a need for much of what it offers (and, if not a need then at least a desire for much of the rest). If only there were a sane, least-privileged alternative.
Firewalls are a much more porous than most people think. It's only a first line of defense to prevent badly configured or broken junk on your network from being instantly exploitable.
http://www.elitefeet.com/wp-content/uploads/wooden-gate-no-f...
You don't need WebRTC's level of complexity to do P2P. WebRTC is an over-engineered Rube Goldberg machine for many reasons, including the fact that it tries to include so many capabilities in a single standard. It's also complex because STUN, TURN, and ICE are overly complex. WebRTC should have used a simpler underlying design. You really, really don't need all that. I say this as a developer of multiple P2P protocols including some that are used in serious applications.
Then there's stuff like: https://github.com/js-platform/node-webrtc -- you don't have to do your whole backend in Node if you don't want, but you could plug something like this in on your servers and speak WebRTC to clients. In P2P a server is just another node and there is nothing the says servers can't talk in P2P networks.
I do believe it would be nice to have UDP in browsers somehow. In fact I think it would have been far better to just add UDP to the browser spec and leave WebRTC out completely. It could have been implemented in JS (and WASM in the future) using TCP and UDP transport provided by the browser. Doing it the way it's been done is like including application software in a computer's ROM. It's the wrong place to put that level of abstraction.
In particular, I mean that subrequests are sent by default with credentials (cookies). This is backwards. In an ideal world, I should be able to send arbitrary anonymous HTTP requests, and should have to jump through hoops to send along the user's cookies. In reality, it is the other way around. This is the original sin that makes CSRF possible. Any site can send a request to any other site I am logged into, and pretend to be me. I understand that we can't change that now, but it just seems wrong.
Right now, you can send anonymous requests (e.g. using windows.fetch), but unless a specific CORS header is returned, you cannot access the results! Ideally, it would be the other way around, and you could only send authenticated requests if the target site cooperates.
Now you can make as many requests as you want (e.g. by using img or iframe tags), but if you want to use the results, you need 1. the site's cooperation, or 2. you need to include remote javascript. This is the next backwards thing. Why do I have to execute remote javascript when I just want JSON data? This should be absolutely discouraged in an ideal world!
The current security model precludes a lot of things. One is the classical Mashup. Back then, when Web2.0 was hot, I made a simple HTML page that scraped another website for geodata and wanted to display it on a Google Maps map. Imagine my shock when I found that I cannot read another (open, non-credentialed) web page with XMLHttpRequest.
There are a bunch of applications that I just cannot write within the current security model, and I believe it is in the interest of certain people to stay this way, so that they can remain in control of content.
The same applies even more when I think of allowing UDP or general network access. Imagine an IMAP client or BitTorrent client in the browser. A pirate iTunes that doesn't rely on a central server. A Tor implementation. You could even do JS crypto somewhat securely - you wouldn't serve the .html page over HTTP, just a simple static file that you'd deliver like any other program.
Sometimes I dream of a HTML 6+ "application profile" that would be opt-in, and allow you to do these kind of things.
What he really wants is a connection-oriented, TCP-like protocol with more flexible handling of missing/delayed packets. (As this is a frequent use-case in game development).
His solution is a UDP-based protocol that satisfies this and other use-cases specific to networked games while keeping the connection semantics of TCP.
However the fact that it's UDP-based seems like an implementation detail to me. The proposed solution hides a lot of other UDP-features that are not contributing to those use-cases but would absolutely make sense in other situations (like connectionless messages and broadcasts)
What I really want is the most UDP-like thing possible in the browser, that lets people build whatever higher level protocol they want on top of it, just like game developers do on every other platform.
Being connection based is important because if it wasn't then it would quickly turn into a DDoS tool, or a security nightmare for probing internal networks for vulnerabilities.
So clearly it needs to be connection based. And if it needs to be connection based, then that rules out broadcast packets too.
I didn't see a port number anywhere. Shouldn't you define 443/UDP (or other) as the only connection port? This would allow networks to manage the traffic, for example dropping all UDP/443 traffic internally, or managing bandwidth at a firewall.
Finally, shouldn't P2P be in the mix? If not now, won't we be doing this again in a few years?
Thanks for taking on such a big challenge, and for listening to the peanut gallery.
I don't have any defined port because in the game industry we tend to run multiple game servers on the same box, so we take up a bunch of ports. I acknowledge that this could cause issues with corporate firewalls, and would be open to ideas how to solve this.
Regarding P2P, I think WebRTC solves the problem of browser to browser communication just fine. Any attempt to support p2p this would just end up rewriting WebRTC.
What I'm trying to do is solve just one small part of the problem, in a WebSockets like way, just one thing that would enable a lot of other cool things to be built on it, if it were adopted by browsers.
cheers
A forged timestamp would still need a signature check, but a clear-text token would not. The speed difference would only be important with a flood of forged packets, each of which would need to have it's signature checked. Additionally, each system could implement a different type of defense: like issuing regional clear-text tokens, or A/B tokens to find which account is leaking a clear-text token, or giving each server it's own token so a DDOS attempt that wanted to force signature checks would need to get the right token (and get it again when an attacked system changes it.) Hosting providers that offer DDOS protection today could offer integrations based on clear-text tokens that wouldn't need any interaction from a game system (other than submitting the clear-text tokens.) I don't know if routers typically have the ability to check a signature, but they can probably drop packets that don't pass a (clear-text token) mask check.
The port issue is interesting. Maybe a range of ports (44300-45100) would work for network administrators. Maybe there should be restrictions and a listing of uses like the first 1024 (this is voice, that port's video, file transfer, etc...)
Browsers should also limit connections. Only 2 connections/IPs at a time? Only JavaScript from the origin domain (the address in the URL) can open connections, not advertisements or iframes. Maybe ask the user to open connections like browsers ask to use your location or audio/video.
I wonder too if a browser should only open a connection when presented with a request signed using the (private) domain SSL cert? That would drastically reduce the ability of bad JavaScript to co-opt browsers of a website (into a DDOS of connection requests.) To use a websites traffic for a DDOS, you would need the SSL keys. Browsers could also be required to add the domain and verified domain sig to a connection request, so a website that cause a DDOS would be identified. I'm not sure identifying the website would lead to accountability since they may have been compromised, but it would prove which domain caused a browser based DDOS; reddit.com couldn't claim a bad advertisement caused their millions of browsers to open connections. This wouldn't stop forged packets, but it should stop innocent web-browsers from becoming a tool for DDOS.
I understand that you love UDP and I won't try to move you on that. But can we avoid browsers? They're basically the worst things ever.
See my other comment for the downsides: https://news.ycombinator.com/item?id=13745055
So much for people behind carrier NATs
As someone who wrote her own (non-encrypted) networking protocol for desktop games, netcode.io certainly seems easier (especially with the built-in security), so in the near future I intend to move my projects over to using netcode.io instead of what I have currently.
Now a browser is just an abstracted operating system. So, fuck it, I guess, let's add a second TCP/IP stack.
The browser is used for all these things; why not have a protocol that works for these scenarios?
(Client<->Server; WebRTC and ObjectRTC are p2p orientated and excessively complex due to this as discussed in article)
That desktop OSes happen to be called "desktop OSes" and web browsers happen to be called "web browsers" is fairly irrelevant to what they're actually good at. Desktop OSes make great hardware abstraction layers, just as server OSes make great hardware abstraction layers for virtualization platforms. But they're fundamentally misdesigned for much of anything else.
A video game on the average Windows, Mac, or Linux desktop has full read and write access to the memory of a tax app on the same desktop
I can read /proc/$PID/mem provided my UID = the effective UID of the process.
Or I can also use ptrace(), again if my UID = the effective UID of the process, both to read the processes' memory and even to modify its code at runtime.
(Some LSMs will block this...)
You run each program as a different user account. The HTTP daemon doesn't run as the same user as the DNS daemon even if they're on the same machine.
This is obviously annoying on a desktop because you have to use user switching to use another app. It would be better if desktop operating systems provided native support for it so that user accounts had a sub-account per app and apps automatically ran like that, and then a permission prompt if one app tries to access another app's files, which you can grant as one-time access or permanently.
Then you expect your email program to try to access a document you're attaching to an email, but if a video game tries to read your tax returns you can be appropriately suspicious.
The interface between a web page and the outside world allows it to do things like access its site and not others, request a particular file be opened, send structured messages to other sites that wish to opt in to such access, etc.
The interface between a process and the outside world gives it either TCP sockets on behalf of the machine, or nothing at all; either the ability to open any file as the current user, or nothing at all.
I used to be excited about proposals for desktop operating systems to provide sandboxing via multiple UIDs and native interfaces for passing files around and powerboxes and all of that good stuff. Then I realized that the web platform does all of that and is very widely adopted and well-tested, and there's no hope of the existing platforms catching up.
I used to have two user accounts, one of which was allowed to run the Flash plugin so I could listen to music, and one of which held my important work. Then the web folks figured out how to sandbox the Flash plugin without requiring me to Ctrl-Alt-F8 to pause a song. Then they figured out how to not use a native-code plugin at all.
I don't particularly like this conclusion in an abstract sense, but it's certainly let me get on with getting things done instead of hoping for a future that will never come.
You can, if the browser is Chrome: https://developer.chrome.com/apps/sockets_udp
The other downside is that the browser (currently only chrome anyway) would present QUIC to the user only in form of QUIC streams with HTTP on top - which means the browser would reject any streams with non HTTP content and there's no API in Javascript for working with other content. The XHR and fetch APIs will utilize QUIC but only for HTTP on top of it.
This means for transmitting unreliable and potentially unordered packets we would need a new browser API anyway. The webrtc data channel API allows to read/write this kind of data, but it's however bound to the webrtc protocol stack (SCTP/DTLS).
While agar is a casual clicker the core game experience revolves around sorting out collision conflicts. I can see how high performance would be desirable.
- It's not clear how data is encrypted. I don't see a client key being generated. It will be very difficult to do this right without using something like TLS. Are the keys just sent over an unencrypted channel?
- The connect token should contain the client's IP address, so the server can verify the same IP that got the token is trying to connect. This prevents someone from using a valid token for reflection attacks.
This token contains public and private data. The public data tells the client which servers to connect to, what the keys are etc, hence the need for HTTPS.
The private data is what gets sent over UDP in connection handshake, and is encrypted with a libsodium AEAD primitive using a private key shared between the backend matchmaker and the dedicated server instances.
Because of this clients cannot read, modify or forge the connect token private data, so cannot connect unless they get a token from the backend.
Tokens are only valid for a specific authenticated client to connect to a small set of n dedicated servers, and expire quickly (30-45 seconds).
- Web browser connects to like https://auth.myapp.com. This can either be part of the login process or server discovery, it's totally up to you and specific to your app. This service calls netcode_generate_connect_token and returns the symmetric key / connection token in the response. - The client then uses this symmetric key / connection token when calling netcode_client_connect. - And you're done, you can now use the rest of the netcode APIs.
The second thing that you mentioned isn't required. The token is unique to the client already, so a server can confirm that it's a specific client connecting.
UDP provides no congestion control. Given the (lack of) quality of what gets developed for the browser, allowing it to send raw UDP would most likely cause an extraordinary amount of problems for the Internet as a whole.
> but realistically those generate only one event per second
How does that work with seeing other avatars walking around in real-time in for example WoW? Are their trajectory only updated once a second? In my game it's not really displayed in that way but I'm curious.
Servers can easily sync player positions once per second and the clients would happily interpolate between prev & current positions. You are probably seeing things a little late/different than server but it does not matter.
Would love a simple way to do client<->server udp from browser!
this is predicated on the fact that packet loss e.g. due to poor signal etc. is conflated with congestion in the network. this then results in tcp reverting to slow-start etc etc
My tweet from May 2015 is titled "I've sent my first UDP packet from a browser!" [1]
I did not write any extensions, I simply turned on an experimental flag for the TCP and UDP Socket API. [1]
In fact looking at other comments here it sounds like it's not hard at all.
One other problem with WebRTC at the moment though, it's not supported by Safari
- Yet another attempt to emulate a full OS-level network stack on top of HTTP (which already runs on top of TCP/IP).
- Giving random web-pages access to RAW OS-level networking, and not just sockets, from untrusted internet JS.
How incredibly ass backwards am I if I find both proposals preposterous and dangerous?
> One solution would be for Google to make it significantly easier for game developers to integrate WebRTC data channel support in their dedicated servers.
I'm confused. Since when did Google decide what was web-standards? Is he deliberately mistaking Google for being W3C?
> Yet another attempt to emulate a full OS-level network stack on top of HTTP
The proposed protocol does not work "on top of" HTTP. From the article:
> The basic idea is that the web backend performs authentication and when a client wants to play, it makes a REST call to obtain a connect token which is passed to the dedicated server as part of the connection handshake over UDP.
So both the handshake and the actual data transfer happen directly over UDP.
Next:
> Giving random web-pages access to RAW OS-level networking, and not just sockets, from untrusted internet JS.
The "Why not just let people send UDP?" section in the article actually explains why that would not be a good idea.
> It would greatly improve the networking of these games.
This is not accurate, i know it's like a rule of thumb that UDP is faster than TCP, but that's naive, there are cases where UDP will end up being slower, and to be honest, it depends on lots of variables, and at many times, the congestion control, packet ordering and all the bells and whistles that comes with TCP is well worth the little performance penalty, assuming that in that specific case it actually is slower than UDP
And of course if I'm wrong, someone will let me know :D
For example, if you are transmitting the position of some guy in a world, N times per second ... and you drop one particular packet ... that's fine, you just get the next one and you have more up-to-date information anyway.
TCP will block the entire connection when that packet is dropped, waiting until it is received again, and not giving any of the subsequent information to the application. This is bad in THREE different ways: (1) By the time the new position is received, it is old and we don't care about it any more anyway; (2) Subsequent position data was delayed waiting on that retransmit and now most of that data is junk too, EVEN THOUGH WE ACTUALLY RECEIVED IT IN TIME AND COULD HAVE ACTED ON IT, but nobody told the application; (3) Other data on the stream that had nothing to with the position was similarly delayed and is now mostly junk too (for example, positions of other guys in totally other places in the world).
It is hard to overstate how bad TCP is for this kind of application.
The main exception is low-number-of-player token-ring style games like RTSs with tons of units. Those usually simulate in lockstep, with the full state of the world extrapolated from inputs that consist of a very small amount of data. This means network traffic is relatively low, but in order for this to work you have to have complete knowledge of everything and exactly when it happened, which means no packet loss can be accepted and everything must be processed in order. So then you have the same kinds of problems as with TCP (even if the underlying transmission is via some other protocol) ... thus these games operate with some large amount of latency to hide these problems.
But, this network design is only the case for a minority of games. Just about any modern multiplayer game that is drop-in/drop-out, where the developers really care about quality of experience, is better off going UDP. (This is not to say that developers always do the best thing, since it's much easier to just say screw it and talk over TCP and call it a day. The temptation to do this is heightened because of all kinds of problems with NAT punchthrough and whatnot; because so much traffic is Web-oriented these days lots of routers mainly care about that, which causes all kinds of interesting annoyances. Thus games that do talk over UDP generally fall back to TCP if they are unable to initiate a UDP connection).
Well, there is one other case of games that run in lockstep, which is when they are console games made by developers who want to avoid incurring the costs of running servers (which are often much higher on consoles because the platform holder charges you out the nose). When you are running in lockstep like that it is more like the RTS scenario above, and thus it doesn't matter much if you use TCP because you are already taking the quality hit. But this is a cost-cutting kind of decision, not an it's-best-for-gameplay kind of decision.
P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
You misundrestood what I'm talking about, I'm not talking about the camera position, I'm talking about different games like turn based games, chess, board games, etc..
Lockstep is out of the scope here, surely not needed in a chess game. I'm talking deterministic games here.
> What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
Again, out of scope, I'm saying UDP is not the answer to all games and the assumption that if a game is networked then you should go with UDP is naive as I'm trying to say, forget open world, forget FPS, think about a simple turn based game.
> P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
Where did I call anyone naive ? thre's a difference saying you're naive and saying "the assumption is naive" I do believe i know enough that's why I'm commenting in the first place, even though I stated I might be wrong about some points, I did not personally call anyone names, go back and read my comments.
The point of engineering is to solve actual hard problems.
There is a reason Webrtc exists.
The only thing that makes UDP faster is that it comes without TCP's convenience features, and for many games, this is more than enough and the performance penalty is not usually worth it (unless you're a AAA with lots of resources and dedicated team just for the networking part)
besides that if you simply opt-in to UDP because it's better, then you'll spend much more time working on the network than actually working on the game.
my problem was with the generalisation in the premise, that `UDP is better than TCP for networked games`, this is not the case for a deterministic game of chess or any card/board game.
UDP's only point in this article is realtime data intensive games like FPS'es.
also I'm not putting security into consideration in this argument.
What's your thoughts ?
then you are almost reimplementing TCP over UDP again
For these reasons, TCP suffers a lot more if the network is bad. You really don't need to be a AAA company to implement TCP features on UDP.
UDP's only point in this article is realtime data intensive games like FPS'es.
> It would greatly improve the networking of these games.
And 'these games' are he means real time games like agario. It is not a FPS but it is a real time game. There is no reason to use UDP if it is a turn based game, like a card game. But a real time is pretty much always would be better with UDP
Yeah you don't need to be a AAA for sure, i was exaggerating a bit to make my point, what i'm trying to say is that newcomers to gamedev will end up struggling, TCP isn't easy, neither is UDP, without proper understanding of both protocols there will surely be mistakes made.
I do agree with the article 100%, I'm not saying in that use case that TCP is better, I'm just disagreeing with the premise as it's a bit vague and implies that you know what agar.io and slither.io are, I know both games and i know they're realtime, but there are people out there who don't know what they are, so I'm saying that just thinking that UDP is faster than TCP so it's best for networked games is naive, a better way to say it is just mentioning that this is for realtime games, better yet realtime games that can't allow network delays and are not critical, WOW for example uses TCP for some parts of the game that are not critical, where player position doesn't really affect the game, they end up with huge latency now and then, but the game is programmed in a way that some latency won't matter. in other cases they use UDP, that's also one of my reasons to say that UDP is not the only answer.
So yes, you are 100% right, and the article is 100% right, I just don't like the premise (the way it was written at least)
Unfortunately, all the alternatives (SCTP etc etc) seem to have foundered, probably due to aggressive filtering by border routers/firewalls making it impossible for alternative protocols to gain traction.
1- UDP is not always the answer, don't overcomplicate things, I'm trying to say that there are games like chess,board games, basically deterministic games that are not realtime. it is very wrong to use UDP for that game style, it's just a huge overkill.
2- UDP can in fact be slower for some use cases than TCP, there are lots of variables and unknowns.
3- Just opting into UDP because "it's faster" is very wrong, before jumping to UDP, there is a whole lot of networking theory that needs to be learned, and I'm not concerned about AAA here, I'm concerned about new beginners and indies that will read this post and think that this is the only right way to do things.
4- UDP is filtered on some networks still, you'll lose some players
5- If your network is so bad that TCP is not fast enough or that older packets are blocking newer ones, it'll be the same with UDP, packets will come in mangled and out of order, ant the game's "Quality" will still be bad with your avatar flying all over the place. until the developer implements a way to reorder packets, which is still more work.
6- I'm not a network professional, neither are lots of people. and if you don't have a strong knowledge to make sure your game's networking is in top shape you might end up making mistakes that will cost to fix.
7- The premise that UDP is going to greatly improve the game networking is naive (It's ok to call things naive by the way, don't be too sensitive) I'm a big fan of gafferongames, there are tons of great resources there, I'm only saying the premise is naive, not the person who wrote it. of course the author knows what they're talking about and I do understand they mainly target RTC and games like agar.io, I would want them to state more clearly that this is only valid for non deterministic, RTC, FPS, whatever you call it. for other cases, it's not the best.
8- Security wise, I'm not sure how easy it is to secrue a UDP conection, but it's surely not straightforward and easy as TCP with SSL for example.
Finally, there is never one true answer to your project's networking technology, lots of developers mix and match between TCP, UDP to get best of both worlds I would just say use whatever works best for you as long as you have enough knowledge and good reasoning to back your decision on what to use!
cheers