search

pymeasure / leco-protocol

Design notes for a generic communication protocol to control experiments and measurement hardware
https://leco-laboratory-experiment-control-protocol.readthedocs.io
MIT License
6 stars 3 forks source link

Separate Component for data and log proxying? #36

Closed bilderbuchi closed 1 year ago

bilderbuchi commented 1 year ago

@bklebel raised an interesting point against having the Coordinator unity control, data and logging channels in one Component type:

I don't think we would like to have multiple data-channel Coordinators (proxies) by design at all, e.g. with one per Node, because one big deal of having this one proxy in one central place would be for Observers to only listen at one point. Like this we do not need to start with issues like multi-hop-like distribution of the data, as we are discussing things for the control-Coordinators.

Of course, I hadn't thought of that, yet. I think I agree. We could make it so our "Coordinator" is purely about the control channel, and have another (singleton) Component be about data proxying (and maybe logging at the same time, as it's similar).

Thoughts?

_Originally posted by @bilderbuchi in https://github.com/pymeasure/leco-protocol/pull/24#discussion_r1093669975_

BenediktBurger commented 1 year ago

I always thought them separate (with the possibility to bundle log and data proxy).

bilderbuchi commented 1 year ago

Ok. Name suggestions for the Component to be added?

BenediktBurger commented 1 year ago

Zmq uses "proxy", we could call it "Data proxy" or just Proxy.

BenediktBurger commented 1 year ago

Publisher proxy is too technical, I fear.

bklebel commented 1 year ago

Well, the definition I had had in mind was, that a "Coordinator" is exactly how we have defined it on the lowest possible level:

A component primarily concerned with routing/coordinating the message flow between other Components.

Data proxies, logging proxies and control "thingies" were different subclasses of Coordinators for me, since all of them do nothing else but shuttle messages from one point to another (compared to processing them, driving Devices, directing Actors, observing data etc.). The different "channels"/"types"/"subclasses" run over different kinds of zmq socket types, since they inherently have slightly different requirements (data does not need answers etc.), so we need different types of Coordinator instances for the different channels.

Our use of the term "Coordinator" in #27, #33, #34, #22, #4 and others mostly concerned the "control-channel Coordinators", which make a distributed request-reply pattern possible. I am open to rename the other channels, because then the discussions would be easier to understand, however, I think we should rather look towards the future and not the past, and name it in the most logical fashion, where for me we would have the highest level of abstraction in a "Coordinator" which is defined as shuttling any kind of messages around, and the second level of abstraction would be the classes/channels of "control", "data" and "logging". Data and logging could essentially run over the same channel as from a network-topology view they are the same type, but separating makes things easier for all parties involved, I think. It is always possible to bundle them into one process anyway.

BenediktBurger commented 1 year ago

So, we have "Data Coordinators" and "Control Coordinators" (from the respective protocol, Logs run through a Data Coordinator as well)?

bklebel commented 1 year ago

I have edited my comment for proper citing and not-citing.

So, we have "Data Coordinators" and "Control Coordinators"? Yes, I would put it like that. However, for the sake of having a clearly identifiable name, I would put it "Data-Coordinator", just to make it clear.

Logs run through a Data Coordinator as well)?

Yes and no, I guess.....yes xD The Data Coordinator and the Log Coordinator do nothing different from each other, they are just separate ports for convenience of not having to prepend every data/log message with a separate type, so that e.g. something reading logs does not need to deserialize a lot of data (or look at the respective header frames we might use) just to find out it is data and not logs (and vice versa). Like this, I would hope to increase performance, and reduce implementation/development complexity significantly, while increasing the network topology complexity only slightly

BenediktBurger commented 1 year ago

Logs run through a Data Coordinator as well?

I meant, that it is from the implementation the same thing as a Data Coordinator.

From the usage, we have one instance for data and one for logs. So I think we meant the same.

bklebel commented 1 year ago

yes, okay, I agree.

bilderbuchi commented 1 year ago

I have subdivided into the 3 variants now.

bilderbuchi commented 1 year ago

Closed by #24.