Reconnection support

[rauchg]

With

[ ] Exponential backoff
[ ] Customizable timers
[ ] Transport remembering even with `rememberTransport: false`

@3rd-Eden is working on this.

[danielbeardsley]

Great! I was just gonna do something similar... Love to see the results.
Also would love to see some events (or similar)
[ ] connecting
[ ] connecting_failed

And maybe some status variables so we can give some visual feedback
[ ] retryConnectionIn
[ ] state (conecting, waiting, ...)

Heh... while were at it... allow users to override the exponential backoff function with their own increasing algorithm.

[3rd-Eden]

I have almost completed the implementation, just some browser testing left to be done before I'm going to send a pull request for it.

You can specify a few new options:
- reconnect: true, if you want to enable automatic reconnection support
- reconnectionDelay: 500, the initial delay that is used for the exponential back off. So you should keep in mind that this will increase overtime.
- maxReconnectionAttempts: 10, how many reconnect attempts should we make using the current or last used transport.

The flow:

The client receives a disconnect event. We start our reconnect functionality and set the property reconnecting to true. Inside the reconnect we attach a event listener for the connect event and we set the tryTransportsOnConnectTimeout option to false. This will make sure we keep retrying using the same transport method as before.

After the first reconnectionDelay is passed we multiply the reconnectionDelay by 2 to create a exponential backoff and call the .connect method. We emit a reconnecting event with the newDelay and the reconnection attempts we have made so far.

If our state is set to connecting when the our new delay passes we are just going to wait until the connecting property is set to false. Once this is done, we repeat the whole process until we run out of reconnectionAttempts.

When we run out of reconnectionAttempts we try all enabled transports for the last time, because it could be that for some odd reason one transport is broken. If this all fails, we will emit a reconnect_failed event so the user can decide what to do.

If a reconnection was successful we emit a reconnect event with the transport type, and reconnectionAttempts.

The development branch can be found here: https://github.com/Hotelsnl/Socket.IO/tree/reconnect

Feedback is more than welcome :)

[danielbeardsley]

Wow.. That's perfect! I'll test it out later this week.

[danielbeardsley]

Shouldn't this be closed?

[rauchg]

Fixed