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

Dimitri John Ledkov dimitri.j.ledkov at intel.com
Mon Apr 13 22:55:13 PDT 2015


On 11 April 2015 at 13:41, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> 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?
>

Yes.
Yes.
No.

I only wish for system-wide WPAD support and PAC auto-parsing.

The standard started by netscape or some such, hence interpreted
javascript, and nobody came up with something more declarative /
deterministic that catched on.

> 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.
>

Well pac file is generally cached, and is static it its contents
(possibly many complex clauses if this / if that) but it's ideal to
keep it around for subsequent queries.

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.


More information about the systemd-devel mailing list