| 1 | # pusher-js reconnection logic
|
| 2 |
|
| 3 | Assuming that `useTLS` is *not* set.
|
| 4 |
|
| 5 | The basic connection strategy involves first attempting a connection to the `ws` (non-secure) websocket url immediately
|
| 6 |
|
| 7 | If no handshake is completed within 2s a connection a connection to the `wss` websocket url is attempted
|
| 8 |
|
| 9 | If no handshake is received within 5s (from the first connection) a connection to the http url using `xhr`\* streaming is attempted
|
| 10 |
|
| 11 | If no handshake is received within 4s (from the `xhr` streaming connection request) a connection to the http url using `xhr` polling is attempted.
|
| 12 |
|
| 13 | Each of these connections are attempted with timeouts in a loop, the initial timeout is 15s. The timeout doubles after each failed attempt up to a maximum of 60s.
|
| 14 |
|
| 15 | If we reach this point it's effectively a race - the first connection to complete a handshake successfully is used as the pusher connection.
|
| 16 |
|
| 17 | When a connection is successfully created, a description of the transport that succeeded is serialized and stored in localstorage. If a new connection process is started within 30 minutes, this transport will be attempted first, though with a short timeout (previous connection delay + 1s), *not* in a loop and with `failFast` configured (meaning we don't wait for the timeout if the connection fails). If this connection fails, the normal strategy outlined above will start.
|
| 18 |
|
| 19 | If `forceTLS` is set the process is the same, but instead of initially attempting a `ws` connection, a `wss` connection is attempted, and `xhr/xdr` streaming is attempted after 2 seconds.
|
| 20 |
|
| 21 | \* If `xhr` is not supported `xdr` is attempted, instead. If neither `xhr` or `xdr` are supported `sockjs` is used instead of `xhr`/`xdr` `streaming`/`polling`
|