[systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Andrei Borzenkov
arvidjaar at gmail.com
Sat Apr 11 23:38:17 PDT 2015
В Sat, 11 Apr 2015 19:41:15 +0000
Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> пишет:
> 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?
I am aware of several large companies that use it, yes.
> Is there no saner standard?
>
I'm not aware of it. Alternative would be central service that answers
the same question.
> 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.
>
Those PAC files I have seen used relatively dumb URL string comparison,
at most doing wildcard domain match. I.e. they do not even attempt to
resolve anything but just take literal URL as entered by user.
> 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
More information about the systemd-devel
mailing list