3 ms·

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 a

by jerven 10y ago

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.

dekhn 10y ago
None of this is true. FTP is just bytes over TCP, it's just as prone to problems. HTTP recovery is far simpler because of ranged GETs. FTP is definitely not better.
- jerven 10y ago
  Yeah, but in practice ranged GETs and HTTP servers are more likely to be down than the FTP servers.
  - dekhn 10y ago
    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.
    - jerven 10y ago
      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.
      - dekhn 10y ago
        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.
        infinite8s 10y ago
        You and the parent aren't really disagreeing.

by jerven 10y ago

dekhn 10y ago

None of this is true. FTP is just bytes over TCP, it's just as prone to problems. HTTP recovery is far simpler because of ranged GETs. FTP is definitely not better.

jerven 10y ago
Yeah, but in practice ranged GETs and HTTP servers are more likely to be down than the FTP servers.
- dekhn 10y ago
  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.
  - jerven 10y ago
    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.
    - dekhn 10y ago
      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.
      - infinite8s 10y ago
        You and the parent aren't really disagreeing.