Recommended NAS for Deluxe eCinema transfers?

[James Gardiner]

The torrent technology is nothing more than technology. Its super reliable, as the pirate networks has shown. It is also super fast if orchestrated with a single mind behind its purpose. It can be made as fast as any content transfer protocol, and in some ways faster as it better navigates interconnect congestion. The ONLY real problem it has is the technology have given pirates the ability to distribute content at no cost. Allowing piracy to occur/flourish. Otherwise, the tech and others like it are solid. But yes, due to the dangers it poses to content gatekeepers, which cinemas and distributors are. There is a negative narrative from them on any technology that allows for this disruptive effect on industries like ours. But should that mean the industry should not take advantage of the technology for its own gain?

AWS is no more reliable than many other cloud providers. Content delivery is non-real time and does not need to be that reliable. I would say you want to use an implementation that specifically is not built to 99.9999 as that is 2-3x the cost and does not benefit the use model we are talking about.
i.e. you send a DCP to a site 1-2 weeks before its needed. Who cares if the link goes down or the cinema turns of its power at night. it WILL defiantly still arrive in time by automatically recovering from all interruptions, as it is designed to do so.

[Scott Norwood]

I think that you're missing how businesses think. If a large company wants to get data from here to there, said company is going to want contracts and SLAs and someone to sue when it doesn't work. A torrent network offers none of that. Again, it's great for distributing free software, but not for most business applications. That is one of many reasons why AWS, Azure, Google Cloud, Oracle Cloud (!), and all of the rest exist.

[Frank Cox]

Unless I'm misunderstanding how bittorrent works (which is definitely possible) I don't see how getting a movie through that would be significantly slower than getting it the way we do now.

If the movie company (or whoever) ran a "supernode" then you would start pulling the movie from them and if someone closer to you had it you might pull some of the movie from that guy as well.

But the worst case scenario would be that you end up pulling the whole movie from the single source supernode, and I don't see much difference between that and the way we get 'em here now.

[James Gardiner]

Torrent type distributed delivery would likely be faster and more efficient, as it better traverses interconnects that may be congested. As once the data has traversed over that congested link, all sites on the other side share that data effectively with each other. So technically it should be faster to do a wide delivery. (Over a typical 1-3 shared hosted sources.) But Again, it still would be best to have at least 2 dedicated and strategically position hosted data sources to ensure prompt delivery (Of one-off titles) and redundancy.

Otherwise, its as fast as a single or multi stream ftp/https transfer as is used by a lot of the delivery technologies we currently use. https is common as it's fast, prioritised and encrypted. That's what I use in my person version I created for moving DCP around if I need to. (From my understanding, goflix uses https as well, based on the libraries seen in the desktop version of the delivery tool)

The biggest issue with torrent type delivery is that the cinemas need to be aware that a portion of the uplink bandwidth is used. But this basically adds to the overall performance of the total network. For example a server with a 10Gbe interface at a cloud host, compared to 300 sites the target DCP is going to all offering say, 50mbit uplink each. 50x0.05GBe = 25Gbe (And its free)

Its a no-brainer really. But technologies like this are swayed by the studios. I don;t expect anyone would be comfortable saying to them.... "We plan to use Torrent technologies to deliver DCPs" is going to go well.
The work "Torrent" is a trigger word to Studios/Distributors.
But at the end of the day, its just a implementation of a file transfer technology.

[Justin d'Entremont]

From my understanding, goflix uses https as well, based on the libraries seen in the desktop version of the delivery tool

I'll second that, my firewall shows HTTPS outbound to their servers / AWS.

[Frank Cox]

That surprises me because I was always under the impression that http was not optimized or recommended for large file transfers.

[James Gardiner]

That surprises me because I was always under the impression that http was not optimized or recommended for large file transfers.

The system break up the https requests into chunks. And secondly, https traffic will not be given a low priority by larger networks as.. Everyone uses https for viewing web pages, and the service providers what that to be snappy. So, file transfers hide in this traffic and so will not be prioritised down.
Thats exactly why I took this path. Plus you get encryption for free in the implementation,

[Harold Hallikainen]

I don't see why HTTP would not be appropriate for a large file. HTTP is just a few headers within a TCP stream. If there is concern about the TCP stream dropping, a Range header can be included in the request to request the part of the file that was missed. It's not appropriate for real time delivery where it is better to drop packets than retransmit them, but DCP delivery is not real time, and accuracy is important.

I stream 8 to 12 hour audio files with HTTP(S) at https://w6iwi.org/rtty/audio/npr/ . These are small compared to a DCP (these files are about 200 MB).

I do agree that bit torrent could be used to spread out the sender load. It also reduces overall internet loading by using the closest sources of the data instead of some single distant server. There are also content delivery networks that can similarly reduce the load on the sender and reduce the circuit distance the data passes through. But it seems like bit torrent scales automatically where more receiving systems increases the number of sending systems.

I'm impressed with bit torrent!

[Ryan Gallagher]

I feel like if they wanted to use torrent on the backend it would probably come in the form of a "content box" not unlike some of what is in the field now, and an agreement to permit some upload, effectively turning each venue into part of the distributed delivery network. They'd have to exert a lot of control as to what stays on the "box" and is not user deleted to make it worth the while. They probably wouldn't advertise they are using bitTorrent either for reasons already stated.

Could they do it entirely in software, yes. But would they, seems unlikely.

At this stage all to end transfer protocols are effectively interchangeable, minus some differences like native encryption etc or what networks pioritize. Most of the "box" approaches probably rely on variation of rsync over ssh, or a VPN back to the mothership.

[Hong Sung Hyeok]

For end-user-level maintenance, it's hard to find an alternative to Synology.