17 ms·

A solution for enabling UDP in the web

• benaadams 10y ago
  Also includes alternative protocol implementation design and source for protocol. Would love a simple way to do client<->server udp from browser!
• daurnimator 10y ago
  > Additionally, the server enforces that only one client with a given IP address may be connected at any time So much for people behind carrier NATs
  • gafferongames 10y ago
    My bad: I meant IP address + port. Fixed in the article.
    • hueving 10y ago
      Well what good is that? You can't tell if multiple IP,port pairs are from a single client or multiple clients.
      • vishvananda 10y ago
        The nat device will have different source ports for two connected clients.
        • hueving 10y ago
          It would also have different source ports if the client is using random source ports as well. So two client connections from the same host behind NAT would look exactly the same as two client connections from two different hosts behind NAT.
          • gafferongames 10y ago
            Hence the authentication on the web backend and the unique 64bit client id.
      • deleted 10y ago
        [deleted]
• peterwwillis 10y ago
  Answer: a browser was for traversing hypertext documents. UDP basically is not good for this. Now a browser is just an abstracted operating system. So, fuck it, I guess, let's add a second TCP/IP stack.
  • poop_cicle 10y ago
    Naivety here is appalling.
  • benaadams 10y ago
    More like TCP/IP is not good for data where only the current state is relevant and old state can be discarded: live video, games, stock prices... 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)
    • fulafel 10y ago
      Since the P2P feature set is a superset of the client-server feature set, it would only increase complexity in the browser to add another protocol for the client-server feature set.
    • dragonshed 10y ago
      ObjectRTC? That's a new one..
  • geofft 10y ago
    The browser is a much better multi-user operating system than the actual operating systems people tend to use. 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, defeating the entire point of memory protection. If the game and the tax app are in a browser (or in a mobile OS, to their credit), this isn't so. 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.
• daurnimator 10y ago
  Interesting idea I had: why not have many QUIC streams?
  • areed 10y ago
    Are you thinking one stream per packet?
    • endianswap 10y ago
      You could have a pool of them, right? Or would you have to actually tear it down after each packet
    • daurnimator 10y ago
      Maybe. Why not?
  • arkadiyt 10y ago
    This would be the same as having a single QUIC stream, since QUIC already supports multiple data streams. The author addresses that with "Unfortunately, while head of line blocking is eliminated across unrelated data streams, it still exists within each stream."
    • PeterisP 10y ago
      However, you could use a pool of x streams; when sending an update for the tick 't' then use the (t mod x)th stream, and thus if one stream becomes blocking for some time then you do receive the next update (since it's using a different stream) and you can treat it something as (1/x) rate of UDP packet loss.
  • awqrre 10y ago
    but QUIC uses UDP?
  • Matthias247 10y ago
    I think the only equivalent to UDP would be: 1 QUIC stream per packet, which avoids blocking inside a stream. I'm not into QUIC, but I guess creating and managing a (temporary) stream would have a lot more overhead than just sending an encrypted UDP packet. 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).
• poop_cicle 10y ago
  The use of libsodium looks absolutely brilliant. Would the author recommend using netcode.io for general games, not just agar.io or browser style stuff?
  • hach-que 10y ago
    I'm an external contributor who did the C# bindings for netcode.io available here: https://github.com/RedpointGames/netcode.io https://github.com/RedpointGames/netcode.io 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.
  • gafferongames 10y ago
    Yes, it would work great for client/server games, provided that you host dedicated servers and have a web backend to generate the connect tokens (this could be your matchmaker, for example).
• VengefulCynic 10y ago
  Obviously going out of his way to implement in a secure way as a software practitioner. I would love to see a review of the design and implementation from the standpoint of a security expert.
• just4suggest 10y ago
  My memory is fuzzy, but I'm pretty sure I did this with WebRTC a while ago. Use RTCPeerConnection in unreliable mode, "peer" with the server, and you should have a UDP-backed SCTP connection. I'll try to dig up my PoCs on this. 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.
  • benaadams 10y ago
    The WebRTC Data channel is still unavailable in Opera, Edge and Safari... :( https://developer.microsoft.com/en-us/microsoft-edge/platform/status/rtcdatachannels/?q=data%20channels https://developer.microsoft.com/en-us/microsoft-edge/platfor...
    • taf2 10y ago
      Opera works - Safari is working on it? At least in my case, we sell web based phone system and pretty much that means we don't target IE/Edge or Safari simply due to the lack of WebRTC.
    • daveorzach 10y ago
      Looks like it is coming to Safari soon https://bugs.webkit.org/show_bug.cgi?id=168858 https://bugs.webkit.org/show_bug.cgi?id=168858
  • mikekchar 10y ago
    >> 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'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.
• mjevans 10y ago
  I'd like to focus on the security issue of 'UDP probes and sending results back over HTTPS'. This is an /inherent security issue/ of running ANYONE else's code within a corporate network. ECMAscript/JavaScript should NOT be blindly run within corporate networks, and web 2.0 is insane for making all websites expect that.
  • michaelvoz 10y ago
    Can you elaborate on this? Legitimately curious.
    • bitexploder 10y ago
      It is allows malicious code to scan ports. It allows easy building of difficult to manage tunnels (never mind corkscrew and port 443 SSH servers breaking out of 90% of corp networks I have been on via their HTTP/S proxy)
      • michaelvoz 10y ago
        Is port scanning dangerous? How can JS in a browser build a tunnel to anything?
        • bmon 10y ago
          Port scanning itself is obviously not dangerous, however I believe the author is imagining a situation where a user on the other side of a corporate firewall views a webpage which then portscans from the inside then sends the results home/starts an attack on specific ports.
        • bitexploder 10y ago
          edit: To answer your direct question, port scanning is probably not /that/ dangerous. It is just information gathering. You almost always need to take steps after that. But if you can build a port scan you can build any other protocol up via this scheme (possibly even just proxy other UDP tools directly) and attack internal UDP services. It just seems like a glaring network hole considering how most corp LANs are set up. 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".
• dragonwriter 10y ago
  > Why can't I send UDP packets from a browser? You can, if the browser is Chrome: https://developer.chrome.com/apps/sockets_udp https://developer.chrome.com/apps/sockets_udp
  • Groxx 10y ago
    Worth noting this is using the "chrome.etc" object, which is only available to apps and/or extensions.
    • duskwuff 10y ago
      Which, at this point, just means extensions: https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
      • Groxx 10y ago
        There are still critical holes in the extension API that they haven't plugged, e.g. filesystem access (super duper important if you want to make an app that can edit / create images, for instance, and not want to shove everything into the downloads folder or force a chooser every time). I'm not sure how they're going to shut things down while crippling the ecosystem so severely (though to be fair, Firefox is doing a similar crippling-move (but for solid reasons, IMO)).
    • djsumdog 10y ago
      Firefox can do this via extensions as well. That's how the Beef fake flash update works (presents something that looks like it's a flash update that really installs a browser extension).
• techsupporter 10y ago
  Minor nit that I almost hesitate to pick but I've been doing 100-series network training lately so this is something that I'd tell my students: > 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.") 0 - https://tools.ietf.org/html/rfc4785 https://tools.ietf.org/html/rfc4785
  • thezilch 10y ago
    You're not wrong, but I think the point was, in a browser, you can get your TCP _connection_ "automatically" encrypted by connecting to HTTPS endpoints. It's not so easy -- "built in" -- with a connectionless protocol.
    • techsupporter 10y ago
      That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go. (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.)
• chatterbeak 10y ago
  You can send UDP packets from a compliant browser (basically, everyone except Apple) with WebRTC. I do it all the time, and our company has products that depend on this. The author of TFA dismissed this solution, but it does work, and is gaining support and use.
• throwawasiudy 10y ago
  It's kinda sad that TCP was chosen so long ago for HTTP that there's effectively no changing it. With modern TLS the underlying data guarantees TCP gives you just aren't that useful. We have kinda a weird situation where we have TCP->TLS->HTTP in layers when it could all be one protocol layer. We also wrap a stateless protocol (HTTP) inside a stateful (TCP) one which causes some insanity. 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.
  • jorblumesea 10y ago
    I'm not so sure the internet would have been as successful without the guaranteed transmission of tcp.
  • morecoffee 10y ago
    Perhaps the massive pervasiveness of the internet is not obvious on a day to day basis, but you should consider it when judging whether or not TCP was a good decision.
  • zmb_ 10y ago
    It makes sense to separate the problem into multiple different protocols, because that gives you re-usability and greatly reduces the complexity of implementation. Can you imagine the amount of effort if every application protocol defined its own mechanisms for retransmissions, congestion control, security, etc.? 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.
• gnu8 10y ago
  Why can't I DDoS an arbitrary host using nothing but twitter accounts?
• greggman 10y ago
  I'm not really sympathetic to the arguments against WebRTC. Ideally someone makes an open source library or 12, problem solved. 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
  • daveorzach 10y ago
    WebRTC will be enabled in Safari production builds shortly https://bugs.webkit.org/show_bug.cgi?id=168858 https://bugs.webkit.org/show_bug.cgi?id=168858
• yokohummer7 10y ago
  > Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers. > 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.
  • aidenn0 10y ago
    Yes this is the reason, but the message-based part is irrelevant. They need to use an existing http connection where both sides agree on the upgrade to prevent lots of possible security holes. 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.
    • yokohummer7 10y ago
      Yeah, but both parties can leverage the existing connection without resorting to a message-based protocol, can't they? They could just assume they're now sending and receiving bytes after the upgrade. 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.
      • 10y ago
• vans 10y ago
  Cool, another protocol which claims for security and a reference implementation in... C
• shurcooL 10y ago
  > Why can't I send UDP packets from a browser? My tweet from May 2015 is titled "I've sent my first UDP packet from a browser!" [1] [1] https://twitter.com/shurcooL/status/605218976969261056 https://twitter.com/shurcooL/status/605218976969261056
  • djsumdog 10y ago
    Looks like Firefox? Did you write a browser extension?
    • philo23 10y ago
      It's from Firefox OS: https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS/API/UDPSocket https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS/API/...
      • shurcooL 10y ago
        No, it was an experimental implementation of https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/ actually. Regular Firefox browser, not Firefox OS.
    • shurcooL 10y ago
      Yes, it was Firefox. I did not write any extensions, I simply turned on an experimental flag for the TCP and UDP Socket API. [1] [1] https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/
• mido22 10y ago
  can't understand this bashing of WebRTC, it is good technology, TURN config is optional is not compulsory, but believe STUN is still necessary because, unlike the public server, the client is behind NAT, but then again, setting up a TURN+STUN server is a trivial job...
  • ambrop7 10y ago
    Why would STUN be necessary if the client is behind NAT? So long as the server is not, the client can send the first packet and NATs will establish associations for the packets from the server to arrive to the client.
• Rapzid 10y ago
  Network congestion.
• Rapzid 10y ago
  Network congestion.
• mostafaberg 10y ago
  I kinda disagree with the premise about UDP: > 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
  • jblow 10y ago
    UDP provides massively better quality of service for realtime data wherein there aren't usually dependencies between particular pieces of data. 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.
    • mostafaberg 10y ago
      You are absolutely correct, but not all games are FPSes, I just think that the generalisation in the premise that UDP is better than TCP for networked games is naive, you have to put into consideration the type of game and what data is actually being sent.
      • jblow 10y ago
• nvarsj 10y ago
  Some things I noticed about the proposed protocol: - 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.
  • IshKebab 10y ago
    Presumably the keys are sent over HTTPS.
    • gafferongames 10y ago
      Yes, the connect token is transmitted from web backend to client over HTTPS. 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).
  • hach-que 10y ago
    The symmetric key / connection token is generated with netcode_generate_connect_token. This is normally done on your authentication server, which runs over normal HTTPS. Thus the workflow is basically like this: - Web browser connects to like https://auth.myapp.com 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.
