Heartbeat timeouts might not be properly working

[SEAPUNK]

  socketeer:SocketeerClient resetting heartbeat timeout: 11000 +0ms
  socketeer:SocketeerClient clearing existing heartbeat timer +0ms
  socketeer:SocketeerClient handling message +10s
  socketeer:SocketeerClient message is heartbeat +1ms
  socketeer:SocketeerClient handling heartbeat +0ms
  socketeer:SocketeerClient resetting heartbeat timeout: 11000 +0ms
  socketeer:SocketeerClient clearing existing heartbeat timer +0ms
  socketeer:SocketeerClient heartbeat timeout called +15s
  socketeer:SocketeerClient killing connection +5ms
  socketeer:SocketeerClient handling message +1ms
  socketeer:SocketeerClient message is heartbeat +0ms
  socketeer:SocketeerClient handling heartbeat +0ms
  socketeer:SocketeerClient resetting heartbeat timeout: 11000 +0ms
  socketeer:SocketeerClient clearing existing heartbeat timer +0ms

It killed the connection after timing out the heartbeat, but it still received a heartbeat somehow.

[SEAPUNK]

From ws/Websocket.js:

WebSocket.prototype.terminate = function terminate() {
// ...
    try { this._socket.end(); }

From the net.Socket.end() documentation: Half-closes the socket. i.e., it sends a FIN packet. It is possible the server will still send some data.

It's possible that the ws library is still receiving data even though the websocket should be technically closed.

[SEAPUNK]

It doesn't seem that the ws library ignores messages even if the socket is in the CLOSING/CLOSED state. I don't know if it's a bug (I'll report it, though), but I'll add another guard to Socketeer so it knows when to ignore messages.

[SEAPUNK]

I ran some tests, and it seems that it is not the case. I'll investigate deeper.

[SEAPUNK]

I'll do another test tonight, where I stress node's network capabilities.

[SEAPUNK]

Oh, this isn't an issue with the ws library; it just happens when the loop is all out of whack. I'll add the message read guards right now.