Hi Jakob,

Thanks for your reply and we will try as you say. Is there any other way to
store the CTX at block level in RDBMS like MySQL? Say if the transfer is
interrupted at 500 MB and i know at which block the transfer has been
interrupted. In same scenario if i know the CTX of already sent block then
it will avoid the process of MD5 update of already stored 500 MB before the
next transfer schedule. Simply is it possible to get the CTX at block level
and proceed?

Regards,
Prabu RM.

On Thu, Jan 26, 2012 at 7:21 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:

> On 1/26/2012 7:25 AM, Prabu RM wrote:
>
>> Hi,
>>
>> We have been used to CRC via MD5 hash algorithm for a file to be
>> transferred in socket we kepp below steps.
>>
>> _*At Client side:*_
>>
>>
>> 1.Md5 Init()
>> 2.MD5 Update
>>   MD5 Update
>>   MD5 Update
>>   MD5 Update
>>   .
>>   .
>>   .
>> 3.MD5 Final
>>
>> 4.Get Checksum *C1*
>>
>> _*At Server side:*_
>>
>>
>> 1.Md5 Init()
>> 2.MD5 Update
>>   MD5 Update
>>   MD5 Update
>>   MD5 Update
>>   .
>>   .
>>   .
>> 3.MD5 Final
>> 4.Get Checksum *C2*
>>
>> *if(C1 == C2)
>>
>> {
>>    crc is sucess!
>> }
>> *
>> What my case is if i transfer a file with large size about 1GB and if the
>> socket closed at the time of file reaching 500MB and i re-transfer the file
>> in next schedule. In this how can i work with MD5,SHA hash algorithms where
>> i wish "Where it left off"?
>>
>> Could you please help me? Simply how can i handle CRC of incomplete file
>> in next schedule? Is there any other way rather than transferring entire
>> file?
>>
>> Regards,
>> Prabu RM.
>>
> Simple:
>
> At Server side first pass the bytes from the previously
> received 500MB to MD5 Update, then the bytes of the
> sent 500MB, so MD5 Update gets the same bytes as for a
> full transfer but with only the missing bytes
> transferred.
>
> At Client side first pass the 500MB that will not be
> sent to MD5 Update, then the 500MB that are sent.
>
> If you use HTTP with the "Range" and "MD5-something"
> headers for this job, be sure your client handles the
> possibility of the server choosing to send a larger
> fraction of the file than requested (it is allowed to
> do that, by specifying a different range or the entire
> file in its response HTTP headers).  For the excess
> bytes you can decide to use either the newly received
> of the previously received values of those bytes, just
> make sure you give MD5 Update the bytes that you will
> actually put/keep in the final file.
>
> ______________________________**______________________________**__________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>

Reply via email to