Node.js UDP for realtime multi-player game

11,475

Solution 1

Generally, browsers do not support UDP connections. Specifically, some browsers do. Google Chrome has a socket api:

http://developer.chrome.com/trunk/apps/socket.html

[2012/10/29 Edited as socket is no longer experimental - PhilH]

You could possibly also use socket APIs from the native client interfaces as well (not sure, only guessing).

If you're going try to do anything real-time on browsers in the near future, Websockets is probably your best bet, but those are TCP only.

Regarding your comments on UDP versus TCP speed, UDP will always be faster. TCP offers ordering and delivery guarantees (this means possible retries and holding other packets back until a lost packet finally arrives at its destination), while UDP only promises to send it once, not caring what happens with it afterwards. UDP will only send it's packet once and you need to figure out whether it got lost. When/if you receive lots of UDP packets, if order matters, you need to encode this in your data payload to be able to figure it out.

In general, UDP will be great for packets where missing a few usually do not matter and where only the latest packet really matters. A game may typically use a TCP stream where ordering and guaranteed delivery matters (the important stuff), and UDP streams for object movements etc (where only the latest position really matters, and if one update got lost it does not matter as long as each package contain the full position [instead of a delta where all packets matter]).

For your own game, I suggest implementing it on TCP first, and then when you have some more experience, you can try move the time critical stuff (where order and lost packets matter less) into separate UDP streams. There are many projects that have failed because people started with UDP first, and then tried bolting on ordering and delivery guarantees on top of it, effectively trying to reimplement TCP. Which is why doing it the other way around makes more sense.

Solution 2

A realtime application is generally one that receives data updates of at least 30 Hz and with less than 10% jitter. TCP/IP is reliable but can’t send periodic updates at that rate without jitter going off the scale occasionally. This is because TCP is handshaking and acknowledging to ensure reliable transmission which gets in the way of sending fast periodically smooth updates. UDP is a simpler protocol where the socket data is fire and forget. This is itself a problem but that problem is easier to overcome than the poor jitter of TCP/IP. In my experience UDP is the only way forward and why real-time applications use it inside protocols such as RTP used in VoIP.

Web Sockets are false hope as well since that is a TCP-based protocol. I use custom UDP sockets where the sender and receiver maintain a sequence number and that can tell you if packets are lost, duplicated or out of sequence, all problems on WAN networks. Find ways to use UDP and instrument the inbound data packets to measure performance.

Share:
11,475

Related videos on Youtube

RobotEyes
Author by

RobotEyes

Updated on September 15, 2022

Comments

  • RobotEyes
    RobotEyes about 1 year

    I am building a real-time multi-player browser-based game using node.js. At the moment I have the client send user input to the game logic server via socket.io and a snapshot of the game world sent back to the client for rendering.

    Below is a simplified version of the code. Is it possible to use UDP to send data from the browser-based client to the server and vice-versa? I know Node.js has a UDP module but I am unsure how to implement it in this way.

    Any help would be appreciated. Thank you.

    Server:

    var server = http.createServer(handler).listen(8888);
    var iosocket = io.listen(server);
    
    // request/response handler
    function handler(req, res){
    
        ...
    }
    
    iosocket.sockets.on('connection', function(socket){
        console.log("[x] Socket listener started");
    
        socket.on('msg', function(data){
            console.log( " [-] incoming message);
        });
    });
    
    ...
    
    iosocket.sockets.emit("message", msg);
    

    Client:

    <!DOCTYPE html>
    <html>
        <head>
            <title>Test</title>
            <script type="text/javascript" src="/socket.io/socket.io.js"></script>
            <script type="text/javascript">
                socket.on('connect', function(){
                 console.log("connected to server");
                });
    
                socket.on('message', function(message){
                console.log('received message');
                });
    
            </script>
        </head>
    
        <body>
            <canvas id='canvas' width="400" height="400">Canvas</canvas>
        </body>
    
    </html>
    
    • freakish
      freakish over 11 years
      You can't. Browsers only support HTTP. Some of them support WebSockets as well (other can emulate WebSockets with Flash XMLSocket). And that's it. BTW: why UDP? Using TCP (i.e. WebSockets) is more reliable.
    • RobotEyes
      RobotEyes over 11 years
      @freakish I was going for speed rather than reliability after reading various articles on the subject of UDP vs TCP... I guess they weren't talking about browser based games then?
    • freakish
      freakish over 11 years
      Well, it depends on what kind of game you are actually building. If you intend to make another Quake in browser, then maybe you should forget about it. :) On the other hand if you don't need to make lots of snapshots per second, then TCP is more then enough. Finally note that some really great games still use TCP, for example: World of Warcraft.
    • Spencer
      Spencer over 9 years
      @freakish World of Warcraft can barely be considered a realtime game, honestly. If you're designing a game with projectiles or moving hitboxes then you almost definitely want UDP in some form, with TCP mixed in for things that aren't as time sensitive. If you're going to make a game where attacking is based on facing a direction, pressing a key and waiting a second (WoW) then TCP is probably fine.
  • Seth Noble
    Seth Noble over 11 years
    Generally a good answer, but note that TCP is not built on top of UDP: both are built on top of IP datagrams. UDP just adds very little on top of IP other than the port number. This distinction matters because TCP ports and UDP ports are in a separate number space. For example, TCP port 80 is completely different and unrelated to UDP port 80.
  • RobotEyes
    RobotEyes over 11 years
    @SethNoble & Marius. If i'm sending game world snapshots from the server to clients at a rate of 20 per second is TCP going to cause problems at the client's end? Do the techniques such as entity interpolation, client-side prediction and lag compensation still apply to TCP as they would to UDP? Thanks.
  • Marius Kjeldahl
    Marius Kjeldahl over 11 years
    Yoshima, that depends on many things, like bandwidth and latency between sender and receiver. Unless you're on a LAN, you need to decouple your view update framerate with the "network framerate". Advanced techniques will attempt to detect and adapt to whatever the conditions are (reducing updates to fit bandwidth and latency).
  • Seth Noble
    Seth Noble over 11 years
    In addition to what Marius said, remember that if TCP becomes delayed due to packet retransmission or flow-control, all of the delayed messages will pile up and get delivered all at once. So you may need a mechanism to "catch-up" and discard stale information. This even applies to UDP, but will be more noticeable with TCP.
  • Spencer
    Spencer over 9 years
    NEVER use TCP for networked games unless it is a turn based RPG. Even then.... reconsider. gafferongames.com/networking-for-game-programmers/udp-vs-tcp