Sign in to follow this  
thedupdup

My javascript websockets seem to be buffering incoming messages

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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? 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.