<div dir="ltr"><div>Hi Amos,</div>Sure, thanks. <div><br></div><div>Initially, I am planning to try to use f-stack. Something, similar to <a href="https://github.com/F-Stack/f-stack/blob/master/doc/F-Stack_Nginx_APP_Guide.md">https://github.com/F-Stack/f-stack/blob/master/doc/F-Stack_Nginx_APP_Guide.md</a><div>F-stack provides wrappers around POSIX APIs.<br><div>So, apart from squid and open-ssl, would I need to re-build anything else?</div></div><div><br></div><div>Thanks,</div><div>Manju</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 2, 2018 at 3:16 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/08/18 18:32, Manju Prabhu wrote:<br>
> Hi,<br>
> I plan to use Squid for ssl-proxy in my project. However, I have my own<br>
> data-path and TCP stack I want to try it out with for performance<br>
> reasons. The TCP stack could be in user-space for example, if I use DPDK.<br>
> <br>
> * Is there any potential pitfalls if I embark on this task?<br>
<br>
</span>The first one is that Squid is is a collection of binaries and processes<br>
working together to process traffic. Not suitable for being a library.<br>
<span class=""><br>
<br>
> * Is it better to convert squid to a library and link it to my process<br>
> along with DPDK (Option A)? Or is it better to try to link DPDK to squid<br>
> (Option B)?<br>
<br>
</span>Neither if you can avoid it. Option B only if you have to.<br>
<br>
Squid uses POSIX API for I/O. So if you are providing POSIX API from<br>
your TCP stack it should be as simple as building Squid with the<br>
appropriate ./configure CXXFLAGS, CFLAGS, and LDADD build options to<br>
link your stacks library/objects.<br>
<br>
If you have done some non-standard API you will have to write a mapping<br>
between it and POSIX functions. Doing that in your own code simplifies<br>
things considerably - especially for your codes prospects being used<br>
widely, but it can be patched into Squid if necessary.<br>
<br>
Also, many TLS/SSL I/O operations are done through the system TLS/SSL<br>
library. Not by Squid at all. So there is additional complication<br>
rebuilding that library against your stack before Squid can use it.<br>
Having the standard POSIX API which both can access is much easier and<br>
better than any custom API.<br>
<span class=""><br>
<br>
<br>
> * With squid I see that separate threads are created to manage<br>
> certificate mimicking etc. Do all of that get complicated with Option A? <br>
<br>
</span>Not threads. Processes. Squid is running independent<br>
binaries/interpreters, and forking itself sometimes as well. Thus your<br>
Option A is not an option.<br>
<span class=""><br>
<br>
> <br>
> I apologize in advance for some open ended questions. Please point me to<br>
> the right forum if these questions are not valid here.<br>
> <br>
<br>
</span>This is the right place.<br>
<br>
Amos<br>
______________________________<wbr>_________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org">squid-dev@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-dev</a><br>
</blockquote></div><br></div>