Rapid-fire sends regardless of interval.

[zimmed]

I used the socket.io example to implement timesync using basic websockets (not a fan of socket.io's overhead and lack of binary buffers). Here is the gist of the implementation:

Server

socket.on('timesync', data  => socket.send('timesync', {
    id: data && data.id || null,
    result: Date.now()
}));

Client

const ts = require('timesync').create({server: socket});
ts.send = (socket, data) => socket.send('timesync', data); // Sends {jsonrpc: "2.0", id: null, result: <timestamp>}
socket.on('timesync', data => ts.receive(null, data)); // Receives {id: null, result: <timestamp>}

The issue is that hundreds of timesync requests are being sent per second, even though each is receiving a correct response. I have tried create({server: socket, interval: 5000}) as in the socket.io example, but am getting the same result. I'm not sure if I'm missing something, or if there's a bug. Any help would be appreciated.

[josdejong]

I'm not sure what's going wrong in your case, but if the socket.io example works you should be able to figure out the differences between the working example and your code.

You're free to use another websocket solution instead of socket.io, timesync can work everywhere. The examples include the most commonly used solutions (http, express, socket.io), but you can use any web socket or http library.

[sean335]

I'm seeing the same thing on my web client. Seems like it gets stuck in an infinite call / response loop. It happens rarely and I'm not sure what scenarios lead to this issue. I believe the issue is around this line:

else if (data && data.id !== undefined) {

        // this is a request from an other peer
        // reply with our current time
        timesync.send(from, {
          jsonrpc: '2.0',
          id: data.id,
          result: timesync.now()
        })
      }

It happens when somehow I get an id = 0:

{
    "id": 0,
    "result": 1499041592374
}

This is my current client side code:

	var ts = timesync.create({
		server: '/timesync',
		interval: null,
		delay: 1000,
		repeat: 4,
	}); 
	ts.sync();

[josdejong]

Thanks for the extra info @sean335 .

Just a stupid question: are you using the latest version of timesync? In v0.3.1 an issue was fixed which could be related to this issue.

I can use some help figuring this out, will not have time for debugging this issue any time soon. Anyone interested in helping out just drop a message here.

I am also running into this issue whenever requests take longer than 10s. I think in my case it has to do with the implementation of timeouts. It seems that when the timeout is hit in the rpc function, the entry for id is deleted from _inProgress, and the promise is rejected with an error. But in the send function, the actual request ultimately returns successfully, so receive is being called, which falls into the else if block posted by @sean335 above. This results in a new request with the same id, and since the entry is still gone from _inProgress, it loops indefinitely.

If this is the case, maybe a way to fix it would be to have the XHR itself time out as well.

[josdejong]

Thanks @dfeblowitz, that sounds like you've probably tracked down the issue. Would it be possible for you to turn your findings into a PR with a fix?

[josdejong]

This issue should be closed now thanks to the fix of @dfeblowitz in #15.

Please let me know if this indeed resolves the reported issues.

Please reopen this. There was a subtlety that I missed in #15 that I didn't notice because of how I was testing, and I'm still seeing this issue when I include the new version in my application. It seems that the XHR timeout doesn't start counting until the request is sent, but timesync's internal timer starts counting before the XHR is created or opened. So if the XHR takes a long time in the "start" phase (which is happening for me), timesync may consider the request to have timed out, but the request still may complete successfully, triggering this behavior. (I'm looking at the Network > Details > Timings view in IE 11's devtools to figure this out, https://msdn.microsoft.com/en-us/library/dn255004(v=vs.85).aspx)

I didn't see this because I was testing by making the server take a long time to respond, which does make the XHR time out. I can work on addressing this.

[josdejong]

Thanks for reporting back, that's trickier than I had expected! Would be great if you could find a solution!

[DerekKeeler]

My team is seeing this issue in our codebase. @josdejong, hopefully #19 addresses the issue in an acceptable way.