• bborud 10y ago
  I think some of the ensuing discussion here says clearly why UDP in the browser (at least as in giving developers access to firing off random UDP packets from a browser) is a bad idea: people don't understand network protocols, yet they feel they have something to contribute to the discussion.
• signa11 10y ago
  on mobile devices or accessing internet through mobile network, i would wager that it is congestion control which causes more heartburn than head-of-line-blocking. 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
• deleted 10y ago
  [deleted]
• Kiro 10y ago
  Why enforce server limits? I'm building a multiplayer game where user actions can happen at most every 150 ms. Am I naive thinking that one server should be able to handle thousands of simultaneous users? I understand the limits when it comes to fast-paced games though.
  • Cthulhu_ 10y ago
    It depends. MMO's can generally handle thousands of users per second, but realistically those generate only one event per second. There's faster-paced games like Planetside and Battlefield which allow for hundreds of users per server though.
    • Kiro 10y ago
      Thanks! > 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.
      • shultays 10y ago
        Player position is not very critical in WoW or similar games. Combat is mostly selecting an enemy and attacking it. Or selecting enemy and casting a ranged spell. The game is designed with this server lag in the mind. 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.
• iamleppert 10y ago
  You could always use something like Electron if you can get users to download your app, which would allow you to use whatever node native networking libraries there are, I'm sure you could send UDP packets or anything else, and still use web technologies and the browser to develop your app/game.
  • iamleppert 10y ago
    Why was this down voted? lol its a legitimate solution..
