Thread: Data Stream for Proxy Process Communication

Hello

Given the requirements below; what input/output method should be used?
A linux process will operate as a proxy between a mounted GPS device and a NTPD (Network Time Protocol daemon). The proxy will receive commands from another linux process and send back information. These commands will be GET_GPS_DEVICE_VERSION, RESET_GPS_DEVICE and KEEP_ALIVE.

So the proxy process will need to listen/communicate between 3 things; the GPS, the NTPD and the command process. The order of operations will be; read GPS serial stream (and store message), read command process serial stream, perform command (if command != KEEP_ALIVE) and propagate GPS serial message to NTPD.

Given these requirements and considering speed and safest implementation which should be used?

• Simple serial stream - open("dev/port", O_RDWR | O_NOCTTY | O_NDELAY);
• Use a pipe?
• Use a Message Queue?
• Use sockets? Note all processes and components are on the same network and OS.
• Use shared memory (seems like overkill?)

c - Data Stream for Proxy Process Communication - Stack Overflow

I'd use potato.

No, seriously. You're asking the wrong questions. Have you checked the PPS/GPS interfaces Network Time Protocol Daemons support? An userspace proxy, with at minimum three context switches per event, is so much added unnecessary latency that nobody has seriously thought that might be useful. What next? Using your finger to get the 1 PPS / 60 BPM rhythm? You use the hardware device to get rid of the latencies, to get a better time precision, in the first place! No reason to go systemd on it from the get go!

If your GPS uses one of the supported protocols, then you only need to configure your daemon correctly. If your GPS does not use one of those, you'll have to patch your NTP daemon. If your GPS device uses an interface that is not already supported (USB, standard serial, GPIO pin) in your operating system kernel, you might have to write the device driver to let the NTP daemon can read the PPS/GPS data in the first place.

IPC mechanisms have as much relevance here as potatoes do.