Downside of using one transport for only one producer/consumer?

mediasoup libraries
1

Hi, I am using one transport for one producer/consumer for some of the scalability reasons on my server side and I want to stick to that.

It is mentioned in some topics that it is better to have all producers on single transport because bandwidth estimation is better in that case and I think same goes for consumers as well.

I want to ask if there is any downsides to using one transport for one producer/consumer? If yes then how much difference in bandwidth estimation, performance in percentage it will have with the other approach (one transport for multiple producers/consumers) like 5-10%?

2

Can someone please share his thoughts on this topic?

3

Ask yourself: do you want to establish a ICE + DTLS setup for every new Producer or Consumer?

4

I think no, no need of having separate ice setup for every producer/consumer and I think doing this will further speedup the producer, consumer creation process.

But if we have separate transport for every producer/consumer then what can be the issues with this approach?

5

More traffic because you’ll have transport-cc feedbacks (BWE stuff) for each transport. More CPU usage in mediasoup since each transport requires its own BWE logic, etc.

I cannot help much more because, for sure, I’ve never used a transport per producer/consumer.

1 Like
6

Thanks, 2 last things I want to confirm with you regarding this:

1- Does this “One transport per producer/consumer” approach have any issues on client side? Can this approach cause more CPU usage on client side as well? If yes how much approx?

2- You said that this approach will cause more CPU usage on server side, can this cause lags in video as well?

7
  1. No
  2. No
8

Thanks nice to know that.

What do you think about CPU usage being increased by “one transport per producer/consumer” approach.

9

Also, what do you think about possible downsides of using one transport per producer/consumer?

10

There’s no down-side it’s just further optimizing. I do prefer transport per user to better understand statistics and potential issues.

I would intend on the goal of having a transport per server IP (or worker). Allows you that scalability if one server isn’t enough.

I do wonder sometimes if a transport contains many many streams if it still uses multiple threads… unsure how all browsers/etc handle it.

1 Like
11

Also think of it this way, the user only establishes a single connection to the server, though a server could handle a LOT of connections it does simplify end-points to send packets.

Transport per user would simply amplify the operations needed. Loops are fast so this is pinching for pennies but everything counts right!?

12

Thanks for the information. :+1:

13

@BronzedBroth as ibc mentioned that using single transport for single producer/consumer will cause increase in CPU usage on server side. Why this will not cause an increase in CPU on client side?

14

Same would apply for client-side, but these gains are not substantial enough… Either end.

15

I see, so this increase in CPU is so small that it can be safely ignored?

16

Yup. Due to the capabilities of core usage and ipc overall, so code as efficient as you can and forget that aspect. I worry most these days about trace routes between piped server routes and global delivery.

17

Thanks for the information :+1: