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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 10, 2015 at 03:17:37PM +0300, Tomasz Bursztyka wrote:
> Hi,
> 
> 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.

Zbyszek