Re: The conclusion regarding resume patch

Girish Venkatachalam wrote:

> I would say it is very basic compared to other fancy
> features like multiple simultaneous file transfers and
> all that.

Whether or not a feature is fancy really depends on your needs. I
support a community that regularly using OC12s as their lower end long
haul paths and 30Gb+ paths at the higher end (I2 and ETF research
networks). Once the speed issues with SSH were resolved the two main
features they want are a more intelligent approach to multiple file
transfers in scp and a resume function (even at 800Mb/s when a 2TB
transfer dies 1GB from the end its really annoying).

Also just so you know, I was supporting your position regarding the
resume feature.

> To argue Damien's point again, we can have a protocol
> check in the beginning the way we have to check
> protocol 1 and 2, in the connect string, and
> interoperate.

Having had to play with that quite a bit for the HPN patch
(www.psc.edu/networking/projects/hpn-ssh) dealing with versioning issues
is pretty annoying and it rarely seems to be as straightforward as one
would hope. While I'm not saying you shouldn't consider this it can
really open up a can of worms. The main reason why I suggested a new
incarnation of SCP as opposed to patching the old one was really to get
around some of these issues.

Chris

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev