Using Socket.IO behind a Cisco CSS load balancer

[Gerbert Nuijen]

Hi,

I am running socket.io in my project and it is working perfect in our
test environment where it uses chrome websockets (all our clients use
chrome). Our production and staging environment are actually behind a
Cisco ASA 5500 unlimited content loadbalancer and that somehow seems
to break the use of websockets and socket.io falls back to xhr-
polling. Although the xhr-polling works fine I am still very curious
why it does not use websockets.

Does anyone know of a possible reason why it should not work behind a
loadbalancer?

regards,
Gerbert Nuijen

[Gerbert Nuijen]

Hmm oke, after seeing problems with 0.9.1 and other versions I did a downgrade to 0.9.0 and set the following options:

io.set('heartbeat interval', 20);

io.set('heartbeat timeout', 60);

And now it works behind the load balancer! So maybe it was simply a wrong version or something else. 

-Gerbert 

Op woensdag 7 maart 2012 16:34:58 UTC+1 schreef Gerbert Nuijen het volgende:

[Gerbert Nuijen]

This problem is solved.

Op woensdag 7 maart 2012 16:34:58 UTC+1 schreef Gerbert Nuijen het volgende:

Hi,

[Erich Buri]

Can you tell us how you solved it?

[Javier Viola]

may be a fixup in the asa??

2012/3/9 Erich Buri <erich...@gmail.com>

[Gerbert Nuijen]

Well, it is partly solved. 50% of time is successfully opens a secure websocket, the other 50% it just connects to the server print outs:

Something like this:

   debug - client authorized

   info  - handshake authorized 2924316021191888523

and then you would expect a get like this, but that never happens:

   debug - setting request GET /socket.io/1/websocket/2924316021191888523

I am not really sure what is wrong yet.  

Op vrijdag 9 maart 2012 15:00:23 UTC+1 schreef pepo het volgende:

may be a fixup in the asa??

2012/3/9 Erich Buri <xxxx>

Can you tell us how you solved it?

[Gerbert Nuijen]

So finally got it really solved, after solving it first partially where it worked only for 50% of the requests. In the end it was a misconfiguration of the loadbalancer. In the words of the network engineer: 

I made sure that the service for the port 9001 policy had port 9001 specifically allocated instead of the default all traffic ( which normally doesnt have to be defined )

Well I am not really sure what it means, I am no expert on hardware load balancers. But it might help others.  

regards, 

Gerbert Nuijen

[Łukasz Michalski]

W dniu 2012-03-09 16:22, Gerbert Nuijen pisze:

> Well, it is partly solved. 50% of time is successfully opens a secure
> websocket, the other 50% it just connects to the server print outs:
>
> Something like this:
> debug - client authorized
> info - handshake authorized 2924316021191888523
>

Are you using the same browser for all tests? I had such issue with
flash transport.

Regards,
Łukasz

[Gerbert Nuijen]

Hi, 

It works now for most popular browsers (except IE which we do not test and support at all). 

I believe flash uses a different port. According to wiki:

flash policy port defaults to 10843

• By default the Socket.IO client will check port 10843 on your server to see if flashsocket connections are allowed. The Adobe Flash Player normally uses 843 as default port, but we decided to default to a non root port.

Did you configure that port as well?

regards, 

Gerbert Nuijen

2012/3/24 Łukasz Michalski <l...@zork.pl>

[Lukasz Michalski]

On 03/25/12 09:39, Gerbert Nuijen wrote:
> Hi,
>
> It works now for most popular browsers (except IE which we do not test
> and support at all).
>
> I believe flash uses a different port. According to wiki:
>

> *flash policy port* defaults to |10843|
>
> * By default the Socket.IO client will check port 10843 on your server

> to see if flashsocket connections are allowed. The Adobe Flash
> Player normally uses 843 as default port, but we decided to default
> to a non root port.
>
> Did you configure that port as well?
>

My socket.io setup works well with xhr, flash and websockets on single
port now. I am using haproxy for load balancing and request routing.
I was asking because I had the similar issue with flash sockets. On node
side I saw:

> debug - client authorized
> info - handshake authorized 2924316021191888523

And this was a problem with flash asking for flash policy file on HTTP
port and this request was dropped by haproxy.

Regards,
Łukasz