Develop Reference

Node JS how to limit maximum number of sockets

is it possibile to set the maximum number of sockets that my server can handle? Something like: maxSocket = 2 and from the 3 attempt of a socket to connect automatically refuse that connection?
Thanks

The default maxSockets value is Infinity and it determines the limit of number of sockets per host. See official docs: https://nodejs.org/api/http.html#http_agent_maxsockets
You can manually set maxSockets limit using the following code snippet
require('http').globalAgent.maxSockets = 10
globalAgent: Global instance of Agent which is used as the default for all HTTP client requests.

In Node.js, you can set the maximum number of connections per origin.
If maxSockets is set, the low-level HTTP client queues requests and
assigns them to sockets as they become available.
Ref URL from AWS JS SDK
According to Node.js Doc,
By default set to Infinity. Determines how many concurrent sockets the
agent can have open per origin. Origin is either a 'host:port' or
'host:port:localAddress' combination.
Conventionally, they recommend 25~50, I guess.

Update socket.connected Socket.IO immediately when network down

Currently, I want to check status of socket when network is down with connected property. But i have an issue when unplug network cable, the connected status still true for 20 seconds or more. How can i get the status immediately ?

You'll have to set the timeout option, which by default is set to 20.000 MS (20 seconds). You can find a lot of information here: http://socket.io/docs/client-api/#
I would disrecommend making it absolutely instant though. Most if not all networks have some instabilities, which are accounted for by the timeout delay. It's there for a good reason. Maybe just make it a bit shorter?

Inconsistent Date.now() values

I built an HTML5 multiplayer game that depends on having a reasonably accurate time sync between server and client. For the most part, the algorithm I use is very accurate -- all it does is estimate what the client-server time delta is, i.e. the difference between the current time on the server and the current time on client. For example, if the server time is exactly 5 seconds ahead of the client time, the time delta is 5000 ms.
The client and server (node.js) are both written in Javascript. The algorithm works as follows:
Record time on the client:
var clientTime = Date.now();
Ping the server. When the server receives the message, it immediately sends a response containing just one thing: the time on the server when the message was received.
var serverTime = Date.now();
// Send serverTime to the client
When the client receives the server response, immediately record the time:
var clientTime2 = Date.now();
Now, we know that when the server received the message, the client time must have been somewhere between clientTime and clientTime2.
If the server received the message when client time was clientTime (i.e. client->server request took 0ms somehow), then the time delta is
var delta1 = (serverTime - clientTime);
If the server received the message when client time was clientTime (i.e. server->client response took 0ms somehow), then the time delta is
var delta2 = (serverTime - clientTime2).
Thus we can safely say that the time delta is somewhere between delta1 and delta2. Now, repeat this process a bunch of times, each time narrowing the range based on whatever results you got, and you can get a pretty good estimate of the time delta.
I've tested this hundreds of times on 7 different browsers and multiple machines and have never had any issue with it. It's never been inconsistent.
The issue, though, is that my server logs show that, every now and then, a few people will get wildly inconsistent time sync results. Here is an actual example of one player's time sync:
The client went through 74 cycles of the above algorithm and successfully narrow the range of possible time deltas to: [-186460, -186431] without a single inconsistency. 29ms accuracy.
On the 75th cycle, possibly a few seconds after the 74th cycle, the client calculated the range of possible time deltas to be: [-601, -596]. 5ms accuracy, except for it's extremely inconsistent with the past 74 cycles: it's 3 minutes off!
I would blame this on crazy edge cases, except it happens almost 100 times a day... how could this happen? Is there any possible error when using Date.now()?

performance.now() instead of Date.now(), because performance.now() is monotonically increasing and not subject to clock drift. See the comments, thanks to everyone for their help!

Your difficulty is that you depend on estimating round-trip times to the server, over an Internet that has variance in round-trip times. Sometimes that variance will be unexpectedly substantial, as in cases where temporary congestion and large router buffers delay a single message far longer than normal. (Cf "bufferbloat".)
Your second difficulty is that you are using self-reported client times, and that means that if a client has a clock that's weird it will look to you like a round-trip estimation gone wrong. As another poster noted, internet time protocols will sometimes slew a clock rapidly to correct from local timekeeping anomalies.
What it sounds like is that you need some filtering in your code that takes into account previous results so that when you get an anomalous result you don't immediately accept it as true.

