[KaiserPro]

Sorry, but no.

For a p2p system to work you need to have a nearest neighbour finder(please wait 5 minutes whilst we probe your network) you then need to have a realtime "rationilser" that will go through and re-route the live stream according to how many peers in one segment are connected to another. Then, you need a number of backup peers for when your current master peer disappears.

Then you have to deal with partition, and also make sure that NAT doesn't get in the way. Also you'll need to block mobile phones as well.

the best part is, you'll be forced to use HVEC as the usable upload is around 2 megabits. That means a stream encoded at 750k (to allow uploading to two other users) or half that if you want 4 other peers.

So no, P2P is not the answer. Iterate again.

[Rodi]

Hey, what you describe what clearly the case with old peer-to-peer systems, but things changed a lot. With webRTC and ICE/STUN, the p2p connection takes less than 5s on average and goes through NATs in 95% of the cases. As for the bandwidht issues, it is not a problem as the solution is hybrid and doen't need every peer to be a full seeder.

If you don't beleive me you can always try by yourself, with a Chrome/Firefox/Opera browser : http://demo.streamroot.io

[KaiserPro]

one connection takes 5s, but using a stun server means you don't understand peer locality. This means you as the service owner has to map the network to find correct peer placement.

How do you asses the bandwidth available now, and in the future? is the bandwidth between two peers inside and ISP greater than two peers from different ISPs. How do you manage peer re-routing when one disappears. What happens if more than one peer disappears?

webrtc is designed for 1 to 1 mapping, and not 1 to many paid for content delivery. Sure you can do it, but your users arn't going to be happy you chose to engineer your way out of a bad idea. (You don't want buffering during an expensive movie/tv/sports game)

[alecco]

That can be cached if there's only one system. And BitTorrent DHT takes about 30s to start finding peers. That's a very old type of DHT, a new protocol could prioritize finding closer neighbors.

[KaiserPro]

but that takes time, which means depleting cache. As most domestic connections are limited by upload, its not like you can get that cache back.

Especially if you are at the edge of the the p2p chain. Your cache might be dependent on three other people refreshing their cache first.

[sylvinus]

Did you read the article? Your points are irrelevant because it's not 100% P2P, they say they reach ~58% of P2P use, while the rest comes from regular CDNs.

[KaiserPro]

yes, I read the article, I also note that they were using a 1 meg stream.

They didn't describe the jitter, dropout rate, cache misses and eventual fall back. For example was that 58% peak? was that 58% attempted p2p use? what was the threshold? did the users notice?

what happens when peers go away? does that mean that create burst loads on the cache master?

What is the success rate when they stream 4meg, 8meg? or a bitrate that changes significantly? for example going from a semi static image to fast moving sports (think transition from commentator studio to live action) Having dealt with these types of systems in the bad old days (think 2007-9) I can tell you that they suck hard.

All that engineering work required to patch over a under resourced and terribly unreliable transport, when many a pre-built system with SLAs already exists