• captainmuon 10y ago
  I believe the security model in browsers is fundamentally wrong. I understand why it evolved the way it did, but it is far from optimal. 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.
• CrLf 10y ago
  The article misses one important reason why allowing UDP from the browser is a bad idea: 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.
  • gafferongames 10y ago
    Games have been spamming UDP packets over the Internet for the last 20 years and the Internet seems to be doing OK.
• dolftax 10y ago
  Do the authentication over TCP and then fallback to UDP for rest of the communication? For encryption, have you considered DTLS? Read more in `Hybrid Implementation` section of http://ithare.com/udp-for-games-security-encryption-and-ddos-protection/ http://ithare.com/udp-for-games-security-encryption-and-ddos...
• machty 10y ago
  Could the "connect" token just be a JWT token?
• xg15 10y ago
  I think the title of the blog post is misleading. 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)
  • gafferongames 10y ago
    > 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). 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.
    • irq-1 10y ago
      Would a clear-text token, in addition to an encrypted connect token, allow servers to drop packets faster (since it wouldn't require decryption)? A clear token could be changed (cached, expired) however the back-end wanted, which would include dropping all new connection attempts when under DDOS. 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.
      • 10y ago
• josteink 10y ago
  So let me get this straight... Basically this guy is trying to champion one of two things: - 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?
  • deleted 10y ago
    [deleted]
  • scribu 10y ago
    I don't think you got it straight. > 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.
  • andrejk 10y ago
    He's not advocating either.. keep reading
• ungzd 10y ago
  Minecraft works great over TCP[1], so casual clickers like agar.io mentioned there, and most games except fast-paced shooters will work too. [1] http://wiki.vg/Protocol http://wiki.vg/Protocol
  • maxmcd 10y ago
    I like this take on UDP v TCP: https://1024monkeys.wordpress.com/2014/04/01/game-servers-udp-vs-tcp/ https://1024monkeys.wordpress.com/2014/04/01/game-servers-ud... 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.
  • amaranth 10y ago
    Minecraft "works" over TCP but I wouldn't call it great. TCP works great for things like block data since keeping those ordered makes it easy to send changes instead of resending whole chunks. On the other hand, entity movement being TCP is a real pain due to the head of line blocking which is one of the reasons PvP can be a pain and why it can be impossible to melee mobs without them hitting you first.
• bandrami 10y ago
  Because there's no such thing as UDP "packets"?
• api 10y ago
  > It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between browsers, WebRTC needs STUN, ICE and TURN support for NAT traversal and packet forwarding in the worst case. 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 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.
• stcredzero 10y ago
  I am using WebRTC with a MMO server cluster written in Golang. Basically, I got Simple-Peer WebRTC library to run on top of node-electron in NodeJS. My Golang coordinating server then also coordinates a farm of 4 NodeJS processes which basically run as UDP proxies. The complexity of WebRTC is tamed by Simple-Peer. 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.
  • pthatcherg 10y ago
    Are you using the data channel p2p or client-to-server? (I work on WebRTC and implemented much of the data channel; I'm always interested when someone uses it)
    • stcredzero 10y ago
      Client server. I'm being extra paranoid about cheating/security, so it's a naive client-server, authoritative server architecture. The client isn't much more than a dumb server, but for 2D sprites, not text.