Not just that. FTP sites have tendency to not fail. HTTP downloads are really hard to keep up at 2gb+ over someones wifi. Dropped connections are quite normal and doing the correct resume work is possible but not trivial in practice.
So for files FTP is much better. Especially if the other side is just a script.
This is just false. What evidence do you have? HTTP was architected for availability (load balancing across many servers). Also, FTP has two TCP connections per copy, doubling the chance of abrubt termination.
I've moved petabytes over the internet using FTP and HTTP. HTTP wins hands-down.
Practical experience in such an institute providing such data. FTP servers for files just run, http servers tend to do more things than just serving files. This could be separated out of course but in _practice_ they aren't. Setting up the http server right and not touching them is the hard part, not the actual http protocol part.
i.e. I do accept that http is a much better protocol than FTP but that social and organisational reasons lead to FTP being more stable and dependable in the field for large file download than http servers.
so your arugment is "http is more flexible so people misconfigure their servers and that affects availability".
that's a server config issue, nothing to do with either of the systems. If you're setting up a CDN (which is what these genomic servers are) you just configure the servers to serve files, nothing else.
My hundreds of aborted recursive FTP fetchs compared to my almost-never aborted recursive HTTP show that anything you're seeing about FTP being more stable is just a PEBKAC issue.
