Nowadays I am looking into mediasoup internals to figure out how to run mediasoup at best, for scalability deploy for cloud.
I know that mediasoup is nodejs module and c++ workers. And they use interprocess communication. My problem starts here. nodejs server also handles signalling from participants and managing workers also (create router, create producer, audiolevel observing etc…)
So, after a number of participants, nodejs server’s clients’ side signalling gets heavy ( A case users starts to chat heavily over signalling channel over nodejs server).
I am looking for a way to handle this. One radical option is, writing a c++ rest server in front of worker and consuming events from nodejs server over tcp/ip socket. Actually this will be replacement of channel comm within mediasoup nodejs side and worker side . As you see, this changes the core mechanism which is interprocess communication. With this, I am planning to scale only rest servers which are working workingon the same process.
Beside this, moving the rest server in front of the nodejs module is another option. With this, signalling and chat messages will be in another process and scalability will mean scaling nodejs+workers .
I would like to ask you that did you think such kind of architecture like the first option before planning mediasoup architecture? What are drawbacks beside implemention time and test of course.
I would be glad to discuss this with you…
If someting needs to be clarified more, please ask.
Mediasoup doesn’t handle signaling, just provides API for you to implement the signaling you need.
The easiest way would be to have multiple copies of your service and load balancer in front of it, but strategy depends on whether you need a lot of viewers or a lot of publishers or what do you mean exactly by scalability.
Also I don’t think signaling would be a problem in most cases, worker instances and CPU on the server will more likely be a bottleneck first unless you have 64-core system or something along those lines. Again, without knowing what you are looking for it is hard to know.
Thanks for the quick answer. I would like to visualize my thoughts as below:
Below one is current architecture. Worker is in the same host with nodejs server and I guess it must be like that. Because workers are managed and configured over interprocess communication.
My aim is like below. Communication over TCP/IP may bring independency to workers to run anywhere.
Also when there is heavy messaging between nodejs mediasoup and workers (like audiolevel observer, stats etc.) , some messaging mechanism may be used like rabbitmq.
Do you think this is feasible and brings advantages?
You cannot split the Node component and C++ components of mediasoup. You can achieve what you want (running N Node components) by using Node Workers (threads):
But this also requires caution with your WebSocket server (or whatever you use to connect clients to the server).
This way you could use all the cores of your CPU not just for media (C++) but also for signaling (Node).
