Websocket unreliable on bad connections

[Andre Foeken]

We are in a country with rather nasty internet connections (loss,
latency) at the moment and to our surprise 90% of the faye push
messages never got to the browser. Safari seems most vulnerable,
Firefox blacks out sometimes (request 'aborted'), but chrome seems to
overcome all and function without a hitch.

I never realized the connection has such a major influence on Faye.
For now we disabled web sockets in the client which makes it work
flawlessly again. Can't faye downgrade to polling once it realizes the
web socket is not working?

We are using 0.7.1 again, since 0.8 is giving us problems in
production.

[James Coglan]

On 1 March 2012 21:33, Andre Foeken <acfo...@gmail.com> wrote:

We are in a country with rather nasty internet connections (loss,
latency) at the moment and to our surprise 90% of the faye push
messages never got to the browser. Safari seems most vulnerable,
Firefox blacks out sometimes (request 'aborted'), but chrome seems to
overcome all and function without a hitch.

I never realized the connection has such a major influence on Faye.
For now we disabled web sockets in the client which makes it work
flawlessly again. Can't faye downgrade to polling once it realizes the
web socket is not working?

Regarding your WebSocket problem: this is what disable('websocket') was designed for, though obviously better automated error detection would be good. Faye does fall back to other transports if WebSockets don't work, but the definition of 'not working' may need changing -- if it manages to make a connection, it assumes WebSockets are working. It might need to instead fall back if it doesn't receive replies to messages, for example.

I'd like you to find out the following for me -- you'll need to edit the JS client code for this. In browsers where WebSockets don't work:

* Does the WebSocket connection ever receive messages?

* When the client connects, how much time elapses between the `new WebSocket` call and the `onopen` event?

* When it disconnects, how long after the `onopen` event does `onclose` fire? Is this constant?

* Does the socket trigger the `onerror` event? What error code does it yield? (The argument to onerror is an error object with a `code` property in recent browsers)

Is it only broken in production, over the public internet, or do you also have problems in development on a local network? Is the problem likely due to bad proxies, or simple latency? I'm a little puzzled as to why WebSocket would be broken but HTTP would be snappy, unless proxies are messing with the socket connection?

Could you try the latest `master` version and run it with disable('websocket')? This will switch to the EventSource transport if your Faye server is on the same origin as the current page (check the connectionType of /meta/connect messages), and I'm curious to know if this works better for you. 

[James Coglan]

On 1 March 2012 22:35, James Coglan <jco...@gmail.com> wrote:

* Does the WebSocket connection ever receive messages?

* When the client connects, how much time elapses between the `new WebSocket` call and the `onopen` event?

* When it disconnects, how long after the `onopen` event does `onclose` fire? Is this constant?

* Does the socket trigger the `onerror` event? What error code does it yield? (The argument to onerror is an error object with a `code` property in recent browsers)

One more thing: can you find out what the delay is between sending a message and getting a response for it is? e.g. between publishing a message and getting one back with the same `id` and the `successful` field set to `true`? 

[Ramon Poca]

Beware, too, of antiviruses+firewall. That was what one of our antiviruses (Kaspersky) broke with its "HTTP buffering".

It made Faye think the websocket connection was established, but then didn't flush its buffer as frequently as needed for the websocket to be operative. Any "too smart"  proxy not understanding WebSockets could break connections the same way. 

We've had to disable websockets too for the "general public".

It's a pity, but if we want to use websockets at this still early stage of general deployment, we'll have to do too many checks and fallbacks. Cases like the antivirus one could be really hard to detect (it broke randomly, depending on the buffer state or something...). I don't know if a separate check could be designed, maybe using the ping mechanism in websockets. Then you could set a cookie or something to mark the transport as unreliable for that box. 

On Thursday, March 1, 2012 11:43:30 PM UTC+1, James Coglan wrote: