Ask HN: Why isn't a content addressable cache built into the Internet?

Re:Ask HN: Why isn't a content addressable cache built into ... by slysf on Tuesday March 01, 2011 @08:19PM (#2278064)

I worked at a big streaming media company and there are significant DRM challenges with serving video in a way that protects the content. When you're trying to get serious content deals from producers they will dive into the deepest level of how you handle their content to make sure it meets their own internal standards before agreeing to anything. Companies like BitGravity are developing solutions that meet these requirements. One idea might be to expire the hashes in a 5 minute rolling window which would still give a huge caching advantage to ISPs:

1. ClientA is authorized with video service. 2. ClientA gets 50mb of hashes to buffer 3. ClientA starts downloading hashes sequentially, requesting more hashes from the service as the queue is emptied. 4. ClientB is authorized with the video service. 5. ClientB requests same resource and gets same list of hashes. 6. ISP can cache the hashes for 5 minutes and get some savings for popular content.

I think this would be a very good solution for live broadcast where you're looking at a huge number of people requesting the same content, but for VOD it would have limited return.

[ Parent | on HN ]

Re:Ask HN: Why isn't a content addressable cache built into ... by mckoss on Wednesday March 02, 2011 @09:33AM (#2279646)

If you recognize that a hash is equivalent to the content, you realize you have to wrap DRM around the hash lists, just as you would the original content.

Perhaps limiting the cache lifetimes would give some legal protection to network operators. Nobody is sending take-down notices for network caches today, are they? I would love to see this protocol have some legal safe harbor - perhaps based on a limited (24 hour) TTL before requiring refreshing the cache from source (which could just be a "ping" w/o retransmitting the whole chunk).

[ Parent | on HN ]