My javascript websockets seem to be buffering incoming messages

[thedupdup]

Im receiving websocket messages on my webpage, and i'm trying to calculate the frequency at which they are received. I do this like so:

let startTime = new Date();
ws.onmessage = function (evt)
{

prevData = recivedData;
var receivedMsg = evt.data;

recivedData = JSON.parse(receivedMsg);

const endTime = new Date();
const timeDif = endTime - startTime;
startTime = endTime;
console.log(timeDif)
}

But it seems timeDif sometimes is 0, and I find this unlikely. People in other questions of mine have sad that its due to the websocket buffering incoming messages. How do I prevent this?

[mattstyles]

Definitely sure you're not executing the `startTime = new Date()` line more times than you think?

i.e. if you're trying to record the frequency of multiple messages maybe this snippet is all in a function that is being called somewhere and inadvertently mutating the startTime you're expecting to be a constant?

[Antriel]

Websockets use TCP under the hood. If a packet drops along the way, TCP will buffer any additional packets until it also receives the one it lost. After it does, it will supply everything it has, which can cause what you see. There is nothing you can do to prevent that apart from using multiple websocket connections and implementing something like udp over tcp.

[thedupdup]

6 minutes ago, Antriel said:

Websockets use TCP under the hood. If a packet drops along the way, TCP will buffer any additional packets until it also receives the one it lost. After it does, it will supply everything it has, which can cause what you see. There is nothing you can do to prevent that apart from using multiple websocket connections and implementing something like udp over tcp.

So its caused by packet loss? Basically all I need to to do is process the messages as soon as they are received, is this possible? 

[Antriel]

8 minutes ago, thedupdup said:

Basically all I need to to do is process the messages as soon as they are received, is this possible? 

Unfortunately, not with TCP. And the only way to do UDP on the web is via WebRTC, which is aimed at media and p2p networking, so achieving client-server architecture there is difficult.

[thedupdup]

39 minutes ago, Antriel said:

Websockets use TCP under the hood. If a packet drops along the way, TCP will buffer any additional packets until it also receives the one it lost. After it does, it will supply everything it has, which can cause what you see. There is nothing you can do to prevent that apart from using multiple websocket connections and implementing something like udp over tcp.

Okay, I have ruled this out by attaching timestamps from the server to the packets, the timestamp difference is very consistent. This would not be so if there was a missing packet. 

[Antriel]

The packet drops along the way, you can't test for that like that.

You could try doing it on a good LAN connection (that you tested) or a localhost loopback, which shouldn't drop packets at all.

[thedupdup]

3 minutes ago, Antriel said:

The packet drops along the way, you can't test for that like that.

You could try doing it on a good LAN connection (that you tested) or a localhost loopback, which shouldn't drop packets at all.

I still get 0 when I use a server running on localhost, I don't think its packet loss.

[Antriel]

Then it's either what @mattstyles said, or your event loop is too busy and can't process the message fast enough – that might show in profiling. I would try to simply log `Date.now()` on arrival of messages and maybe also run another timeout with much smaller timestep than what server sends, logging the time too, to visualize whether event loop is free or not.

[thedupdup]

3 minutes ago, Antriel said:

Then it's either what @mattstyles said, or your event loop is too busy and can't process the message fast enough – that might show in profiling. I would try to simply log `Date.now()` on arrival of messages and maybe also run another timeout with much smaller timestep than what server sends, logging the time too, to visualize whether event loop is free or not.

The server sends updates around 20 times per second, is this too much? I also tried just printing Date.now(), some times two of the printed dates were the same. 

[Antriel]

50 Hz is normal. Try doing the setInterval that just logs the time too, with something like 10 ms interval. If that fires around the problematic message, with +-10ms interval, then event loop isn't too busy.

Also, is there a visible missing date? Like before there's delta of 0, is there delta of 100? If not then it really feels like the message callback is ran more than it should (which you can determine by the contents of the message).

[thedupdup]

17 minutes ago, Antriel said:

Also, is there a visible missing date? Like before there's delta of 0, is there delta of 100? If not then it really feels like the message callback is ran more than it should (which you can determine by the contents of the message).

Yes, it will go from a steady 60 to a 0 unpredictably. But the problem is all the time stamps on the messages are normal.