3 ms·

> WebRTC will work well in a fully P2P way. There's no need for a centralized server unless you have more than 10 users connected. I wish. With 10 users you ha

> WebRTC will work well in a fully P2P way. There's no need for a centralized server unless you have more than 10 users connected. I wish. With 10 users you have 102 - 10 = 90 different (unidirectional) data flows. Each of them can run into a different bottleneck where person X cannot hear Y and Y cannot hear W... And they cannot be monitored centrally (!). Compared to a centralized location where you would have 10 user-->server + 10 server-->user flows. On top of that, ISPs care about bandwidth between customers and large services e.g. AWS and don't care about ISP-to-ISP traffic.

littlestymaar 7y ago
> I wish. With 10 users you have 102 - 10 = 90 different (unidirectional) data flows. I don't understand your maths: in a p2p network with 10 clients, each clients ends up having 9(up) + 9(down) streams, with a centralized server, there is still 9 streams to download, but a single upload. Of course it requires 9 times less upload bandwith with a centralized server (or you get 9 times better quality for the same bandwidth), but as long as you don't have too much clients, p2p works fine. Keep in mind that for video chat, the biggest issue for QoS are latency and jitter. Using a centralized server won't help on those and if you have a good connection in terms of jitter and latency, you usually don't have throughput problems either. > And they cannot be monitored centrally (!). Why ? You definitely can push QoS metrics to a central serverif you want (but this server will have a much lower load to handle than if it had to centralize the video chat themselves) > On top of that, ISPs care about bandwidth between customers and large services e.g. AWS and don't care about ISP-to-ISP traffic. And AWS makes you pay a lot for every byte.