Already existing "big" solutions/frameworks

[bilderbuchi]

From here

We should really check what protocols have already been defined. Protocol design is hard and finicky work, and it would pay to make use of the work of those who came before. I got the feeling that we can't be the first ones concerned with this problem space.

If there is something that

• we could plug in to
• we could take a subpart and use that (e.g. because we don't need all the complexity)
• we could take as a template and adapt to our needs (I guess ZMQ majordomo falls into this)

we should take a l_ong hard look_ at reusing instead of coming up with our own stuff.

Specifically,

• What about the big distributed things like Taurus, Tango or Sardana (maybe not EPICS, as that is very old afaik)
• I think the yaq folks also spent a lot of thought on this -- maybe @untzag can advise here?
• Probably a strong contender: Bluesky. I remember bluesky making the strongest impression on me back when I wrote my own tool referenced upthread.
  • Skimming the docs makes me think that these folks have the right ideas, and there might be enough commonality to make use of. Can we maybe plug ourselves in like yaq seems to do?
  • They have understandable documentation on the message protocol, data model, HW interface
• Any others?

[bilderbuchi]

What's missing is a low entry point, many of those solutions, while powerful, are quite complicated to set up.
Bluesky would be preferable to Sardana, but those synchrotron-focused projects are not that suitable for "quickly getting started" (with a small setup) or ramping up on if unfamiliar.
Bluesky seems to focus on EPICS/Ophyd, possibly yaq is working on getting other things outside those environments to integrate.

It seems hard to get "just" the communication parts, without involving RunEngines (BlueSky), daemons (yaq), device servers (Tango), etc.

@bmoneke failed to install a working Tango installation. Tango needs C++ skills and SQL databases.

[BenediktBurger]

bluesky sends "message" objects and they are queued in the recipient. This seems a good idea to learn from.

[bilderbuchi]

There's an interesting paper "How to Design & Implement a Modern Communication Middleware Based on ZeroMQ" (https://doi.org/10.18429/JACoW-ICALEPCS2017-MOBPL05). I think it's definitely relevant to our design effort, and only a couple of pages.
One decision in the paper that we probably will decide differently (because our trade-offs are different from CERN's) is to write a serialiser themselves instead of using something like Apache Avro.

[BenediktBurger]

Thanks for that source, it is really insightful.

[BenediktBurger]

A few ideas from that paper, which might be good for us or spark a discussion:

• Separation of the transport layer and business layer (content) is a good idea.
• They used test driven development, which helped them a lot.
• They dropped a publishing scheme in favour of simplicity and it did not fit their requirement (getting to know some initial information). They are right, that you do not save on bandwidth (a published message is sent as individual messages to the recipients on the tcp backbone). It might save some programming work (a Component does not have to manage the subscribers of changes manually, as zmq does that for us). For a "data stream without beginning and end" it is great, however.
• They wrote their own serialization scheme to reduce dependencies and increase performance. (I prefer to start with a ready done serialization scheme, if possible).
• Each Component has a thread dedicated for message handling.
• Each message counts as a heartbeat
• DEALER/ROUTER socket pairs.

[bilderbuchi]

Yeah, this would ~ also have been my summary of the main points. Thank you for the excerpt!

[BenediktBurger]

Here is the COAP definition (an IoT protocol), which can serve as a language / definition reference and hints for protocol ideas:
https://www.rfc-editor.org/rfc/rfc7252

wikipedia short article: https://en.wikipedia.org/wiki/Constrained_Application_Protocol

[VigneshVSV]

Following from my comment in pymeasure/pymeasure#676

Hi, experimental physics RPC called tango-controls developer here.

Late adder, but I already have most things sorted out in my package which is based on ZMQ, with HTTP support. Its a proper RPC, with possibility of REST like design.
It already supports PUB-SUB, ZMQ's TCP, IPC & optionally HTTP.

Its pretty modern, pythonic and a good alternative for older packages coming from experimental physics world like EPICS and tango. I use a tested RPC pattern.

I am also adding support for Web of Things.

I wish to integrate with all devices you have defined here (in pymeasure). I also need some help to smoothen rough areas from people who are deep into this area and I am open to ideas.

Anybody interested?

Examples -

https://gitlab.com/hololinked-examples/oceanoptics-spectrometer

https://gitlab.com/hololinked-examples/serial-utility

[VigneshVSV]

My package's slowly upcoming doc is here : https://hololinked.readthedocs.io/en/latest/index.html

[VigneshVSV]

Just an update - If you guys are also doing RPC, I simply propose a merger.

[BenediktBurger]

Hey @VigneshVSV ,

thanks for telling about your project. It's sad to see, that another project does basically the same thing. I'm glad, that you found your way here to see, whether we could join our efforts.

Just an update - If you guys are also doing RPC, I simply propose a merger.

Yes, LECO offers RPC, we call it the "control protocol".

Don't get discouraged by the current state of the LECO protocol definitions. Most issues are sorted out, but due to personal challenges, the last details have not yet been reviewed and merged. The python implementation PyLECO is already in a stable state. In fact, we are using it in our lab for a year or more without on a daily base. It is also published on pypi (not yet on conda).

The core of LECO is the message transport among peers (called Components) in the network.

I simply propose a merger.

You're welcome to contribute to the protocol definitions (LECO), the python implementation (PyLECO), or add-ons.

Your web control sounds very interesting.

If you have questions, don't hesitate to ask.

[VigneshVSV]

I dont exactly see a double-effort as a negative thing because one still learns a lot and its better to own one's knowledge thoroughly with practice. I am open to changing stuff within my RPC/merging it, not a issue.

It would be best if we once discuss in terms of specifications of user features to see if a merger is possible because both are based on ZeroMQ. May be we can share a power point presentation to each other?

Can I write to your email ?

I heavily suggest this because the web of things paradigm has a lot of industrial players within it and no representatives from experimental physics side. Further, these industrial players themselves have a few different implementations, some commerical, some open source. Therefore its better to have some united approach from people like us. The web of things is becoming part of W3C and will likely be the future of IoT.

[bilderbuchi]

It would be best if we once discuss in terms of specifications of user features to see if a merger is possible because both are based on ZeroMQ. May be we can share a power point presentation to each other?

You can already study and compare what we have come up with on the specification side at the rendered documentation: https://leco-laboratory-experiment-control-protocol.readthedocs.io/en/latest/ :-)

[VigneshVSV]

For future reference - moved conversation to email.