6 ms·

What is the most efficient? What is the most reliable for NAT traversal for all of the various implementations?

laumars 10y ago
FTP doesn't support compression, error correction nor partial transfers. So any protocol that supports some or all of the above will improve efficiency and data reliability (reliability also affects efficiency too) As for NAT traversal, p2p protocols would obviously suffer the same issues but anything with a stronger client / server relationship would fair much better. Something like SFTP is a better alternative to FTP in those instances.
- __s 10y ago
  FTP does have some support for partial. One can request a specific start point in the file
  - laumars 10y ago
    Have you ever tried resuming a failed download using that feature though? Support for it is so bad that it's usually quicker to just redownload the whole file from scratch.
    - __s 10y ago
      I have actually, at work I made a tool which has a SQL server backup/compress into a folder which I then download via FTP to restore on another server. I was having connection issues so I made the downloader reconnect/resume on disconnnect, fixing the issue
- paralelogram 10y ago
  Some FTP servers support compression: http://www.proftpd.org/docs/contrib/mod_deflate.html http://www.proftpd.org/docs/contrib/mod_deflate.html
  - laumars 10y ago
    There's edge cases for nearly all of FTPs failings but none of them are employed as part of the default standard protocol. Which means nearly everyone ends up falling back to the lowest common denominator.
- mcguire 10y ago
  Given that FTP was mostly used to transfer compressed files, compression in the protocol wools be a bad idea as well as a layer violation. Error correction wasn't really necessary either (and is also possibly a layer violation).
  - laumars 10y ago
    Unfortunately neither of those two statements are true. 1) FTP predates widespread usage of compressed file formats by quite a long time. JPEG, MPEG formats (MP3, AVI, etc), ZIP archived XML documents formats (OOXML, ODF, etc), they're all comparatively new in relation to FTP. GIF is much older than the above but still more than a decade older than FTP and frankly GIF wasn't even that widely used pre-WWW where as uncompressed bitmaps like BMP and PCX were common place. However a lot of text files were copied around in the early days of FTP (hence why FTP has an ASCII transfer mode in addition to binary) and given the modem speeds of the era, compression would have really helped - albeit it's questionable whether the machines were powerful enough to do real time deflating even against text files. That isn't so much a problem these days so it's well worth having compression built into the protocol if just to catch that extra 5%. Even if you think you don't care as an end user, it matters to us sysadmins hosting high traffic servers :) 2) TCP does have a CRC-32 checksum but that doesn't help against failed downloads, memory or other hardware errors etc. A lot of more modern protocols will compare a source and destination hash of each chunk of data and/or the completed file to ensure that the two copies are identical. Frankly, I wouldn't trust FTP for archiving data for that reason alone.
    - matthiasl 10y ago
      "TCP does have a CRC-32 checksum" Where? TCP has a checksum in the header, but it is neither 32 bits nor is it a CRC.
      - laumars 10y ago
        Maybe I was thinking of the ethernet frame check instead of the TCP header? 32bit did seem a bit high when I wrote I must admit.
- Senji 10y ago
  You can bust NATs with something like Teredo or plain old DHT with a couple of bootstrapping nodes.
- skissane 10y ago
  > FTP doesn't support compression The FTP standard (RFC959) actually includes RLE compression (see section 3.4.3). (Almost no one implements it, since RLE is a pretty poor compression algorithm.)

FTP doesn't support compression, error correction nor partial transfers. So any protocol that supports some or all of the above will improve efficiency and data reliability (reliability also affects efficiency too) As for NAT traversal, p2p protocols would obviously suffer the same issues but anything with a stronger client / server relationship would fair much better. Something like SFTP is a better alternative to FTP in those instances.

__s 10y ago
FTP does have some support for partial. One can request a specific start point in the file
- laumars 10y ago
  Have you ever tried resuming a failed download using that feature though? Support for it is so bad that it's usually quicker to just redownload the whole file from scratch.
  - __s 10y ago
    I have actually, at work I made a tool which has a SQL server backup/compress into a folder which I then download via FTP to restore on another server. I was having connection issues so I made the downloader reconnect/resume on disconnnect, fixing the issue
paralelogram 10y ago
Some FTP servers support compression: http://www.proftpd.org/docs/contrib/mod_deflate.html http://www.proftpd.org/docs/contrib/mod_deflate.html
- laumars 10y ago
  There's edge cases for nearly all of FTPs failings but none of them are employed as part of the default standard protocol. Which means nearly everyone ends up falling back to the lowest common denominator.
mcguire 10y ago
Given that FTP was mostly used to transfer compressed files, compression in the protocol wools be a bad idea as well as a layer violation. Error correction wasn't really necessary either (and is also possibly a layer violation).
- laumars 10y ago
  Unfortunately neither of those two statements are true. 1) FTP predates widespread usage of compressed file formats by quite a long time. JPEG, MPEG formats (MP3, AVI, etc), ZIP archived XML documents formats (OOXML, ODF, etc), they're all comparatively new in relation to FTP. GIF is much older than the above but still more than a decade older than FTP and frankly GIF wasn't even that widely used pre-WWW where as uncompressed bitmaps like BMP and PCX were common place. However a lot of text files were copied around in the early days of FTP (hence why FTP has an ASCII transfer mode in addition to binary) and given the modem speeds of the era, compression would have really helped - albeit it's questionable whether the machines were powerful enough to do real time deflating even against text files. That isn't so much a problem these days so it's well worth having compression built into the protocol if just to catch that extra 5%. Even if you think you don't care as an end user, it matters to us sysadmins hosting high traffic servers :) 2) TCP does have a CRC-32 checksum but that doesn't help against failed downloads, memory or other hardware errors etc. A lot of more modern protocols will compare a source and destination hash of each chunk of data and/or the completed file to ensure that the two copies are identical. Frankly, I wouldn't trust FTP for archiving data for that reason alone.
  - matthiasl 10y ago
    "TCP does have a CRC-32 checksum" Where? TCP has a checksum in the header, but it is neither 32 bits nor is it a CRC.
    - laumars 10y ago
      Maybe I was thinking of the ethernet frame check instead of the TCP header? 32bit did seem a bit high when I wrote I must admit.
Senji 10y ago
You can bust NATs with something like Teredo or plain old DHT with a couple of bootstrapping nodes.
skissane 10y ago
> FTP doesn't support compression The FTP standard (RFC959) actually includes RLE compression (see section 3.4.3). (Almost no one implements it, since RLE is a pretty poor compression algorithm.)