Menu
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>
806
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.
141
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
