reget reput again...

[Dan Kaminsky]

Rsync does this (indeed, it's how I do reget/reput right now.)

It's ungodly slow for large files.

--Dan


Damien Miller wrote:

>I think a better option is to have an extension to take a checksum over
>a file, or an arbitrary subset of one. re(get|put) could then validate
>the file before continuing with it.
>
>This would be quite easy to do using the draft-secsh-filexfer
>protocol's vendor extension mechanism, if someone want to try to
>beat in implementing it :)
>
>If anyone is interested, please discuss your proposed design on-list.
>
>-d
>
>Darryl L. Miles wrote:
>  
>
>>Ben Lindstrom wrote (a very long time ago) :
>>
>> >The problem is in some cases the data being sent to you may be out of
>> >order (thankful no sftp server does this yet). So reget/reput without RFC
>> >clearifications can lead to bad file transfers.
>> >
>> >I'm trying to drag up in my mind which one was the problem... I believe
>> >reput is fine since the client has control over the ordering. reget is
>> >the troublesome some one without RFC clarifications stating out of order
>> >transfers are denied.
>> >
>> >if the RFC get clarified to disallow out of order transfers then a cleaned
>> >up version of this patch may not have a problem getting in.
>>
>>
>>It seems everyone body has a patch for this but it still can't quite 
>>make it into any official distribution.  Not wanting to stifle technical 
>>progress down surely the standards body have mechanism to allow new 
>>concepts to be experimentally deployed without affecting non-cooperating 
>>parties ?
>>
>>Is it really necessary to get RFC clarification on this, maybe its 
>>useful to leave as-is and have the option to execute out-of-order for in 
>>uses.
>>
>>Would it be possible to extend the channel initialisation options to 
>>negotiate a feature requesting "mandatory in-sequence execution of 
>>commands within this channel".  I'm not sure how these options are 
>>created or assigned but maybe use some OpenSSH naming space until a 
>>standard group either accepts or rejects the concept and assigns it a 
>>standard option name.
>>
>>Non-conforming servers would not understand the option and the client 
>>could then disable the reget/reput commands from use in that session.
>>
>>I do not know enough about the OpenSSH implementation to know if its 
>>possible for it to ever execute commands out of sequence with respect to 
>>the channel they are in nor the contraints this may pose to future 
>>maintainace of OpenSSH.
>>
>>To confirm the scope of the option suggested, it says nothing about any 
>>other channel nor the order in which channels are attended to within the 
>>server, this stays as-is.
>>
>>
>>RFC ?  Please Cc your reply Thanks.
>>
>>
>>    
>>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>