[systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

[Marcel Holtmann]

Hi Zbyszek,

>> As it has been discussed in the systemd hackfest during the Linux Conference
>> Europe, one daemon could centralize the management of all network proxy
>> configurations. Idea is something user can do per-application (like in
>> firefox for instance) or broader (per-DM like in Gnome), user could do it
>> once and for all through such daemon and applications would then request it
>> to know whether or not a proxy has to be used and which one.
>> 
>> As a notice, this is nothing new. Such standalone daemon has been already
>> done by the past, pacrunner. systemd-proxy-discoveryd will more or less
>> implement the same ideas with improvements. It will get rid of big JS
>> engines like spidermonkey or v8 which are overkill for the tiny PAC files
>> to be executed on, for instance. From pacrunner experience, APIs will be
>> also improved.
> Hi,
> 
> the idea of having centralized proxy config is certainly nice. But the
> PAC files make me shiver. So the first question: is it really necessary
> to support PAC files? Are they widely used in corporate setting or something?
> Is there no saner standard?
> 
> If the PAC files must be interpreted, I think this is the hardest
> part.  FindProxyForURL is started for every request, potentially
> hundreds of times per second and more. This means that starting a
> process per invocation is out of the question, and even starting a
> thread per invocation seems to be too much. But each call fall into an
> infinite loop and hang. So the run time of FindProxyForURL should be
> bounded. FindProxyForURL can also resolve names over the network,
> which would best be done asynchronously.
> 
> Things in systemd are usually implemented through poll loops, which
> makes it easy to support thousands of concurrent "jobs". I'd think
> that this would be the best option here too, with a number of "workers"
> executing FindProxyForURL()s and stopping when name resolution is
> requested and continuing when the name is resolved.

PACrunner is an existing implementation of this concept. It uses threads and seems to work just fine. We bridged libproxy API compatible library that talks to the PACrunner over D-Bus.

I am confused why everybody worries about DNS here. Just use C library name resolving calls. Let it resolve it and be done with it. You are synchronous anyway since the name resolving happens as a Javascript function call. It just happens that this is mapping to actually system code internally.

Regards

Marcel