REFCLOCK rises again

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> >> My strawman for REFCLOCKD is something like the touring test.
> >> You can't tell the difference by poking around with ntpq.  (Maybe
> >> you don't get to poke too deep.)
> 
> > It'd need its own UDP port. 
> 
> I don't understand.  All I was trying to say is that splitting out the 
> refclock drivers to another process shouldn't make any difference that is 
> easily visible.

Maybe. The devil is in the details.

I expect some issues around Mode 6.  We'd still need to exchange
control packets with it to query and set clock variables.

> > I like Unix named pipes for this kind of scenario.  They're very
> > straightforward, no buffering or hidden magic, no interaction with the
> > network code (thus no possibility of remote exploits), and an ironclad
> > atomicity if you keep your writes 512 bytes or below.
> 
> Sounds good.  I suspect the hard part will be coordinating 
> start/stop/crash/recovery.
> 
> How do we get 2 processes to read the same data?

We don't. Why do you expect to need this?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.