Using Primus.io (websockets) behind AWS Elastic Load Balancer

0
votes

I am trying to setup an Elastic load balancer to route requests to a cluster of node.js servers running Primus.io with sockjs to manage real time communications.

I have set up the load balancer to listen with the following configuration:

  • HTTPS 8084 -> HTTPS 8084 (The port used on my node.js servers)
  • SSL 443 -> TCP 80

My understanding is that the only way to get websockets to work through ELB is via SSL->TCP, hence the above configuration.

I have correctly enabled the new proxy protocol for ELB as described here:

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html

When trying to connect to the server from a client an HTTPS request is initially sent and then from what I can gather it should be upgraded to websockets. But the request is simply failing when I send it to the loadbalancer address.

If I send the initial Primus connection request to the ip of a single nodejs server like so:

var primus = new Primus('https://ip.address.of.single.server:8084');

The request is correctly returned and is upgraded to websockets correctly.

When I switch the ip address to that of the balancer, it fails and the initial https request to the node.js server returns nothing. I assume this means that the websocket transfer could not be established, but to be honest I have little experience in this area so could be completely wrong.

Does anyone have any idea what I am doing wrong?

Thanks in advance

1
amazon-web-serviceswebsocketload-balancingamazon-elb

1 Answers

1
votes

Do you have clustered your NodeJS-instances? For example, if you use SocketIO you should use a clustered session store. Actually, I'm also currently investigating the same with SockJS running on top of Vertx.

The problem behind is Amazon ELB won't respect any forwards in the past (in opposite to Sticky Session on top of HTTP) which means that a connections via TCP level can be forwarded at any cluster's node. Yes, one tcp channel would be okay. But frameworks like SocketIO do a little bit more to support sessions (does not exist in WebSockets) and multiple transport layers (http, polling, sockets, and so on).