On Sat, Oct 26, 2019, at 8:24 PM Hal Murray <hmur...@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-...@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.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
