Sticky Session behavior - sometime long polling

[Klaus Baumecker]

Since a while I'm using SocketStream on Stackato (= CloudFoundry compatible PaaS).

In order to support the web-socket transport I had to configure the Stackato router to load-balance multiple instances based on sessions.

The way of doing this is to let the router know, what the session cookie is. Unfortunately there is no way in SocketStream the specify a cookie name for that. That's why I used the one created by connect. That is "connect.sid"

After configuring the router and creating two parallel running socketstream web servers, it seems to work fine.

What's strange is that after each reload of the page (init the client) the protocol flips between pure web-socket connection and long polling.

There are no errors in the server.

Has someone else made experiences/recommendations using sticky sessions with web-sockets and how to configure the router properly.

I'm a bit nervous, that SocketStream is behind the latest web-socket versions and no update is planned yet. 

Has someone updated engine.io/socket.io in the current socket stream lib?

Regards,

klaus

[Wylie JoshuaCullick]

Hi Klaus,
Maybe somewhat my responsibility here because I last updated the engineIo . So , which version are you on ?
---wjc

[Wylie JoshuaCullick]

( Which version of SocketStream )
(Why does GoogleGroups UI , chat message threading UI suck so ?  ( can't even edit a message . . I think is critical feature ))() . 

[Klaus Baumecker]

Hi,

I think I was not clear with my last question. What I meant was, if someone already tried to use a newer version of engine.io, because the one I'm using is pretty old. That is the one in the current version of socketstream in the npm repo. I saw you already updated socketstream to a newer version on github.Is that already released to npm?

/klaus

[Klaus Baumecker]

I did some tests with the latest bits of socketstream from master.

The behavior is unchanged and seems an engine.io related topic:

What we did: we specified the connect.sid cookie as the hook for sticky sessions

What we observe: 

- The sessions remain sticky, which is good. 

- With each reload (F5) the client flips between long-polling and a true web-socket connection. Looking closer it turns out, that the client makes an engine.io request for upgrading the protocol, which does not return. Therefore the server remains in long-polling mode.

I wonder if sticky sessions work at all reliably with engine.io?

Any experiences/advice?

/klaus

[Wylie JoshuaCullick]

Thanks for the testing Klaus (a process which we'd like to normalize with e2e testing for every progression),  I'm going to look into this sometime today and report back some thoughts / findings .  A full picture maybe not emerge immediately; will need to return to it over the week.  I'm unfortunately / fortunately (!) very busy with my day job.

[Wylie JoshuaCullick]

I'm looking through it for a bit now, then will do some more tomorrow.  I want to make sure interactingg correctly with engineIo API.

Klaus (interested in many views on this so others also respond), can you describe your system for monitoring the state of the websocket/polling connection ?  I'd like to survey to find best/good-practice, then be able to make some programmatic routine for the e2e with headless browser.

[Weber A.]

I'm a coworker of Klaus.

We don't have a piece of software to check the connection type. We just look into the network tab of the browser dev tools.