libp2p has a huge potential in manufacturing and automation, due to the high heterogeneity, in devices as well as in communication latencies and policies.
I am looking for some implementations or use cases stories in those domains, preferably with links to peers in PLCs or C-based Linux processes.
Herman
Not a direct answer to your question, but one consideration to take into account. I believe that libp2p pubsub messages do not have guaranteed delivery nor confirmation of delivery. In regards to an environment where you are communicating with PLCs and similar devices you may want to construct a messaging layer on top of PubSub to provide these services. The libp2p messaging facility is pretty amazing, but you should be aware of these constraints. Working on this issue myself.
[45.png]
K8hwS
January 9Not a direct answer to your question, but one consideration to take into account. I believe that libp2p pubsub
messages do not have guaranteed delivery nor confirmation of delivery. In regards to an environment where you are
communicating with PLCs and similar devices you may want to construct a messaging layer on top of PubSub to provide
these services. The libp2p messaging facility is pretty amazing, but you should be aware of these constraints. Working
on this issue myself.
I disagree with your suggestion: low latency and building a exactly-once
semantics on top of pub-sub are not really compatible…
Herman
Hi Herman,
I would be interested in your thoughts on why pub-sub would not be compatible for this use case. I think I understand the low latency part of your comment, but I would like to know a bit more about why an exactly-once messaging facility would be inappropriate. When I looked at the chat example on github it seemed to have this type of architecture. But I might be missing something. Any thoughts you have would be appreciated.
Patrick
[45.png]
K8hwS
January 9Hi Herman,
I would be interested in your thoughts on why pub-sub would not be compatible for this use case. I think I understand
the low latency part of your comment, but I would like to know a bit more about why an exactly-once messaging facility
would be inappropriate. When I looked at the chat example on github it seemed to have this type of architecture. But I
might be missing something. Any thoughts you have would be appreciated.
The communication requirements in some parts of “manufacturing” and
“robotics” are a lot more similar to low latency video conferencing than
pub/sub messaging: it is not so much a problem to loose some data as
long as one has the latest one available.
The simplest example is when you want to make a dashboard to follow,
remotely, the data streams inside a series of machines or robots: their
positions, currents, velocities, status flags,…
One practical example of the use case differences when concrete standards are concerned: WebRTC vs HLS.
In the latter the “customer” wants to see the full video, without holes
and is willing to wait a bit when there is a communication hickup; while
in the former you can live with missing a second or so of sound or video
if you get the latest data as soon as you get connection again.
The recent developments in libp2p, around WebRTC and QUIC, are hence
very interesting for my use cases. Of course, “manufacturing” has
Pub/Sub and Request/Reply communication requirements too, in other parts
of the systems. For example, to distribute manufacturing orders over
machines and to receive their progress updates, an “exactly once” (or
even “at least once”) delivery guarantee makes sense.
libp2p is the only one initiative (that I am aware of) that tries to
support a large variety of communication use cases in a coherent and
systematic way, with a minimum of the really relevant concepts.
Especially the focus on “mesh” topologies is interesting
for robotics/manufacturing, because many devices have only “IoT” like
communication capabilities, they move around a lot, and almost always
need to communicate only with local “peers”, that they need to discover.
Here and there, there are more powerful “edge computers”, that can be
used as the backbone of the mesh.
Patrick
Herman
Perfect, thanks so much for this more detailed response. More educated am I.
Example of implementations in manufacturing or automation contexts?
//CC @rkuhn