Is SUBSCRIPTION_KEEPALIVE needed?

[NeoPhi]

The WebSocketServer implementation being used already has keep alive support build in and it is turned on by default. This is configured via the options passed into the created server:
https://github.com/theturtle32/WebSocket-Node/blob/master/docs/WebSocketServer.md#server-config-options

[helfer]

@rricard could you give that a try and find out if we could drop the keepalive?

[rricard]

@NeoPhi @helfer I initially implemented it because nothing was sent and heroku was cutting me out. However I didn't look for the option in WebSocketServer and that's my mistake...

So the defaults of WebSocketServer right now are not enough for heroku it seems but I agree that correctly exposing the WebSocketServer's keepaliveInterval option would be better than doing our own stuff.

[rricard]

However I would argue for keeping a timeout system on subs transport ws just in order to track connection closing (the socket does not fire correctly if the client abruptly disconnects, it will close correctly the next time the client comes back on the webpage managing this socket ...), the timeout could do regularly a health check on the connection just to see if everything is still ok and if the connection cut us out, do the corresponding cleanups

[Urigo]

Hi @NeoPhi , in this PR: #53, we replace WebSocket-Node with a smaller package called ws, and it does not have a built-in implementation for keep-alive messages yet, so we still need our implementation in this package.
We can revisit this once ws will support that

[tailhook]

Hi,

After reading this issue I'm still not sure whether I need keep-alive. My guess is that it is only useful when websocket server implementation doesn't support builtin websocket's ping/pong messages. Am I right?