←back to thread

492 points storf45 | 3 comments | | HN request time: 0.643s | source
Show context
shermantanktop ◴[] No.42160502[source]
Every time a big company screws up, there are two highly informed sets of people who are guaranteed to be lurking, but rarely post, in a thread like this:

1) those directly involved with the incident, or employees of the same company. They have too much to lose by circumventing the PR machine.

2) people at similar companies who operate similar systems with similar scale and risks. Those people know how hard this is and aren’t likely to publicly flog someone doing their same job based on uninformed speculation. They know their own systems are Byzantine and don’t look like what random onlookers think it would look like.

So that leaves the rest, who offer insights based on how stuff works at a small scale, or better yet, pronouncements rooted in “first principles.”

replies(15): >>42160568 #>>42160576 #>>42160579 #>>42160888 #>>42160913 #>>42161148 #>>42161164 #>>42161399 #>>42161529 #>>42161703 #>>42161724 #>>42161889 #>>42165352 #>>42166894 #>>42167814 #
survirtual ◴[] No.42160913[source]
For an event like this, there already exists an architecture that can handle boundless scale: torrents.

If you code it to utilize high-bandwidth users upload, the service becomes more available as more users are watching -- not less available.

It becomes less expensive with scale, more available, more stable.

The be more specific, if you encode the video in blocks with each new block hash being broadcast across the network, just managing the overhead of the block order, it should be pretty easy to stream video with boundless scale using a DHT.

Could even give high-bandwidth users a credit based upon how much bandwidth they share.

With a network like what Netflix already has, the seed-boxes would guarantee stability. There would be very little delay for realtime streams, I'd imagine 5 seconds top. This sort of architecture would handle planet-scale streams for breakfast on top of the already existing mechanism.

But then again, I don't get paid $500k+ at a large corp to serve planet scale content, so what do I know.

replies(5): >>42161009 #>>42161094 #>>42161365 #>>42161475 #>>42162174 #
nemothekid ◴[] No.42161009[source]
Torrents are awful for live events.

1. Everyone only cares about the most recent "block". By the time a "user" has fully downloaded a block from Netflix's seedbox, the block is stale, so why would any other user choose to download from a peer rather from netflix directly?

2. If all the users would prefer to download from netflix directly rather than a p2p user, then you already have a somewhat centralized solution, and you gain nothing from torrents.

replies(2): >>42161197 #>>42161766 #
1. eviks ◴[] No.42161766[source]
1. Because Netflix is at capacity? Or because the peer is closer and faster than the original?
replies(1): >>42162084 #
2. nemothekid ◴[] No.42162084[source]
If Netflix is at capacity and you have to wait for a peer, then you have simply reinvented the buffering problem. In other words

1. I exclusively download from a peer and my stream is measurably behind

2. I switch to a peer when Netflix is at capacity and then I have to wait for the peer to download from Netflix, and then for me to download from the peer. This will cause the same buffering issue that Netflix is currently being lambasted for.

This solution doesn’t solve the problem Netflix has

replies(1): >>42162129 #
3. eviks ◴[] No.42162129[source]
"Buffering problem" can have very different QOL manifestations, so :

1. You still get a better viewing experience without interruptions. Besides, your "measurably behind" can be an imperceptible fraction of a second?

2. Similar thing - shorter queues - the switch can happen faster due to the extra capacity

So yes, it does solve the practical problem, though not the theoretical one