rlaa...@wiktel.com said:
> >From the draft, it sounds like this might be as simple as NOT specifying a
> port on the socket, which is what other implementations do.
Unfortunately, the code isn't written that way. There is no socket for each
server. There is one for each interface. It uses
On Tue, Sep 17, 2019 at 1:23 PM Richard Laager wrote:
> On 9/16/19 6:08 PM, James Browning via devel wrote:
> > - additions to the DNS code to allow non-A/ pools. (cname/srv
> probably)
>
> Is it not following CNAMEs already? I haven't checked.
>
No, it seems not to. Also since typing that
On 9/16/19 1:33 AM, Hal Murray via devel wrote:
> Port randomization:
> https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
> I'd guess somewhere between a day and a week to implement this.
>From the draft, it sounds like this might be as simple as NOT specifying
a port on the
On 9/16/19 6:08 PM, James Browning via devel wrote:
> - additions to the DNS code to allow non-A/ pools. (cname/srv probably)
Is it not following CNAMEs already? I haven't checked.
> - less awful asccidoctor support
What's the issue here? I might be able to help.
--
Richard
> This is exactly what futexes are for.
Is there a standard recipe for using them in shared memory when the processes
using them can start/stop/crash at any time?
I see 2 problem areas. One is initializing the futex. The other is
recovering from a crash while the futex was busy. (lock
> So you are correct that some clients may use the SHM protocol in rw mode.
> Can't imagine why...
Does gpsd write in mode 0 or mode 1?
In mode 0, the reader has to turn off the valid flag so needs writing.
Mode 1 isn't solid. It's only got one counter. Clean read-only operation
needs 2
> gpsd installs gps.h, the header for libgps, in $PREFIX/include/gps.h
> I would assume similar for NTPsec: $PREFIX/include/ntpsec.h
That would work, but it shows that ntpsec owns the SHM interface.
I was trying to split it out to emphasize that ntpsec can't just change it
without a lot of
Yo Daniel!
On Mon, 16 Sep 2019 23:05:55 -0400
Daniel Franke wrote:
> On Mon, Sep 16, 2019, 22:50 Hal Murray via devel
> wrote:
>
> >
> > The disadvantage of SHM is that there is no way to wake up a reader
> > when new
> > data is available. Readers have to poll.
> >
>
> This is exactly
Yo Hal!
Let me make a quick retraction below:
> On Mon, 16 Sep 2019 14:09:45 -0700
> Hal Murray wrote:
>
> > I think we should put the current stuff on the back burner and make
> > a new SHM interface where the clients are read only.
>
> ntpshmmon, from gpsd, is already read-only on the
On Mon, Sep 16, 2019, 22:50 Hal Murray via devel wrote:
>
> The disadvantage of SHM is that there is no way to wake up a reader when
> new
> data is available. Readers have to poll.
>
This is exactly what futexes are for.
>
___
devel mailing list
Mark Atwood via devel :
> On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> > I think we should put the current stuff on the back burner and make a new
> > SHM
> > interface where the clients are read only.
> >
> > Is shmget/shmat the right API to use? I remember discussions of
> Another is that you can allow anyone on the localhost to read the SHM without
> any risk of them messing up the SHM data.
Good point.
> It is also fast since it is memory mapped. No system call overhead.
CPU cycles aren't important for refclocks. (at least within reason)
The
Yo Hal!
On Mon, 16 Sep 2019 14:09:45 -0700
Hal Murray wrote:
> devel@ntpsec.org said:
> > I'd like to see "struct shmTimme" cleaned up and move into a header
> > file for system use.. Right now it is not in any header file, so
> > clients like gpsd need their own copies.
>
> Assume we had
Yo Hal!
On Mon, 16 Sep 2019 17:42:24 -0700
Hal Murray via devel wrote:
> > Are UNIX domain sockets available on all OSes? If so, that's worth
> > considering.
>
> One advantage of the read-only SHM mode is that it supports multiple
> readers. So you could run shmmon while ntpd is also
> Are UNIX domain sockets available on all OSes? If so, that's worth
> considering.
One advantage of the read-only SHM mode is that it supports multiple readers.
So you could run shmmon while ntpd is also running.
--
These are my opinions. I hate spam.
> - a multicast DNS broadcaster for NTS.
> - additions to the DNS code to allow non-A/ pools. (cname/srv probably)
> - Additions to the DNS code to allow for mdns monitoring.
I'm not a DNS wizard. That area is slightly ugly in that the DNS work is done
in a separate thread so there is
> I always liked the idea of moving to a shm or a local socket "clockd"
> interface.
My comment and Gary's was only to clean up the existing SHM interface. No
changes outside refclock_shm.c (and whatever it takes to support a new/clean
header file)
> (Under the hood, a UNIX domain socket
-- Forwarded message -
From: James Browning
Date: Mon, Sep 16, 2019 at 4:07 PM
Subject: Re: Future directions
To: Mark Atwood
On Mon, Sep 16, 2019 at 3:24 PM Mark Atwood via devel
wrote:
> On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> > I think we s
On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> I think we should put the current stuff on the back burner and make a new SHM
> interface where the clients are read only.
>
> Is shmget/shmat the right API to use? I remember discussions of there being
> a
> wrong API but don't
I like both of those, port randomization and better transmit timing. Plus it
will make the IETF people happy.
..ѥѸђ
Mark Atwood
Project Manager of the NTPsec Project
+1-206-604-2198
On Mon, Sep 16, 2019, at 03:00, Eric S. Raymond via devel wrote:
> Hal Murray :
> >
> > Two areas to
devel@ntpsec.org said:
> I'd like to see "struct shmTimme" cleaned up and move into a header file for
> system use.. Right now it is not in any header file, so clients like gpsd
> need their own copies.
Assume we had a nice header file. Where would it live? What are the
mechanics of
Yo All!
Consider the a wishlist item as changes would be a bit jarring.
I'd like to see "struct shmTimme" cleaned up and move into a header file
for system use.. Right now it is not in any header file, so clients
like gpsd need their own copies.
Here is the current definition from attic/sht.c
Hal Murray :
>
> Two areas to consider:
>
> Port randomization:
> https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
>
> The basic idea is for the client side to use a random port number when
> sending
> packets so bad guys have a harder time attacking with junk packets if
Two areas to consider:
Port randomization:
https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
The basic idea is for the client side to use a random port number when sending
packets so bad guys have a harder time attacking with junk packets if they
can't monitor the traffic to
Hal Murray :
> -* We intend to fully support Network Time Security and to be first or
> - second interop on that standard once it is finalized. At that
> - point, older insecure authentication methods (MAC and MS-SNTP) may
> - be removed.
> +* Now that we have full Network Time Security, a
-* We intend to fully support Network Time Security and to be first or
- second interop on that standard once it is finalized. At that
- point, older insecure authentication methods (MAC and MS-SNTP) may
- be removed.
+* Now that we have full Network Time Security, a neasr-future
+ direction
26 matches
Mail list logo
