Make time duration since last server data available

[ngbrown]

With my WebSocket connection, I needed the client to re-connect when the connection wasn't active anymore. Setting the heartbeat would ensure the server sent something at a regular interval, but the application had no way to know when the heartbeats were.

This was the solution I came up with, on every received message, store the current performance.now() value, a monotonic millisecond timer. It had to be within this library, because the only message during the time period might be the heartbeat message. Then the application can check if it has been significantly greater than the heartbeat time since the last received message, and attempt to re-connect.

[dentarg]

Sounds like this makes sense, is it possible to cover it with some test?

[dentarg]

Suggested change

	* Get the time since since connection or last data received
	* Get the time since connection or last data received

[carlhoerberg]

Shouldn't the heartbeat functionality be built out instead and automatically disconnect if no heartbeat frame is received within the acceptable time frame?

[ngbrown]

... is it possible to cover it with some test?

Good point, I'll work on a viable test.

Shouldn't the heartbeat functionality be built out instead and automatically disconnect if no heartbeat frame is received within the acceptable time frame?

At the time this was the simplest diff I could patch-in to do what I needed, while detecting disconnects and re-connecting continued to be handled within the app. My application code (in the browser) manages creating and disposing a timer that checks both for closed connections and missed heartbeats. If this timer was moved into the library, a more involved event model between the library and the application would need to be built out.

The .NET client, for example, has an even more involved model of also reconnecting when disconnected, I don't think reconnecting within this library would work easily in my application's case. The application is connecting to RabbitMQ streams, so needs to update x-stream-offset argument to the last value it saw to effectively resume from where it left off. If reconnecting was going to be internalized into the library, then directly supporting streams parameters would be needed.

[carlhoerberg]

Did you perform any benchmarks with this? How expensive is performance.now()?

The client might not need to reconnect automatically, but socket could be closed and onerror could be called if a missed heartbeat is detected. Then there should be no need to expose this, right?

[dentarg]

The client might not need to reconnect automatically, but socket could be closed and onerror could be called if a missed heartbeat is detected. Then there should be no need to expose this, right?

Sounds like that would address #95?