This is a curious question. While webrtc RTPTranceiver supports the sendrecv why Mediasoup creates 2 separately as sendonly and receiveonly? Won’t it be good if we have a single connection to server and that ports are free and possibly the CPU and memory is optimized on server?
Any reason to have this design?
Can we create single webrtctransport and attach produce and consume to it? Any issues in that usage? Does it cause any issues in the SFU design / architecture? Is it more like a good practice ? Does it harm user experience?
For a fully scaled solution that would not work at all and in fact set you back in development if you coded that way.
How could you ever scale the application if you assume all transports will connect to the same server?
What happens if someone DDOS attacks your single server configuration for these transports?
This implementation would harm the user experience greatly and would prevent you from working outside a single server per room. You’re more likely to run into scenarios where as room complexity grows with users you may want to trade that off with another server.
any questions do ask.
Thanks a lot for your response and views.
I did not understand fully, these points.
I got this point to limited extent. For e.g. Why would, the number of webrtc tranceivers have nothing to do with the server setup. If at all, we would need to pipe to other servers (and the pipetorouters internally). Isn’t it? So having two transports vs single transport, how does that cause issue? For e.g., wherever the a single router is created, will get the piped to all servers and would pass the transports, which might need a bit of more coding to identify whether producer or consumer and process accordingly. In fact the load on server will reduce with the single transport and only bandwidth consumption would increase. Right?
In fact even in current scenario, if we are transmitting screen sharing, we just create producer to the producer transport and don’t create another one for screen sharing. With that logic, we should have created another transport for screen sharing. We don’t create multiple transports for each track (traansceiver) and thats just collected through a single webrtc connection transport as consumer. I think normally in pure webRTC even in peer-peer uses the single connection.
How does having two transports prevent the DDOS attack and protect the application? I am not able to understand this point.
What way the user experience get harmed? Is it that on a single port, the incoming or outgoing videos will have bad experience vs having multiple ports?
thanks again for your views, but please let me know some more details, around your view.
Sorry about that, it was a bit confusing the question and my answer as well.
You’d be fine running single transports for piping remotely/locally, the transport can consume/produce as many streams as you’d like, you just would differentiate them by consumer/producer ID. The CPU/Bandwidth will forever rise for each consume/produce you require. Each connection you’d like to make however is a new transport so you may have server A connect to B,C,D and that means A has 3 transports whereas B,C,D has one for the pipetransport.
In some scenarios yes a single Transport with multiple producers/consumers is just fine as mentioned above but this shouldn’t be applied for the client-level of things. A broadcaster should have its own transport to produce to the server and each viewer has a transport of each broadcaster.
So screen sharing and regular broadcasting you’d produce video and/or audio to the single Transport.
(If sending both screenshare and broadcast, you should maybe open two transports in case the server already produced to is full). In some cases you may open two transports for audio and video but this would be for further scaling if necessary.
The DDOS preventative comes into play when you use many transports for the clients. So if broadcasting and screensharing, two transports would be ideal for both sets of audio/video. When viewing a broadcast that would count as a single transport but the catch here is each transport may have a different IP so if there was in fact an attack you only lose few users at most.
User experience gets harmed if it’s easy for attackers to demolish your system and take big chunks out of it. If I was hosting a room of 24 broadcasts by 48 viewers and all 24 broadcasts suddenly dropped people would make quick judgement of the service but if 1 or 2 dropped, that’d be easy to dismiss as a disconnect.
You seem to have the right logic just some opinion for the pot.
This is good explanation. Although, the approaches may differ for the choice of architecture, this explanation is a very good base for taking decision.
Although this discussion referred to generic points, my question is answered by Cosmosis. The discussion you referred also helps for clarifications partially. Thanks for your response!