Best approach to implement clusterable P2P signaling / messaging?

For my WebRTC based app, I need a signaling server to negotiate the connection descriptions between the peers.

The WebRTC samples I found are using, but as far as I understand it, this approach wouldn’t work if I scale the app horizontally, as it relies on one server instance mediating between the clients. Though I haven’t set up a cluster yet, I want to make sure this will be possible in the future.

The simplest approach would be to use a regular collection to store events and subscribe to them, but this causes additional load on the database server. This is how Rocket Chat seems to do it, according to

I found some community packages for messaging like raix:eventddp and yuukan:streamy, but these don’t seem to support scaling either.

lepozepo:streams (based on meteorstreams) should, but the docs of meteor streams refer to the meteor cluster package which in turns says it is obsolete now due to Meteor’s collections. Which is a bit confusing since I always thought that meteor cluster would be the way to go for scaling.

I also read that people are using REDIS servers for messaging, but this would require me to set-up an additional server.

How are you guys doing this? Is there any other approach I am missing?

I’ve used MongoDB for an app (RTCMulticonnection), so I’ve sent all signaling messages over it using publications and subscriptions. It was not the best way, but I also didn’t want to use a second server only for the ICE handling.

As far as I know, supports a cluster with Redis ( I think if you want to go the clean way without “abusing” MongoDB for temporary, this will be the best way.

1 Like

Thanks for your reply. I guess I will use MeteorStreams now. Though it’s deprecated, it still seems to have a broad adoption and works just fine. I’ve looked deeper into Rocket.Chat and found out that it’s heavily relying on streams.