Carson,
My mistake- read "SSL", immediately started thinking "ssh",
and issues there. No excuse.
So- my comments aren't applicable to the SSL-for-real discussion -
apologies to the list.
(Aside: the issues with ssh are not about modifying TCP buffers.
They are about a fixed-size ssh-windowing behavior,
which happens "on top of" whatever TCP is allowing.
The end result is similar to having too-small TCP buffers.
That's what Chris' patch addresses - he allows the ssh-windowing
behavior to become dynamic, essentially tracking TCP's window size.
Current Linux releases do a good job of auto-tuning TCP buffers,
without need for manual adjustment. )
Again- sorry for the tangent.
Larry
--
At 1:21 PM -0700 4/18/07, Carson Gaspar wrote:
Lawrence D. Dunn wrote:
Colleagues,
If you do pursue SSL functionality directly in rsync,
please be sure to take a look at Chris Rapier's work
to "fix" standard ssh implementations, at:
http://www.psc.edu/networking/projects/hpn-ssh/
Turns out "-e ssh" using most libraries puts a fixed-window-size
ssh-windowing
behavior on top of TCP - so for large bandwidth*delay product paths,
even if you use large TCP buffers (which Wayne added for such paths),
an "un-fixed" SSL library can clobber overall performance/throughput,
even for a perfectly clean (no errors/loss) path.
SSL != SSH.
--
Carson
--
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
