An interprocess network?

[Curt Carpenter]

I have six instruments connected to my PC, each with its own GUI.  Then need to talk to each other or at least to a central "control panel."  Any thoughts on a clean, memory-efficient way to implement an interprocess network?  Speed is not really an issue, but memory is.

[TRon]

Might this be a solution for your use case ?

[Warfley]

Is the memory constraint only on the devices or also on the central PC/control panel?

If it's only on the devices I would recommend the following:
Use the PC as central node communicating with all the devices and dispatching communication between them. On the nodes, only connect to the central broker, this way you only need to manage a single connection instead of n. Additionally use a lightweight protocol. MQTT was developed pretty much for that purpose. If you want something custom you can go with raw TCP or, if you need it even more leightweight, raw UDP.
Also if you need have a really slim footprint, use the raw berkley API instead of some fat OOP library (like Indy, Synapse or even ssockets), and do single threaded networking. But these are rather extreme measures.

[Bogen85]

Might this be a solution for your use case ?

I could be wrong, but that does not appear to cross machine boundaries.

[silvercoder70]

+1 to what Warfly said.

I used to use Indy sockets (TCP) between clients and servers to display stats for call records and was effective. Of course, this does depend a little on the amount of data you are sending.

[MarkMLl]

Might this be a solution for your use case ?

I could be wrong, but that does not appear to cross machine boundaries.

I could be wrong, but I'm not sure OP asked for that: we need more info.

MarkMLl

[Curt Carpenter]

Each instrument connects to my PC via either a usb cable or wifi.  When in use, each has its own "control panel" window present on the PC monitor screen to allow manual instrument settings and readings.  I want to be able to control and coordinate all of the instruments from a single script, sending settings to some instruments and reading data from others in response.  The PC is inherently the physical "hub" in a hub-and-spoke topology, so fits the configuration described by Warfrey.

At some point, I would like to move the whole instrument platform to something like an RPi or Beaglebone (which Lazarus/FPC makes pretty easy to achieve), so my memory concerns are looking ahead to the limited resources on those SBCs.  I have no control over the memory in the individual instruments. 

Most of the IPC solutions I've looked at seem overkill to my needs (eg. SimpleIPC).  Been looking at FCL-net ssockets using localhost, fcl-net TUnixServer and pipes. 

[MarkMLl]

Each instrument connects to my PC via either a usb cable or wifi.  When in use, each has its own "control panel" window present on the PC monitor screen to allow manual instrument settings and readings.  I want to be able to control and coordinate all of the instruments from a single script, sending settings to some instruments and reading data from others in response.  The PC is inherently the physical "hub" in a hub-and-spoke topology, so fits the configuration described by Warfrey.

So each instrument is fully programmable with an IP stack etc., and you can put an MQTT client on it?

MarkMLl

[alpine]

You could try this: https://gitlab.com/-/snippets/4782633
It's a component I wrote once, not documented - sorry for that. It can be configured as client or server. The messages are short text messages with a single characters for prefix, suffix and a field separator. Raw sockets used for transport. If you find it suitable I can write some more meaningful comments for it.

[Curt Carpenter]

So each instrument is fully programmable with an IP stack etc., and you can put an MQTT client on it?

No, most of them have their own OEM-invented API's via USB-serial physical layer or worse.  The Wifi hardware I have connects via an ESP8266 (UDP to serial MODBUS).
Each different device needs its own specific Lazarus PC GUI.  Connecting the GUIs into a network is the problem I've been investigating. 

You could try this: https://gitlab.com/-/snippets/4782633
It's a component I wrote once, not documented - sorry for that. It can be configured as client or server. The messages are short text messages with a single characters for prefix, suffix and a field separator. Raw sockets used for transport. If you find it suitable I can write some more meaningful comments for it.

 
,
Thanks for the code, I will study it.  The approach I've been fooling around with right now is using the FCL-net "ssockets" unit in the sort of topology  Warfley described.   Low memory requirements and very simple, but not much in the way of performance (thinking pipes might be better).  Whole project is strictly for personal interest.  I have Lazarus-based control panels for all my gear now, but want to generalize combining them into bigger systems.

[MarkMLl]

So each instrument is fully programmable with an IP stack etc., and you can put an MQTT client on it?

No, most of them have their own OEM-invented API's via USB-serial physical layer or worse.  The Wifi hardware I have connects via an ESP8266 (UDP to serial MODBUS).
Each different device needs its own specific Lazarus PC GUI.  Connecting the GUIs into a network is the problem I've been investigating. 

I thought that's what you were asking: it's basically how to set up communications between the various GUI-based programs that are talking to the proprietary instruments.

Within the context of a single controlling PC you could (as somebody has already suggested) use the IPC unit, or UDP (or unix-domain sockets) since packet loss would be unlikely.

Or you could (as suggested by somebody else) use MQTT, although I've never looked at the Pascal API. Or (and this would probably be my favourite) you could use a database backend: PostgreSQL and Firebird both have asynchronous notification mechanisms that allow a program to alert its peers that something needs attention, I use that for a program suite running on multiple systems where I want changes made by one to propagate to others.

Coincidentally, I'm currently in the middle of some maintenance of a number of instrument-support programs of the type that you've got. As standard they can run either as text- (easily backgrounded) or GUI-based programs, I grafted in SCPI support years ago but only when not using a GUI. I don't think that's directly relevant, other than to suggest a modicum of common interests and experience.

MarkMLl

[cdbc]

Hi Curt
Posted in your other thread, but I'll just repeat here...
If you're still looking, then maybe you should have a 'LookSee' HERE, as this might just be what you're after...
Regards Benny