Multi Player game using Nodejs and Socket IO

I am trying out multi player racing game using Node and Socket IO ,express . So I have tried simple example to see the latency between node server and the clients. I have a draggable image in client . when I move the image ienter code heren one client ,it has to move in all clients. so basically when I am moving the image I am sending the image position to the node server in a json format , then from there I am broadcasting to all clients. there is a ~approx 300ms latency from the time. following are the results.

Client 1 sending data to server at : 286136 (timestamp) Server received at : 286271

Client2 received data at : 286470 Client3 received data at : 286479 Client4 received data at : 286487 Client5 received data at : 286520

the latency between move from client1 to client5 is 384ms. its too hight for a racing game .. here is my server code.

var app = require('express').createServer();  
var io = require('socket.io');  
var http = require('http');  
var http_server = http.createServer();  
var server = http.createServer(app);  
server.listen(3000);  

var socket = io.listen(server,{ log: false });

socket.sockets.on('connection', function (client) {    
  client.on('message', function (data){  
        console.log("data arrived to server",new Date().getTime());  
// Below  both statements are giving same latency between the client 1 and client 5  
        client.broadcast.emit('message',data);    
        //socket.sockets.emit('message',data);  
  });  
});

1) Is there any way to optimize the server code to reduce the latency?
2) is this expected latency using node and websockets ?
3) is socket io can't broadcast the data asynchronously (I mean at a same time) ?

Thanks Kishorevarma

Solution

I have created a couple real-time games like this. One was multi-player Asteroids (everyone was shooting at the asteroids, co-op play). I had great response time -- BUT, I was NOT "spamming" all clients with too much data -- this may be a problem. I got the game to run at 60 fps on the client with the server processing the physics at 30 fps. It only worked when all clients were Chrome (so they had web-sockets). Most browsers today support web sockets. I would check to make sure you have sockets first. Second, I wouldn't send too much data to all clients: One way is to process the physics on the server at a known rate (like 30 frames-per-second). Also, be processing the physics on the client. Send end-user-changes to all clients on the 30 fps boundary (not when you get the data). For asteroids this means: Each client AND the server knows the following:

Where every player-ship is, and everything about that ship (facing direction, floating direction, if boost is on or off)
Where every bullet is (location, direction, velocity, who fired it)
Where every asteroid is (location, direction, velocity)
30 times a second, run physics, repaint screen

Now ...

When a client gives you a request (like, rotate my ship to the right) -- the client sends that data to the server (and does NOT process it locally)
When the server gets a user-request, it queues the request up to be processed next "tick"
The server tick (30 times a second): Process all queued events:
On a request to rotate a ship: Actually rotate the ship. Broadcast the ship data to everyone (location, facing-direction, velocity ...)
When a client gets a update-event from the server, it crams that new "correct" data from the server into it's local space. Note: If a client can't process everything at 30 fps, the ships will "jump" to their correct locations when the data is sent.