Menu
▾
▴
#6 rs_mdfour family can't be used with librsync >= 0.9.6?
It appears that rs_mdfour family of functions has
trouble in 0.9.6 because "struct rs_mdfour" is no
longer defined. Further, it appears that
rs_mdfour_begin still expects a pre-allocated buffer to
be passed in, so this can't be an anonymous type (we
need to allocate storage from the caller). librsync
0.9.5 defined struct rs_mdfour in rsync.h. This
definition has now been moved into mdfour.h, which
further depends on types.h.
None of these problems will surface if you only use the
whole file API: rs_mdfour_file. Unfortunately a bunch
of other stuff that uses buffer APIs:
rs_mdfour_{begin,update,result} will break.
Logged In: YES
user_id=10273
The plan is to move to a libmd/RSA API, allowing librsync to
use libmd's md4 implementation.
We will continue to include a version for platforms that
don't have libmd. Even on platforms that do have libmd, the
implementation we provide might be faster.
Logged In: YES
user_id=521
In my measurements the mdfour routines in librsync were
substantially faster than those in the version of libmd that
I downloaded from abo's site.
I guess the function should be added back into the public
interface.
Logged In: YES
user_id=10273
Ummm, which version of libmd would that have been? What
platform?
I have ported the librsync mdfour to the libmd API and made
it slightly faster again. I have also fixed the "non-int
aligned char *" problem by only enabling the "cast (char *)
to (int *)" optimisation for i386, not just any little
endian platform. I've benched mine vs libmd's, and mine is
nearly 2x as fast on i386.
I've also looked at the md4 library code in openssl. It
seems that right now libmd is loosing ground against openssl
as the prefered implementation.
It has the same API as the RSA code in libmd, except for
slight differences in the names (MD4_Update instead of
MD4Update etc). Nothing that a few configure driven
#define's can't fix.
The code is scary complex. It has two completely different
implementations for the little-endian+char aligned int * vs
other platforms. I suspect it will be the fastest
implementation, but wouldn't be surprised if all the
complexity ends up producing something slower.
I think librsync should switch to the libmd API, and provide
configure support for using openssl vs libmd vs our own
implementation.
Logged In: YES
user_id=10273
Ummm, which version of libmd would that have been? What
platform?
I have ported the librsync mdfour to the libmd API and made
it slightly faster again. I have also fixed the "non-int
aligned char *" problem by only enabling the "cast (char *)
to (int *)" optimisation for i386, not just any little
endian platform. I've benched mine vs libmd's, and mine is
nearly 2x as fast on i386.
I've also looked at the md4 library code in openssl. It
seems that right now libmd is loosing ground against openssl
as the prefered implementation.
It has the same API as the RSA code in libmd, except for
slight differences in the names (MD4_Update instead of
MD4Update etc). Nothing that a few configure driven
#define's can't fix.
The code is scary complex. It has two completely different
implementations for the little-endian+char aligned int * vs
other platforms. I suspect it will be the fastest
implementation, but wouldn't be surprised if all the
complexity ends up producing something slower.
I think librsync should switch to the libmd API, and provide
configure support for using openssl vs libmd vs our own
implementation.