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

[Marcel Holtmann]

Hi Lennart,

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

are you sure that you are not overthinking this? I think that duktape actually allows just canceling the JS engine execution, no matter what operation it runs. So you could just cancel the JS context.

Regards

Marcel