Make connections sticky to a node instance behind the LB

[crzidea]

To support socketio/engine.io#207
Load balancers can use worker id to target a specific node instance behind the LB.

[mokesmokes]

Frankly I don't see great utility in supporting LB schemes that are relevant for one physical machine only. Plus the cluster functionality is labeled "experimental", and actually gets in the way when wanting to scale across machines. How many apps and PAAS are actually using the cluster functionality?

[crzidea]

@mokesmokes

1. How many apps or PAAS do not support cluster functionality
2. workerId is just a flag you set to the node instance, not only cluster worker id.
3. nginx users can easily LB their node instances using the following config:

http {
    upstream channel- {
        server 127.0.0.1:3000;
        server 127.0.0.1:3001;
    }

    upstream channel-1 { server 127.0.0.1:3000; }
    upstream channel-2 { server 127.0.0.1:3001; }
    server {
        listen       8000;
        location / {
            proxy_pass http://channel-$arg_wid;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_read_timeout 120;
        }
    }
}

I understand you are not using nginx or haproxy at the time, but you should know how many users are using them.

[mokesmokes]

This PR still doesn't work as advertised since you're not targeting the initial socket open request (and the following reconnections) - so it's currently an attempt at "sticky connections" rather than connection targeting.

[crzidea]

@mokesmokes Initial socket open request doesn't need to targeting. It should be targeted by load balancer. What you mean about connection targeting?

[crzidea]

@mokesmokes I have updated PR title.

[mokesmokes]

@crzidea take a look at my PR for what I mean. LB is normally a dumb beast that has no clue about the application, and frequently we app devs have no control over it a priori (e.g. in PAAS deployments). In my app, for instance, I tell the client which server to hit (i.e. which server has his "app context" active) - I can't leave this decision to the LB which has no clue. Making these decisions "intelligently" instead of relying on LB's load balancing makes a huge difference in scalability. Thus to "target" connections one must take care also of all open requests.
In any case, LBs today have sticky sessions I'm not sure what is the new functionality introduced by this PR.

[crzidea]

@mokesmokes This is third time I tell you cookies was not supported with cross domain JSONP even by IE10. I'm dealing with it.

[mokesmokes]

You don't need cookies to support sticky sessions. You can also stick the session to a specific client IP address and this is how it's often done.

[crzidea]

@mokesmokes That is not reliable. And we have to test it with 1M clients connections on a sigle 64G memory machine. IP based load balancing just targeting all of them to one node instance.That is a terrible way.

[crzidea]

Already solved with following way:
socketio/engine.io#207 (comment)