> > Just to conclude this thread, I wanted to share that I found an example > program in the 7-17-2016 Unix(7) manual page that uses the newer > SOCK_SEQPACKET socket types. My older 2012 manual page does not. I don't > mind feeling old, but I like to think I still know something, so I'll > sleep well tonight and brag to my wife tomorrow. > > The example even calls the exchanged messages "commands" so the Linux > experts are thinking like us, or maybe more like you. > You are talking about this one: http://man7.org/linux/man-pages/man7/unix.7.html This is a great example. There are conventions used there, in the spirit of what I was talking about. The server expects keywords, like DOWN and END, and will pass if anything is garbled. This is typical of an example with no error-checking beyond the null-terminated string, etc. (Essentially, there is no protocol when you are writing your own software for your use or tests.) Inter-process communication, as was mentioned in that man page, is also done with pipes through the file-system. There are pros and cons to this. There is also shared-memory type communication with the "RAM drive" that is typically in a mount-point like /dev/shm. In the case of pipes, you write to a pipe and you read from the other side. The process is FIFO and you will need some system call like "select()" to monitor a file pointer. There are also pipes that stay within a memory space so that threads can talk to eachother in the same way. I use this for my audio sequencer software to get real-timeness on POSIX thread communication where one thread manages the hardware via ALSA and another thread generates sounds to fill a buffer. Here is a snippet from my software: read(seq->pipep[0], cmd, (size_t) 4); if(strncmp(cmd,"QUIT",4) == 0) icmd = -1; if(strncmp(cmd,"WAIT",4) == 0) icmd = 0; if(strncmp(cmd,"PLAY",4) == 0) icmd = 1; switch(icmd) { The above code reads from the pipe, identifies one of three expected commands, and reacts (with the "switch" block of statements). It is triggered from the outcome monitoring of the pipe determines in the following statements: /* keep monitoring the pipe for a command from the master */ FD_ZERO(&rfds); FD_SET(seq->pipep[0], &rfds); nfds = seq->pipep[0] + 1; iret = select(nfds, &rfds, (fd_set *) NULL, (fd_set *) NULL, &stv); This method would work really well for real-timeness and your data acquisition needs. The timeout for the select() can be set given a gettimeofday() call that is used to try and maintain a constant rate. You need to do the thinking there on how this can work for you. I hope this helps, hence the long reply. One last thought regarding your automation discussion and for your information. You can do a lot with fully programmable OS type controlers based on the Raspberry Pi and the I2C functionality/protocol. (I love the Pi for a lot of reasons, mostly its price for a fully functioning computer.) Most components you need for sensors and automation can be had with I2C support built-in. It is a client-server protocol that is an industrial standard and it is well supported under Linux. Pythoners can use it via Python bindings to I2C, which is great, and that is how your Pascal code can probably interface well via a Python interface and a file- or pipe-based setup. Look it up.