Hi Jakob,
Thanks for your info. The openssl version currently we used to is 0.9.8r.
Also we need a clarification for one more thing.
Is there a way to cleanup the missed CTX from memory? Consider the below
scenario.
*File 1*
--> MD5_Init
--> MD5_Update
--> MD5_Update
--> MD5_Update
--> Missed MD5_Final
*File 2*
--> MD5_Init
--> MD5_Update
--> MD5_Update
--> MD5_Update
--> MD5_Final
Here we feel there could be a memory leak on openssl libraries when
MD5_Final() is missed. It would be better if an MD5_ReInit() or MD5_ReSet()
like functions which should clean up the previous missed CTX before calling
MD5_Init() for next file. Since we used to call Md5_Init(),MD5_Update and
MD5_Final from different places w.r.t application design if we missed
Md5_Final some leak will happen at openssl library level. Right?
Regards,
Prabu RM.
On Fri, Jan 27, 2012 at 9:29 PM, Jakob Bohm <[email protected]> wrote:
> Depends which of the OpenSSL APIs you use to do the hashing. Some give
> you a usable context pointer where you can access the bytes that need
> saving by following pointers into "internal" structures, others do not.
>
> However note that there is another problem in such cases: When a
> connection is interrupted, it is very common that the server and client do
> not completely agree on the exact byte offset of the interruption (because
> some bytes sent by the server never reached the client but were lost in
> hardware and software buffers). So the saved CTX will usually be for
> different byte offsets at each end and one end will have restart its MD5
> calls at a different byte offsets than where it restarts its transmission
> calls.
>
>
> On 1/27/2012 8:22 AM, Prabu RM wrote:
>
>> 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 <[email protected]<mailto:
>> [email protected]>**> 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 [email protected]
>> <mailto:openssl-users@openssl.**org <[email protected]>>
>> Automated List Manager [email protected]
>> <mailto:[email protected]>
>>
>>
>>
> ______________________________**______________________________**__________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [email protected]
> Automated List Manager [email protected]
>
