Seni
asked on
how to enabling high performance data transfer on redhat linux 4.2
How to do Tuning of TCP for Linux 4.2 for maximizing data transfer over TCP
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I you have to repeat the transfer regularly please consider using rsync to transfer the data.
FTP is not secure by default, only if all parties concerned are setup to use SSL, (which pretty much gets ruined if NAT is involved somewhere), so it shouldn't be the first choice.
rsync might take longer the first time, but will only write updates afterwards.
FTP is not secure by default, only if all parties concerned are setup to use SSL, (which pretty much gets ruined if NAT is involved somewhere), so it shouldn't be the first choice.
rsync might take longer the first time, but will only write updates afterwards.
> FTP is not secure by default,
It depends on how do you use it.
Encrypt the file with "gpg" before transfer will improve the security.
In the internet, there is no such thing that is fully secure.
If the transfer speed is the highest priority, then use FTP with pre-encryption.
It depends on how do you use it.
Encrypt the file with "gpg" before transfer will improve the security.
In the internet, there is no such thing that is fully secure.
If the transfer speed is the highest priority, then use FTP with pre-encryption.
FTP doesn't secure the password transfer, or if it does it might not be able to cross a NAT.
> FTP doesn't secure the password transfer
agree. :->
agree. :->
FTP of compressed data is the most efficient transfer protocol for this. But, since the username and password are transmitted in the clear in an FTP transaction the security implications may preclude that. The next best method would be SFTP. Since you can control all (or any) of the eintermediate hops in this transfer there is nothing to be gained bt tuning the TCP stacks on either end.
rsync can do ssh encrypted transfers, it also compresses all data on the fly, based on continually computed checksums over chunks of data if can notice that some data has been modified (sender->receiver only, independent if you are pushing or pulling).
In that case it will send only the modified data.
Because of this incremental property rsync can always continue where it left off if you need to disconenct/reconnect.
In that case it will send only the modified data.
Because of this incremental property rsync can always continue where it left off if you need to disconenct/reconnect.
Default IP stack parameters especially for large data file transfers are not optimal. In that case you may wnat to look at tunning your tcp and udp send and receive spaces.
Also, an IP statck can be tuned for predictable latency as well to maximize throughput.
harbor235 ;}
ASKER