What are some choices for producer-consumer protocols?

[Reds]

I have a LabVIEW application that produces a continuous stream of binary measurement data. Right now, this measurement data streams into a LabVIEW notifier, and multiple "listeners" can "subscribe" to that data and monitor what is happening. Both the producer (publisher) and consumers (subscribers) are all native to LabVIEW right now, so it  all works great with LabVIEW notifiers.

But, now I want to have a non-LabVIEW listener. What to do?

The semi-obvious choice would be to switch the code so that the data would be streamed on TCP/IP instead. But what higher-layer protocol would you want to use for that? It seems to make like the RESTFul and gRPC models are more client-server oriented. I want something this a very loosely couple producer-consumer model, where you have one producer and any number of listeners.

What are some good candidates?

[ensegre]

Redis is certainly high performance and suited to multiple, loose writers, readers and subscribers, with bindings for so many ecosystems. One of its several features, which I haven't perused, are Streams. I'd be curious too to know whether continuous cross-app data streaming could be efficiently implemented using them.

Edited yesterday at 08:15 AM by ensegre

[Antoine Chalons]

I would suggest rabbitmq, i want(ed) to present it at a LabVIEW user group (LUGE) but haven't done it yet.

It's very powerful.

I use redis and did a quick presentation (in french) at LUGE recently, i haven't used the stream feature though, I only used it as cache.

 

[ShaunR]

QUIC

Edited 2 hours ago by ShaunR