[squid-dev] Converting squid to library

[Amos Jeffries]

On 02/08/18 18:32, Manju Prabhu wrote:
> Hi,
> I plan to use Squid for ssl-proxy in my project. However, I have my own
> data-path and TCP stack I want to try it out with for performance
> reasons. The TCP stack could be in user-space for example, if I use DPDK.
> 
> * Is there any potential pitfalls if I embark on this task?

The first one is that Squid is is a collection of binaries and processes
working together to process traffic. Not suitable for being a library.


> * Is it better to convert squid to a library and link it to my process
> along with DPDK (Option A)? Or is it better to try to link DPDK to squid
> (Option B)?

Neither if you can avoid it. Option B only if you have to.

Squid uses POSIX API for I/O. So if you are providing POSIX API from
your TCP stack it should be as simple as building Squid with the
appropriate ./configure CXXFLAGS, CFLAGS, and LDADD build options to
link your stacks library/objects.

If you have done some non-standard API you will have to write a mapping
between it and POSIX functions. Doing that in your own code simplifies
things considerably - especially for your codes prospects being used
widely, but it can be patched into Squid if necessary.

Also, many TLS/SSL I/O operations are done through the system TLS/SSL
library. Not by Squid at all. So there is additional complication
rebuilding that library against your stack before Squid can use it.
Having the standard POSIX API which both can access is much easier and
better than any custom API.



> * With squid I see that separate threads are created to manage
> certificate mimicking etc. Do all of that get complicated with Option A? 

Not threads. Processes. Squid is running independent
binaries/interpreters, and forking itself sometimes as well. Thus your
Option A is not an option.


> 
> I apologize in advance for some open ended questions. Please point me to
> the right forum if these questions are not valid here.
> 

This is the right place.

Amos