<div dir="ltr"><div dir="ltr">On Sat, Oct 26, 2019, at 8:24 PM Hal Murray <<a href="mailto:hmurray@megapathdsl.net" target="_blank">hmurray@megapathdsl.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> I do not have access to a copy of POSIX and the SuSv2 seems to have SHM<br>
> support.<br>
<br>
You can probably get what you need from man pages.  Try man shm_overview</blockquote><div><br></div><div>There are links in the documentation that I should have read before<br>removing all doubt.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I'd be happy to switch to POSIX SHM, but the current code works so I don't see </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
any point in doing that until we decide what else to do in this area.<br>
<br>
Linux, NetBSD, and FreeBSD all support POSIX SHM.  How many other OSes to we <br>
currently support?  Can somebody see if they have shm_open?</blockquote><div><br></div>POSIX SHM support in a quick bit of web searching seems largely a<br>Linux and BSD derivative thing.<br><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You are worrying about the weeds when we haven't even found the forest yet.<br></blockquote><div><br></div><div>Noted, it is one of my defects.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Changing it to use say a UNIX socket would allow for simpler packet<br>
> design.<br>
<br>
That approach is worth investigating, but it adds a layer of complexity if you <br>
want to support more than a single reader.<br></blockquote><div><br></div>In that instance, I am not handling multiple readers. To handle<br>multiple readers it would have to be sent to a non-unicast address<br>(or something). Then securing things becomes an issue. Tacking on an<br><div>eight-byte trailer probably would not cut it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Why do you think it is simpler to design a packet than a memory layout.  When <br>
I want to send something like this over a network connection, I build it in <br>
memory, then call send() or one of its friends.</blockquote><div><br></div><div> Because I would not need to worry about locking, semaphores or mutexes as that</div><div>is someone-else's-problem. I could build a packet, throw it and no have to wonder</div><div>whether one process is faster, slower or roadkill.</div><div><br></div><div><div dir="ltr">On Sat, Oct 26, 2019, at 2:14 PM Dan Drown <<a href="mailto:dan-ntp@drown.org">dan-ntp@drown.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You might consider the unix socket refclock format supported by gpsd/chrony:<br>
<a href="https://github.com/mlichvar/chrony/blob/master/refclock_sock.c#L40" rel="noreferrer" target="_blank">https://github.com/mlichvar/chrony/blob/master/refclock_sock.c#L40</a></blockquote><div><br></div><div>I have looked at it and it has issues. The presumably 'secret' magic<br>value is not. The use of a double however seems to allow for the<br>accurate representation of time offsets greater than the panic<br>threshold, while allowing (what I would consider reasonable) accuracy<br>up to a few NTP eras of offset. The use of unsized (u)ints and timeval<br>means that there is the possibility of functionally different structs<br>being used on the sending and receiving ends.<br></div></div></div></div></div>