4 ms·

Ftp is still the fastest file transfer protocol , when you invent something better then you can moan otherwise plz go to fail.

cm2187 11y ago
... for large files.
kba 11y ago
Everything unencrypted will always be faster than the encrypted counterpart. Do you also deliberately avoid HTTPS? And is that minuscule performance gain really worth the risk with FTP?
- cm2187 11y ago
  Not convinced https is a simple substitute for ftp. Think of the new asp.net MVC framework. The http root directory is not the root directory of the MVC app, but a sub directory (which by the way is a good design decision, separating executable from static content). So with https you will only have access to a subdirectory of the application you need to deploy. Not sure you will be able to use https to deploy. ftpes sftp and ftps are alternative solutions but I found them to be extremely incompatible between softwares. I never managed to get filezilla ftp client to connect to a secure IIS ftp server. And Visual Studio can't deploy to secure ftp, etc.
  - kba 11y ago
    I did not mean to say that HTTPS was a substitute for FTP. You said that FTP was the fastest protocol, and the only reasonable explanation for why FTP could be faster than anything else would be due to the lack of encryption. Therefore, I asked if you also avoided HTTPS (and only used HTTP), since HTTP clearly is faster than HTTPS. But if you didn't mean to say that FTP is the fastest due to the lack of encryption, then why do you think FTP is the fastest?
Zr40 11y ago
What makes you think so? Nothing in the FTP protocol makes it faster than, say, HTTP, yet FTP requires more network round-trips to initiate each file transfer.
creshal 11y ago
Even SCP easily saturates a GBit line with negligible overhead, where is FTP significantly faster?
masklinn 11y ago
Faster for what kind of transfer? Surely for retrieval it won't be noticeably faster than HTTP, and may be significantly slower? FTP has the advantage of no metadata (possibly significantly less overhead on a small file) that's traded for way more round trips, no transparent compression, no persistent connections and limited to no pipelining. And if you want to push files SFTP, SCP or rsync over ssh will do that just fine. If you don't care about security and you can't saturate your network connection by default you can just use RC4.

cm2187 11y ago

... for large files.

kba 11y ago

Everything unencrypted will always be faster than the encrypted counterpart. Do you also deliberately avoid HTTPS? And is that minuscule performance gain really worth the risk with FTP?

cm2187 11y ago
Not convinced https is a simple substitute for ftp. Think of the new asp.net MVC framework. The http root directory is not the root directory of the MVC app, but a sub directory (which by the way is a good design decision, separating executable from static content). So with https you will only have access to a subdirectory of the application you need to deploy. Not sure you will be able to use https to deploy. ftpes sftp and ftps are alternative solutions but I found them to be extremely incompatible between softwares. I never managed to get filezilla ftp client to connect to a secure IIS ftp server. And Visual Studio can't deploy to secure ftp, etc.
- kba 11y ago
  I did not mean to say that HTTPS was a substitute for FTP. You said that FTP was the fastest protocol, and the only reasonable explanation for why FTP could be faster than anything else would be due to the lack of encryption. Therefore, I asked if you also avoided HTTPS (and only used HTTP), since HTTP clearly is faster than HTTPS. But if you didn't mean to say that FTP is the fastest due to the lack of encryption, then why do you think FTP is the fastest?

Zr40 11y ago

What makes you think so? Nothing in the FTP protocol makes it faster than, say, HTTP, yet FTP requires more network round-trips to initiate each file transfer.

creshal 11y ago

Even SCP easily saturates a GBit line with negligible overhead, where is FTP significantly faster?

masklinn 11y ago

Faster for what kind of transfer? Surely for retrieval it won't be noticeably faster than HTTP, and may be significantly slower? FTP has the advantage of no metadata (possibly significantly less overhead on a small file) that's traded for way more round trips, no transparent compression, no persistent connections and limited to no pipelining. And if you want to push files SFTP, SCP or rsync over ssh will do that just fine. If you don't care about security and you can't saturate your network connection by default you can just use RC4.