Hacker News Reader

Comment by otterley | Hacker News Reader

For one thing, SSH performance for large transfers is abysmal over high-latency links. SSH uses a small TCP window size because it was optimized for quick response, not bulk transfers. (After all, it was designed to be a remote shell protocol, not a generic file transfer protocol; scp and sftp were added after the fact.) And unfortunately you can't currently specify a different buffer size even if you wanted to.

More information can be found here: http://www.psc.edu/index.php/hpn-ssh

View on HN

> scp and sftp were added after the fact

scp was there from the beginning, or thereabouts. It certainly was present the first time I played with it which was within a few months of the first release.

ssh was specifically designed as a replacement for BSD remote tools (rsh/rlogin/rcp) even falling back to those protocols if ssh wasn't available (although the FallBackToRsh option was removed from OpenSSH a decade or so ago I think). That's also why "slogin" is installed as a symlink to "ssh", to keep it similar to rsh/rlogin. It only made sense for there to be a "scp" to work like the existing "rcp".

You are right that sftp only came later.

Are there any plans to patch this into OpenSSH? It looks like they have a great solution for the problem you highlighted.

Those patches are old. My understanding is that the parts that are reasonable have been implemented and the parts that aren't (plaintext modes) have been ignored.

If you need to transfer large files around a lot use what the supercomputing centers use: GridFTP.

I'd never even heard of GridFtp before. It looks pretty good. I've taken to not installing ftp on servers at all and just using ssh, but this might make me think again.

A solution would be to have some kind of protocol revolving around ssh, that would open one ssh session, and use other socket connections to do other stuff, like ftp, scp, wget, etc...

Would be pretty hairy though. Maybe another solution would be to have some new socket standard that can achieve what both UDP and TCP do, at some kind of variable window size...

Reply on news.ycombinator.com