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 s
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 sock
> 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 locked
> 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 cou
> 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 th
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 wha
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 SHMs
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
dev
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 ther
Yo Hal!
On Mon, 16 Sep 2019 19:50:24 -0700
Hal Murray wrote:
> CPU cycles aren't important for refclocks. (at least within reason)
Yup.
> The disadvantage of SHM is that there is no way to wake up a reader
> when new data is available. Readers have to poll.
Good point.
I'd like to cleanup
> 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 disadvantage
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 a
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 runni
> 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.
> 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 or
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 rem
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 consider:
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 getting
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 they
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 neas
22 matches
Mail list logo
