pingInterval should just force close the connection if the server doesn't pong

[lmcd]

pingAndScheduleNextTimeoutTask in WebSocket should not call close (as this assumes the connection is still open), and should rather just immediately close the channel.

[0xTim]

What's the downside of sending a close to the client before shutting the connection down? If there's a network delay or the server is still processing some data it will at least get a close with the right error code it can then handle rather than an instant kill

[lmcd]

I think I've misread the code here, as the close promise seems to succeed after the close signal is dispatched, rather than waiting for the full roundtrip.

I was running into long delays/timeouts, but I think the source of the issue is in fact this: #90 (comment)

IMO, if the pingInterval is set to 2 seconds, I should have a way of immediately knowing when this 2 second timeout has elapsed, rather than instead waiting 7 seconds for onClose to actually fire.

[0xTim]

Ok I'll close this in favour of #90 then