Re: [chrony-dev] Runtime refclock management

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Oct 05, 2017 at 05:20:00PM -0400, Will Miles wrote:
> On 2017-10-05 5:05 AM, Miroslav Lichvar wrote:
> > I guess a completely different approach would be to allow multiplexing
> > with the SOCK driver. Multiple clients could connect to the socket and
> > each one would have a separate refclock. This could be tricky.
> 
> If I'm understanding you correctly, are you thinking of something based on
> SOCK_SEQPACKET, where chrony could accept() to get a new fd for each client,
> listen for an initial "refclock metadata" packet, then just readmsg() for
> the measurement stream?

Yes, something like that. Maybe a metadata packet wouldn't be
necessary if a refid could be assigned automatically and all refclocks
added over the socket would share the other settings.

> With a couple of the smaller fixes to start the
> refclock timers on demand, I don't think it wouldn't be too hard to build as
> a quasi-independent subsystem bolted on to the main poll layer, but it would
> definitely be a little outside the current architecture as I understand it.
> Even then, I'm not sure if it's really that much different than allowing
> general "add refclock" commands - there'd still be a master socket
> responsible for adding refclocks, just a different protocol than other
> remote client commands.   At least the permission management would be easy
> to document and understand, as the socket could be created before dropping
> root.

Right. The main advantage would be that nothing changes for other
refclocks and the behavior is consistent.

> Unfortunately for me, QNX doesn't support SOCK_SEQPACKET, and replicating
> that sort of per-client connection semantics using only SOCK_STREAM and
> SOCK_DGRAM would be a pain for sure. :(

I'm wondering if it can be done with SOCK_DGRAM alone. If clients were
required to bind their sockets, chronyd could map refclocks to the
source address, right? When a refclock becomes unreachable (it stops
sending new samples), it will be removed.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.