Request for repeated `heartbeat` option

Some hosts are closing web socket connections if there is no traffic over a certain period. For example, heroku.

It would help if there was an option to keep the connection alive. This fork|commit has implemented a ping/pong like service. But a heartbeat need not be bi-directional.

Here is a (not well tested) workaround:

// pass the peer instance, and it will start sending heartbeats
var heartbeater = makePeerHeartbeater( peer );

// stop them later
// heartbeater.stop();

function makePeerHeartbeater ( peer ) {
    var timeoutId = 0;
    function heartbeat () {
        timeoutId = setTimeout( heartbeat, 20000 );
        if ( peer.socket._wsOpen() ) {
            peer.socket.send( {type:'HEARTBEAT'} );
        }
    }
    // Start 
    heartbeat();
    // return
    return {
        start : function () {
            if ( timeoutId === 0 ) { heartbeat(); }
        },
        stop : function () {
            clearTimeout( timeoutId );
            timeoutId = 0;
        }
    };
}

[afrokick]

Done https://github.com/peers/peerjs/pull/502

[rc1]

It works – at least with Heroku. The server need not do anything. As it stands the server should be parsing the message and printing “Message unrecognised” . But this would be an easy fix if a feature like this were adopted.

I’m not sure that a ping with a pong at JS level would be required to keep a connection alive. Perhaps there is by-directional communication happen at a lower level anyway; just a guess. For the server detecting closed peers, I would have thought WS’s ‘close’ event would be fired and then the clean up happens? If not, perhaps the issue is with WS? Alternatively the server could periodically send a heartbeat back (not in sync with the other heartbeat) and catch the failed write callback.

You are right about the trickiness testing. I wish I had a better way than trail and error. In this case that’s what I’ve done. However here is Heroku’s docs on connection timeouts and this being an acceptable practise.