AsyncRedisManager.get_participants() only returns participants from the local instance

[Trinkes]

Hi, first of all, thanks for the amazing library!

I’m using socketio.AsyncServer with socketio.AsyncRedisManager in a distributed FastAPI application.

In one particular use case, I need to emit an event to all clients in a room and wait for an ack from each client. Because of the requirement for acknowledgments, I cannot use the standard emit(..., room=...) functionality, as that does not support per-client ack callbacks.

To work around this, I tried retrieving the SIDs of all clients in the room using RedisManager.get_participants(), and then emitting the event to each SID individually. This lets me await the ack from each client and retry sending the event if the client doesn’t acknowledge it.

However, I noticed that get_participants() only returns the participants connected to the current server instance, not the full list of participants in the room across all instances.

Is there a recommended way to emit events to all clients in a room across the cluster, while still being able to handle per-client acks (and potentially retry sending events that are not acknowledged)?

Thanks in advance for any insights!

[miguelgrinberg]

This made me realize that I need to update the documentation of get_participants() to make it clear that it does not have a way to know the participants in other nodes in the system.

One option that you have that I often suggest is for the application to keep track of which people are in each room in your database, because computing a complete list of participants is really difficult and inefficient in a distributed environment, this isn't a distributed operation.

You may also consider adapting your solution to match your distributed application better, so that instead of one node emitting to all the users, you can have each node talking to the users it knows about, which is actually how broadcasts are implemented in this package.

[Trinkes]

Hey @miguelgrinberg, thank you for the quick reply!

This made me realize that I need to update the documentation of get_participants() to make it clear that it does not have a way to know the participants in other nodes in the system.

That would be great! Maybe you can also suggest the alternative you've shared.

One option that you have that I often suggest is for the application to keep track of which people are in each room in your database, because computing a complete list of participants is really difficult and inefficient in a distributed environment, this isn't a distributed operation.

I understand, this was more a mismatch of expectation on my side than anything else.
I ended up implementing the rooms feature on my side with redis and keep tracking of the session myself.

You may also consider adapting your solution to match your distributed application better, so that instead of one node emitting to all the users, you can have each node talking to the users it knows about, which is actually how broadcasts are implemented in this package.

This was the implementation I had before I integrate with socket.io. The thing is that you still need to communicate between servers and I'm not sure about the advantages of doing that myself or relying on what socket.io already have.