Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm

[Anthony Bryan <[e-mail]>]

On Tue, Jan 18, 2011 at 11:16 AM, Robert Oslin <[e-mail]> wrote:
> I like the idea of an intermittent 213 reply that would effectively ask the client to hang in there (maybe reset its timeout counter, perhaps with a client defined hard limit to the number of resets in order to prevent malicious use).
>
> This seems in accord with RFC959 section 5.4: Certain commands require a second reply for which the user should also wait.  These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection.  They are secondary replies to file transfer commands.
>
> Anthony, could a provision be made such that a server MAY return a 213 reply every N seconds (5, 15, other) for long running hash operations? I think that would be especially useful if SHA-256 ends up being the default recommended and implemented hash algorithm.

I think we can do anything that is internally consistent within the
FTP universe and seems logical for the published FTP RFCs. :)

> Alternatively client logic could be made to auto-extend the internal timeout when making a hash request for a large file. The draft could recommend either/or approach.
>
> Robert Oslin
>
>
>
>
> -----Original Message-----
> From: Daniel Stenberg [mailto:[e-mail]]
> Sent: Tuesday, January 18, 2011 10:01 AM
> To: Robert Oslin
> Cc: [e-mail]
> Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm
>
> On Tue, 18 Jan 2011, Robert Oslin wrote:
>
>>>> I personally think CRC32 is too weak for multi-gigabyte files.
>>
>> Do you mean that CRC32 is weak period?
>
> CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets weaker
> the more data to try to check with it. Having a CRC32 field for a sufficiently
> small amount of data will be fine IMO - but that's not what we design for
> here.
>
>> One may argue that the "weaker" the hash the faster it will compute, making
>> it ideal for use with larger files (in order to mitigate the chance of
>> client timeouts).
>
> Clients don't have to timeout. The server can easily send "213-" lines every
> 5-10 seconds or so while calculating the hash. Or is there a reason why not?




-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads