Wiki: Ftpguide wiki page
Table of Contents
FTP (File Transfer Protocol) is a network protocol used to transfer files between two servers on a tcp based network. When talking about torrents FTP is mainly used in combination with seedboxes. You download the files via torrents on the server and connect with a FTP client to bring the files to your own pc.
SFTP is a different protocol that works on top of a encrypted SSH connection. Both the commands and data stream is fully encrypted. It's a totally different protocol though and only the name is similar to FTP. Since it works on top of TCP though the rest of the text still applies to SFTP.
Swish is believed to be a better option for typical Windows users than other SFTP clients because it is so easy to use. Download it now from the client list below and see for yourself. Swish adds support for SFTP to Windows Explorer so you can access your files on another computer securely via SSH. Swish is easy to use because it integrates seamlessly with Windows Explorer so working with remote files feels just like working with the ones on your local computer. Lastly, Swish is a Windows Explorer extension so you don't need to open a separate program to use it and therefore is not resource intensive.
Most of the questions regarding FTP have to deal with speeds issues. To explain why FTP does not always max out your home connection we have to take a look at the way the transport layer FTP uses works. Like mentioned above FTP uses TCP as it's transport layer. TCP is a great protocol, it has built in error detection, it numbers the packages so it can rebuild the file regardless of the way the packets arrive and it has native support for flow control. Flow control is responsible for deciding how fast the server sends the data to the client and is main factor that decides your download speed. When talking to a server the client requesting the data specifies a "receive window" it's a value that decides how much data it is willing to receive before reporting back to the server that it received all the packages. If for instance it announces to the server it's willing to buffer 256kb of data the server will send 256kb and then wait for the client to report that it received the 256kb in good order. It's this mechanism that's responsible for the loss of speed. If you are very close to the server (let's say 12 ms) it's not that much of a problem. The server will send 256kb and then pause for 12ms. This won't really effect the speed. However if you live in the US and you are connecting to a server in Germany this trip might take 130ms. This means for every 256kb the server sends it waits 130ms to send the next 256kb. That's why you can max out your download to one server but get a sucky 150kb/s on a different one.
An other annoying side effect is that the internet is constantly changing. One day your speed might be fine and the next it might be much slower (or much faster). This is because the peering/transit arrangements between providers constantly change. Because of this the route to your ISP might get better or worse from time to time. Usually this returns to normal but make sure you are using segments to get around any issues you might have.
tl;dr The further away you are from the server you are trying to download from the slower your download will be.
Don't give up just yet! There are techniques that can drastically improve your download speed. Clients like FileZilla can connect with multiple threads to one server. The TCP limitations I just talked about are working on a per thread basis. So if you are only getting 150kb/s, you are actually getting 150kb/s per thread connected to the server. By increasing the thread count you will also multiple your speed. If your residential line can do 1500kb/s you should set up your client to download with 10 threads. Each thread would be limited to 150kb/s but the total speed would still come up to the 1500kb/s your line can handle. This is called multi-threading. Note that this does not scale indefinitely. If you are on a 50Mbit line and only getting 50kb/s per thread creating 120 threads probably won't improve your speed as much as you think since most servers only accept a limited amounts of connection per ip to prevent flooding. Multi-threading will work fine if you are downloading the latest Phish concert since each song is it's own file and FileZilla will make a new connection for each file. However when you download the latest Ubuntu 12.04 LTS release which is one large iso file FileZilla can only create one thread. This is where multi-segmenting comes in. (I'm not sure this is the correct term but it's the one I decided to use) Multi-segmenting clients, like CuteFTP Pro or Free Download Manager can take that one file and split it up in several small parts. For each part it will create a thread to the server so it can download that one file with 10 threads bringing you close to the 1500kb/s limit again.
Your speed is limited per thread, increasing your threads increases your speed. Use a multi-segmenting client so you can use multiple threads even one single file downloads.
Here are a few client suggestions, on windows I am a big fan of Free Download Manager. It's sounds like scamware but it works really well and like the name implies, it's free!
Filezilla, multi-platform, supports threads but not segmenting.
Swish,SFTP Windows extension that supports threads and segmenting (Windows Explorer Extension) .
Free Download Manager,Windows, supports segmenting .
Cute FTP Pro,Windows, supports segmenting.
IFTP, Linux / OS X, supports segmenting .
Speed Download,OS X, supports segmenting .
Captain FTP, OS X, supports threads, supports segmenting.
SmartFTP,Windows, supports threads, supports segmenting, Paid.
Transmit, OS X, supports threads, does not support segmenting, Shareware .
Cyberduck, OS X, donate-ware.
BitKinex, Windows, supports threads, supports segmenting, Freeware.
|Last Author||Contributors||Versions||Last update|
|juggernaut||Alchemist||10||Mon, 14 Nov 2016 01:24:05 +0100|