On Sat, 11.04.15 19:41, Zbigniew Jędrzejewski-Szmek (zbys...@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? Yes, it's kinda necessary. PAC is pretty widely used in corporate setting. Windows does the WPAD stuff (the protocol to discover PAD) in all its versions since a long time. In fact, it immediately issues the wpad requests as first thing when you plug in an ethernet cable, in addition to DHCP. > Are they widely used in corporate setting or something? > Is there no saner standard? Nope, not really, I fear. > > 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. Well, it's Java script code. People can just add code like "for (;;); ", and we must be able to cancel the lookup then safely. I doubt that's cleanly doable with either thread-based or event loop based solutions. I am pretty sure a worker process logic is the way to go. The worker process should get the PAC data when it is forked off, and then read FindProxyForURL data from a pipe and output the result on another, or something similar, and easily sandboxable... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel