[OpenSIPS-Devel] Re-organizing and de-duplicating digest code (related to the RFC8760 work)
Bogdan-Andrei Iancu
bogdan at opensips.org
Thu Oct 8 08:55:13 EST 2020
Hi Max,
I see candidate 3) as the best. We already have this approach (under
lib/ dir) for csv, path, registration related code.
The work you do looks very promising, thanks for your contribution on this.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit 2020 online
https://www.opensips.org/events/Summit-2020Distributed/
On 10/8/20 5:42 AM, Maxim Sobolev wrote:
> Hey folks,
>
> I am making good progress on implementing RFC8760 (SHA-XXX for digest
> auth), basically the UAS side is functional and tested against our
> Sippy Python implementation*. Trying to organize and clean the code
> as I go. Thanks to Liviu by the way for his help flushing some code
> cleanups and fixes!
>
> The problem that I am hitting now is that we have digest computation
> code duplicated in both modules (auth vs. uac_auth), which of course
> is less than ideal from many perspectives (2x code to test, code
> bloat, pain to add more algorithms etc).
>
> Now the question is what is the best way to deal with it. Couple of
> options I have:
>
> 1. Make uas_auth use code from the auth module and add it as a
> dependency. In general this seems to be the path the project takes to
> solve this problem. The downside is perhaps some small performance
> degradation as well some overhead to define and maintain API. Also
> this method does not work for smallish bits and pieces, too
> heavy-weight for an API.
>
> 2. Move code into the core. I think this is probably the wrong
> direction, some application might not need auth at all. Just listing
> it for completeness sake.
>
> 3. Move code into some kind of internal static library (say
> "libospcore.a") and link both modules against that library. I really
> like this approach since apart from some make-foo to get the library
> compiled and linked with each of modules, the rest is pretty much
> trivial. This avoids API/dependency overhead. With things like
> link-time-optimization becoming de-facto standard in the next 2-3
> years would give the best possible performance with very small size
> overhead. Also works great for useful functions that are too small for
> an API (for example function to convert binary into hex and the likes).
>
> Would love to hear what you guys think!
>
> -Max
> *)
> https://github.com/OpenSIPS/opensips/compare/master...sippy:RFC8760?expand=1
More information about the Devel
mailing list