> has a hardcoded maximum receive buffer of 2MiB

For completeness, I want to add:

The 2MiB are per SSH "channel" -- the SSH protocol multiplexes multiple independent transmission channels over TCP [1], and each one has its own window size.

rsync and `cat | ssh | cat` only use a single channel, so if their counterparty is an OpenSSH sshd server, their throughput is limited by the 2MiB window limit.

rclone seems to be able to use multiple ssh channels over a single connection; I believe this is what the `--sftp-concurrency` setting controls.

Some more discussion about the 2MiB limit and links to work for upstreaming a removal of these limits can be found in my post [3].

Looking into it just now, I found that the SSH protocol itself already supports dynamically growing per-channel window sizes with `CHANNEL_WINDOW_ADJUST`, and OpenSSH seems to generally implement that. I don't fully grasp why it doesn't just use that to extend as needed.

I also found that there's an official `no-flow-control` extension with the description

> channel behaves as if all window sizes are infinite. > > This extension is intended for, but not limited to, use by file transfer applications that are only going to use one channel and for which the flow control provided by SSH is an impediment, rather than a feature.

So this looks exactly as designed for rsync. But no software implements this extension!

I wrote those things down in [4].

It is frustrating to me that we're only a ~200 line patch away from "unlimited" instead of shitty SSH transfer speeds -- for >20 years!

[1]: https://datatracker.ietf.org/doc/html/rfc4254#section-5

[2]: https://rclone.org/sftp/#sftp-concurrency

[3]: https://news.ycombinator.com/item?id=40856136

[4]: https://github.com/djmdjm/openssh-portable-wip/pull/4#issuec...