Socket.IO - How to change timeout value option on client side?

I use Socket.IO 0.9.16 to establish a connection:
io.connect(url)
However, when the server dies, it takes 2 minutes timeout to detect error with the server.
I already tried to reduce timeout to 5s by setting:
io.connect(url, {'timeout': 5000, 'connect_timeout': 5000})
But no success... How can I do this?

The challenge here is that there are a bunch of different settings that interact with each other and some retry logic that all make a socket.io timeout not what you would normally expect. I should add that I am familiar with socket.io 1.0+, not 0.9 though this probably applies to both.
Lets review how a socket.io connection works.
It attempts to make the initial connection.
If that succeeds, then you're done with the connection.
If that connection attempt does not return immediately, it will wait the timeout value that you pass in the initial options for a connection result.
If your server is down, the connection attempt will likely fail quickly. This will result in a connect_error and if you register for that message on the socket with socket.on('connect_error', function() {...});, you will see that connect_error event.
This connect_error is not a timeout. So, if the connection fails quickly (which it usually does when the server is just down), then you never get the regular timeout and the timeout argument you pass to io({timeout: 5000}) really doesn't come into effect. That only comes into effect when a connection to a server is just taking a long time (like an overly busy server or a server that accepted the TCP connection, but is really slow at responding). This is not usually what happens when a server is just down or unreachable.
So, after socket.io gets a connect_error it marks this socket.io connection for retry.
The delay before retrying is based on a whole bunch of things. Presumably, the reconnectionDelay option is part of the formula, but in looking at the code, there is also a backoff algorithm that lengthens the time between retries the more times it has retried. So, suffice it to say, there's some algorithm that calculates a given delay before retrying that varies for each retry.
Then, after that calculated delay, it tries to connect again. This essentially repeats the process starting at step 1 again.
As best I can tell, by default it keeps retrying forever. There is an option you can pass reconnectionAttempts that specifies the maximum number of reconnection attempts. This default to infinity if you don't pass it. But, if you pass 10, then it will give up after 10 successive connection failures.
If you specify reconnectionAttempts, then after that many unsuccessful connection attempts, you will get a reconnect_failed event on the socket and it will give up.
As best I can tell, there is no traditional timeout in the way that you are looking for where it would connect, attempt some retries, then give up after x amount of time. The timeout option applies only to a single reconnect attempt and not to the total amount of time it keeps trying to connect.
In a sample test page I've been experimenting with, I was able to implement my own traditional connection timeout like this:
var socket = io(...);
// set connect timer to 5 seconds
socket._connectTimer = setTimeout(function() {
socket.close();
}, 5000);
socket.on('connect', function() {
// socket connected successfully, clear the timer
clearTimeout(socket._connectTimer);
});
This will wait a maximum of 5 seconds for a successful connection, regardless of how long a connection attempt takes or many reconnect attempts occur in that span of time. After 5 seconds without a successful connection, it shuts down the socket.
In my test app, I can see socket.io happily retrying the connection over and over again until after 5 seconds, my timer fires, I get notified of the "timeout" and I close the socket and it stops trying to retry any more.

I think it is connect timeout
io.connect(url, {'timeout':5000, 'connect timeout': 5000})

Socket IO detect when client has lost connection

I need to be able to detect when a user has lost connection to the socket, it doesn't seem that socket.on("disconnect") is being called when I just close my laptop, so it doesn't run the ajax call that needs to run in order to update the database to mark the user as offline. How could I check if the connection has been closed or whatever?

As mentioned here https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO, Socket.IO has it's own heartbeat implementation.
But the defaults are a 25s interval and a 60s threshold for a lost connection.
So my advice: Set the defaults as you expect on testing. Otherwise you may miss the threshold.
Example:
socket.set("heartbeat timeout", 10);
socket.set("heartbeat interval", 5);

we came across this too and as mentioned above use our own heartbeat timer.
For example the server will emit a heartbeat every 5 seconds (we simple send out server time). The client has an 11 second timeout so it has 2 chances to catch the heartbeat. If it receives the heartbeat we reset the timer. If we miss both heartbeats the timeout function is run and you do whatever you want there.
Fairly straightforward.