Jump to content

My javascript websockets seem to be buffering incoming messages


thedupdup
 Share

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?

Link to comment
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?

Link to comment
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.

Link to comment
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? 

Link to comment
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.

Link to comment
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. 

Link to comment
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.

Link to comment
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.

Link to comment
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. 

Link to comment
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).

Link to comment
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. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...