This SocketIO method emits a message to all users who have joined the same room (conversation ID).

This works if it's a 1-to-1 chat or a group chat with infinite users in the group.

The thing that bothers me is this enhanced for loop. It loops through ALL currently connected users.

- If theres 10 users, sure no big deal

- if theres 1000 users, it has to loop 1000 times

- for N users it loops N times

What if N = 10000? God what if it's 100,000 or 1,000,000.

Imagine having to loop that many times every time you want to send just 1 message.

OR wait i just realized. This shit grabs ALL users -- but within the room ID. Right? Am i trippin balls here

Im now confused (excuse my confusion i coded till 3am last night and im still fried). Is my logic flawed? Have i written this piece of code with good performance or not?

from what I understand you want to send read acknowledgements to all other clients?

Either way, if you wanna send something to every client, you're gonna have to loop over all of them in some way or another.

What I think could improve this performance wise is making this async. I suspect all of this is network based so most of the runtime of sendEvent will be spent waiting on IO.

I guess you could also process let's say 8 or so of these async operations at the same time.

But I don't know if that would make any better, I would suggest to do some measurements.

@LotsOfCaffeine what exactly should be async in this method?

Didn't socketio support channels?

@b2plane rooms. https://socket.io/docs/v3/rooms/

@retoor maybe in v4 but I'm using v2

@b2plane step up dem game. Btw, create an avatar!

@b2plane I would expect to have an async version of that send function, so you could make your sendSocketIOMessage async as well.

But I don't know that library, I just expect IO to be asynchronous in general.

Sending a message is kinda adding a record do a table. It's fast as a pony on meth. F dem async

@retoor do you mean that specifically for that library?

A pubsub system would be useful here for the numbers your talking about.

If this is theoretical, just loop until it actually becomes a problem.

@LotsOfCaffeine sockets in dem general. How it under dem water works

@LotsOfCaffeine have read this. Still happy about life

@lungdart

Pubsub also has to loop over all subscribers anyway. You have to do an operation for every element of a set. A loop is inevitable here.

Yeah but you can scale your pubsub horizontally while leaving the app alone.

Client code can sub to the correct queues, and you can push to it Willy nilly. If you have it set up correctly it will auto scale up and down as required without needing to think about it in the stack.

Yeah I agree with @lungdart here, an event-based system is at least more elegant for a group chat like system and allows for easy asynchronous execution.

@retoor idk why everyone forces using socketio v2. There are almost 0 tutorials or blogs or libraries supporting v3 not to mention v4

@b2plane I saw the docs were quite nice but I think it was TS

@LotsOfCaffeine i think the built in library's sendEvent() method is async in the background. I dont have to do anything on top of it. All emits literally arrive in the exact millisecond on all clients who joined the room. However that is done, seems to work efficiently

@lungdart socketIO already works as a pub/sub mechanism out of the box

@b2plane yes but you'll need a distributed message queue to facilitate it outside your app.

I prefer using cloud offerings because they're dead easy to set up this way. But if money is a concern you can whip up a Kaka/redis/rabbitMQ cluster and host it yourself to save a few bucks in exchange for effort.

Plain and simple, if you need to send a message to 1,000 people, you need to send 1,000 messages. There's no way to "broadcast" in one operation.

@lungdart

1) why would i need a distributed message queue?

2) whats wrong with just using socketio?

@AlgoRythm maybe in just overengineering shit

@b2plane you talked about effigies at 100k users. You'd want a reliable message broker that's decoupled from your server and client side code at that scale.

If you're not at that scale, don't worry about it. But if you're not at that scale I wouldn't worry about the looping either

@lungdart you're right. And i think i was wrong, i understood as if the looping goes through ALL online clients (100k users online = 100k loops) and that is false. It will loop through online users ONLY within the room ID. So this could be viewed as a partition loop

If it's a 1-on-1 chat (N=1, where N is number of participants) it will loop N+1 times (the +1 is me, the sender, which always gets skipped because no need to send the message that I am sending, back to myself)

If its a group chat with N=4 people it will loop only N+1=5 times, again skipping me

Seems efficient enough. Tell me why this mechanism wouldnt work with 100k users?

Lets assume 100k users are online (which means the platform has more than 100k users but others are offline). The socketio loop will run through the online clients only.

Scenario A: lets assume the platform allows only 1-to-1 chatting, meaning you cannot create group chats. Every message emit between 2 users would always loop 2 times among 100k users

@lungdart

Scenario B: many-to-many chats, meaning users are able to create group chats now. But lets say theres a restriction of maximum 10 people per group chat

Why wouldnt socketio be able to handle this, how would a distributed message queue broker fix this?

Assume you have an average of 3 people per chat (most 1 on 1). Assume each user has 10 chats on average they're in. Assume each chat sends 1 message per minute.

You'll have somewhere between 100,000 and 1,000,000 messages per minute being sent out to 2 people.

If each one of these have to go through a single server, 2,000,000 requests a minute could tax it, especially if it's performing all the other server end tasks.

A distributed queue would remove these requests from your server, letting it perform the other tasks without interruption. You could scale the server itself but that might be wasteful to scale all functionality when only one feature is taxing it.

For multi user messages, there's no difference, a message to a chat is a message to a chat. Each chat can have a unique queue, and each member of the chat will subscribe to it.

@lungdart ok that makes sense. Since the backend im building is just a monolith right now since its a mvp product how do i create a separate message broker here? A new repo, new project, or put everything in the same monolith backend?

@b2plane I would build in monolith so it can share config files and models. Would make service runnable using some command line argument

@b2plane don't worry about it. A simple monolith with lots of inefficient loops is perfect for an MVP. I wouldn't worry about scale until shit starts to break.

Those are what I call good problems!

@b2plane

Bear in mind hardware has its limitations too.

Each client is a socket, and sockets are not free. 100k sockets open at once (particularly if you blindly broadcast to them without delays or jitter will likely toast your OS if you aren't running on powerful hardware.

@lungdart tell me why shouldnt i use socketio even as a distributed message queue? Its a pub sub mechanism and works efficiently. Easy to setup and scale. Why should i use kafka/rabbitmq/redis pub sub instead of socketio?

@CoreFusionX isnt that how its supposed to work? How are kafka/rabbitmq/redis pub sub mechanisms handling that any differently than socketio?

@b2plane you probably shouldn't. Use socket io. And if you ever get to the point you need distributed message queues, you have good problems!

@lungdart if you don't use socketio you'll find yourself making one probably. What's socketio doing wrong? What's alternative?

@retoor socket IO isn't doing anything wrong. Event driven systems are just now scalable, and we were originally talking about 100,000 users chatting.

@b2plane

You shouldn't use socket io because to begin with, socket io, as I already told you earlier, is just bullshit functional sugar over regular sockets.

Socket io does not handle dead lettering, socket io does not handle routing, socket io does not handle acknowledgement/rejection/preflight... Need I go on?

Those are all functionalities a true message broker must offer.

Redis is not a full pubsub either, but already offers some advantages, such as ACLs, or pattern subscription/publishing.

@CoreFusionX what distributed message broker do you recommend then