Websocket: are server data sent synchronously?
Asked Answered
F

2

9

I'm using nodejs + websocket module to establish a connection between the client and the server through a websocket. The server emits several times data to the client: I know it's a TCP connection, but let me delete every doubt about it. Are the "emits" sequential? If the first "emit" was done at time 1s and the second "emit" at time 2s, will the client receive for sure the first emit and then the second one? What happens if the first emit is not received yet and the second one is emitted? Are emits blocking calls?

Femininity answered 14/2, 2012 at 19:21 Comment(1)
E
23

WebSockets is built on TCP. TCP guarantees delivery and ordering of packets. In addition, unlike TCP, WebSockets is message based which means that WebSocket messages are received as an entire message (TCP is streaming and 'messages' may get fragmented from the listener's perspective)

In node.js, two emits that are called from the same context (the same function) one after the other will be delivered in that order. However, if your emits are in two different callbacks, you can't always guarantee when Node.js will schedule those callbacks and so the emits may get re-ordered because the scheduled callbacks got re-ordered.

Update:

Here is an example to expand on why the event driven nature of Node.js may result in surprising re-ordering of WebSocket emits/sends:

fs.readFile(file1,function(e,data) { ws.send(data); });
fs.readFile(file2,function(e,data) { ws.send(data); }); 

The order that file1 and file2 will be delivered to the browser is not predictable (even the file size is not a guarantee of when they will fire due to things like caching, file-system fragmentation, etc). Even if the readFile of file2 is called 1 second later using a setTimeout, the browser may still receive them out of order (e.g. if file1 is much larger and takes 3s to read in then the send of file1 will happen after the send for file2).

So yes, emits/sends will be received in the browser in the order they are called in Node.js, but due to the asynchronous event driven nature of Node.js the emits/sends may not happen in the order you expect.

The asynchronous event driven nature of Node.js is what gives Node.js excellent efficiency and performance, but if you aren't used to this type of callback based programming it can have some surprising results.

Exudate answered 14/2, 2012 at 19:46 Comment(7)
"However, if your emits are in two different callbacks, you can't always guarantee when Node.js will schedule those callbacks and so the emits may get re-ordered because the scheduled callbacks got re-ordered." - if callback 1 ran before callback 2, and they each emit, callback 1's emit will run before callback 2's emit.Bombardier
@einaros, that's true but my point is that callbacks are inherently asynchronous so you can't guarantee the order in which they will fire. Even if you register callback A 1 second before you register callback B, if the routine with callback A takes 3 seconds to complete and B only takes 1 second, then B will happen before A even though A was registered first. And any callbacks that are firing on I/O completion will often have unpredictable timing.Exudate
Given that callbacks registered in a specific order for a specific event will always execute in that order, I don't quite see how any of the rest relates to the OP's question. It's obvious that if the events that trigger the emits change order; the emits will also change order.Bombardier
My intent was to answer his question and the next one he (and others in the same situation) will likely encounter when dealing with event driven languages. I think an example might help: fs.readFile(file1,function(e,data) { ws.send(data);+); }); fs.readFile(file2,function(e,data) { ws.send(data); } . In this case, the order that file1 and file2 will be delivered to the browser is not predictable (even file size is not a guarantee of when they will fire). Even if the readFile of file2 is done 1 second later, the browser may still receive them out of order due to the async nature of readFile.Exudate
You should add that example to your answer, otherwise people may be left with the impression that node.js itself may reorder emits or callbacks (which it won't -- it's entirely up to whatever you're waiting for).Bombardier
I'm still a newbie with node and its event-driven nature. However: in my app I have an "onmessage" handler which 1)work on the message 2)update several keys in redis db 3)returns each websocket-listening client the result of the updated redis keys. This "onmessage" handler may be called even 2 or 3 times in a second. I guess I shouldnt worry about the sequence of the data.Femininity
uhm... I'm trying to understand deeply the node-websocket working flow. I think I'll open another question too. Thank you guys!Femininity
K
4

Messages come in at the client in the correct order.

Karlynkarma answered 14/2, 2012 at 19:29 Comment(2)
So what is the "correct order"? If two processes send simulatenously 1 nanosecond apart, does the server receive the calls in that order?Hotchpot
@Hotchpot Your question embodies a contradiction in terms.Expedition

© 2022 - 2024 — McMap. All rights reserved.