Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

Off-topic: can someone provide a good reason why SSH w/ the HPN patches is not the default for every SSH install on every platform?

Today, people are relying on SSH for binary transfer more than ever. SFTP and SCP are the new defacto file transfer standards between machine to machine over a secured connection. Source control like GIT (or even SVN) make heavy use of binary transfers over SSH. The performance benefit to the entire world is immeasurable. Yet unless you explicitly go out of your way to manually compile and install SSH-HPN, you don't get it.

That said, given how slow SSH is on Windows (GIT pushes and pulls are exponentially slower than on *nix or OS X), does anyone have a good link to a Putty HPN build?

View on HN

I have to admit I felt pretty ignorant for not knowing what you were talking about. So, for anyone else in a similar situation: http://www.psc.edu/index.php/hpn-ssh

Don't. It's a very esoteric topic. Hence my frustration - I wish it weren't so!

Presumably because the patch introduces intermittent bugs that are not fully understood (disconnects iirc).

It's pretty much unmaintained.

Every host it's installed on has to be properly tuned. Fine for large setups where finely tuned TCP stacks are the norm and maintaining your own ssh isn't much overhead, probably not fine for most setups where the 2MB buffer does the job. "To compute the BDP, we need to know the speed of the slowest link in the path and the Round Trip Time (RTT)". Do you know the slowest link in the path for everything you want to conceivably connect to?

The patches were an exercise in trying to max out high bandwidth connections using scp under ideal lab conditions, nothing more.

The none cipher switch was always a turn off for a lot of people.

iirc, it's off by default?

Even when enabled, it'll only not encrypt binary blobs; TTY input will remain encrypted. Obviously many times that is not an option, but sometimes it is.

So you are not worried about the confidentiality of your data?

Leaving aside the crypto worries and concerns over why it was not merged upstream can you imagine being the Debian package maintainer? Having to manage and triage bug reports with two upstreams? And then having to keep track of whether the bug occurred when HPN initiated a connection to pristine upstream, pristine connects to HPN or HPN connects to HPN? If you want to get an idea of the headache involved site:debian.org ssh hpn.

Have you read why upstream never merged it? The pleas for funding and lack of maintainer time do not give you cause for concern?

Reply on news.ycombinator.com