shallow thoughts on SHM

[James Browning]

On Sat, Oct 26, 2019, at 8:24 PM Hal Murray <hmurray at megapathdsl.net> wrote:

>
> > I do not have access to a copy of POSIX and the SuSv2 seems to have SHM
> > support.
>
> You can probably get what you need from man pages.  Try man shm_overview


There are links in the documentation that I should have read before
removing all doubt.


>  I'd be happy to switch to POSIX SHM, but the current code works so I
> don't see

any point in doing that until we decide what else to do in this area.
>
> Linux, NetBSD, and FreeBSD all support POSIX SHM.  How many other OSes to
> we
> currently support?  Can somebody see if they have shm_open?


POSIX SHM support in a quick bit of web searching seems largely a
Linux and BSD derivative thing.


> You are worrying about the weeds when we haven't even found the forest yet.
>

Noted, it is one of my defects.

> Changing it to use say a UNIX socket would allow for simpler packet
> > design.
>
> That approach is worth investigating, but it adds a layer of complexity if
> you
> want to support more than a single reader.
>

In that instance, I am not handling multiple readers. To handle
multiple readers it would have to be sent to a non-unicast address
(or something). Then securing things becomes an issue. Tacking on an
eight-byte trailer probably would not cut it.


> Why do you think it is simpler to design a packet than a memory layout.
> When
> I want to send something like this over a network connection, I build it
> in
> memory, then call send() or one of its friends.


 Because I would not need to worry about locking, semaphores or mutexes as
that
is someone-else's-problem. I could build a packet, throw it and no have to
wonder
whether one process is faster, slower or roadkill.

On Sat, Oct 26, 2019, at 2:14 PM Dan Drown <dan-ntp at drown.org> wrote:

> You might consider the unix socket refclock format supported by
> gpsd/chrony:
> https://github.com/mlichvar/chrony/blob/master/refclock_sock.c#L40


I have looked at it and it has issues. The presumably 'secret' magic
value is not. The use of a double however seems to allow for the
accurate representation of time offsets greater than the panic
threshold, while allowing (what I would consider reasonable) accuracy
up to a few NTP eras of offset. The use of unsized (u)ints and timeval
means that there is the possibility of functionally different structs
being used on the sending and receiving ends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20191027/5db272bb/attachment.htm>