CODEWITHSUNDEEP
javascriptnode.jswebsocketsocket.io
IlIIlllIIIlIIlllIlIllIIIlIlI
IlIIlllIIIlIIlllIlIllIIIlIlI

Reputation: 777

Do emitted events create significant load even when they are not watched?

I spent a couple hours looking into this, and I could not find a definitive answer so I'm creating a question. I'm quite new to websockets, so apologies in advanced if the answer is easily available somewhere.

I currently have a node.js server emitting several different websocket events through socket.io. Throughout different parts of the server code, I therefore have lines that look like:

io.sockets.emit('eventOne', data);

Let's say that other parts of the code also include lines such as:

io.sockets.emit('eventTwo', data);

I have two different types of clients that connect to the server. One type of clients only listen to the first event, thus having lines such as:

socket.on('eventOne', function(data) {//blah blah}):

The other class of clients listen to the other event, and thus have run lines such as:

socket.on('eventTwo', function(data) {//blah blah});

Both clients are connected on root level without rooms. If we look at the first group of clients, for example, it's only watching for the 'eventOne' events, so it makes me wonder if this group of clients receive all the data for 'eventTwo' events, or if they do not because they do not listen for them.

Here's my ultimate question: Do the clients experience A: the full network load for all events, or B: only for events that they are watching for? (or C: full load for events that they are watching for and only partial load for events they do not watch for)

My guess is that even though the client side code are not watching for all events, all the emitted events from the server will be emitted through the websocket, and both types of clients will each be under network load for both types of events. However, a part of me thinks that socket.io code might reduce the network load for clients by refusing to receive the entire payload for events that they are not watching after it determines what the event is.

Yes, in this example, the two types of clients should be joining different rooms, but I just wanted to better understand how watching for events affects the network load

Thanks in advance for the insights!

Upvotes: 3

Views: 58

Answers (1)

jfriend00
jfriend00

Reputation: 707876

Do the clients experience A: the full network load for all events, or B: only for events that they are watching for?

A server has no idea whether a client is listening for a specific event. So, if the server code says to send the event to all clients, it sends the event to all clients whether the client is listening for that event or not. So, the answer to the above question is A - the full network load for all events sent to it.

However, a part of me thinks that socket.io code might reduce the network load for clients by refusing to receive the entire payload for events that they are not watching after it determines what the event is.

No, TCP and socket.io just don't work that way. A whole message is sent as a unit. There's no ability to cancel part of a message. The payload would have to be broken into multiple messages with some ability for the client to send back and tell the server it does or doesn't want more pieces. That could be designed, but is not that way by default.

If you have two classes of clients, each that are interested in different classes of messages, then you should probably put a given client in a specific "room" that matches what it wants to receive. If the server knows which client is which, then it can just put the client in the right room as soon as it knows. If only the client knows, then the client can send a message to the server to request placement in a specific "room". You make up the "room" names you want to use on the server - they are merely collections of clients, the actual name does not matter.

Then, the server can broadcast messages to the appropriate room and only the clients that have asked to be in that room will get those messages. This way you won't be sending messages to clients that aren't interested in them.

It's logically like a chat room. Each client gets put into the chat rooms that contain the types of notifications/messages it wants. It can be put into more than one room if desired. This is a very useful capability built right into socket.io. It was likely first written for chat purposes, but it works just fine for classes of notifications too.

Upvotes: 3

Related Questions