I discovered that each Worker in mediasoup has a reference to its routers as _routers but does not propose it as a public property. The same is for Router._transports, Transport._producers and Transport._consumers. Does it mean I need to re-implement the whole infrastructure to keep track of workers, routers, transports and etc in the app?
ITOH it seams there is no reference for router to it’s worker. The same is for transport.router, producer.transport and consumer.transport which could be useful.
As a general rule, if the app can do it mediasoup won’t do it.
Yes the app can do it but the point is that mediasoup has already done it, probably in a more efficient way. I don’t understand why do I need to create exactly the same references that mediasoup has, which adds the app complexity and raises the chance of garbage collection issues.
mediasoup is not a server but a library. It provides you with an API to create objects and use them. You (the app) create those objects and you manage them. Why is this so hard and why do you expect a getXxxxxxxxxxById() API? All those API usages I’ve seen (in v2) are due to a wrong server app design.
And which “garbage collection” issues do you mean?
Okay so you advice not to use the internal mediasoup objects like _routers, _transports, etc.
And which “garbage collection” issues do you mean?
If the app does not release references to a closed/destroyed object then that object never could be removed by the garbage collection and I’m actually a little worried about not properly handling all the closed/died events for managing those objects while mediasoup is doing that in the right way.
Definitely you MUST NOT use the internal objects like _routers, _transports, etc. Those are private members.
A worker is closed when:
worker.close() is called, or
worker.on("died") event is fired.
A router is closed when:
router.close() is called, or
router.on("workerclose") event is fired.
A transport is closed when:
transport.close() is called, or
transport.on("routerclose") event is fired.
A producer is closed when:
producer.close() is called, or
producer.on("transportclose") event is fired.
A consumer is closed when:
consumer.close() is called, or
consumer.on("transportclose") event is fired.
consumer.on("producerclose") event is fired.
When any of those cases happens, xxxxxx.closed returns true.
Also, each close() action in different objects triggers different events in sub-objects. For instance, calling transport.close() will trigger “transportclose” event in all producers and consumers in that transport and, hence, also “producerclose” in all consumers (in different transports) associated to those producers in the closed transport.
I really do not understand what you are trying to achieve but you do need to manage your own references to mediasoup objects anyway so you must listen to those events and act according by removing those references from your app memory when appropriate. May be you expect something like router.getTransports() and router.getTransportById(id) and transport.getProducers() and transport.getProducerById(id), etc. so when an API or WebSocket message is received in your Node app you look for the contained transportId and producerId properties, get the corresponding mediasoup object and act on them. I’ve seen that in the past, and people using that approach does zero validation of the message, so any user that knows the id of a transport or producer not belonging to him can close them or whatever. I strongly think the current API design forces the application to properly manage the mediasoup objects it creates, just that.
