> On 06 May 2017, at 10:00, Alexander Rössler <alexander@roessler.systems> > wrote: > > > Hedge Hog writes: > >> On Fri, May 5, 2017 at 5:52 AM, Alexander Rössler >> <mail.aroess...@gmail.com> wrote: >>> >>> >>> Am Dienstag, 2. Mai 2017 14:25:11 UTC-5 schrieb Hedge Hog: >>>> >>>> <snip> >>>> >>>> There are now several message formats that offer considerable speed >>>> advantages over Protbuf. >>> >>> So far speed has not been a problem with Protobuf. However, Flatbuffers look >>> very interesting since the API and supported languages seems similar to >>> Protobuf. On the other hand, Protobuf has a very wide adoption and is can >>> also be used for storing data. >> >> Can you elaborate on the 'storing data' requirement? >> Is this a MUST, RECOMMENDED, or OPTIONAL requirement? > Storing data is definitely an OPTIONAL requirement. > >> >> Is there a requirement that the message decoding support random reads? > Not necessarily. However, there are some messages that are relatively > big such as the status messages from mkwrapper. The concept Machinetalk > uses is incremental and full updates to sync the state. The only > requirement that arises from this concept is that it must be possible to > detect optional fields which are not set. On the other hand, a different > message design might also solve this problem. > >> >> If not I'd lean toward SBE for speed. However it does bring with it >> some version constraints - from memory - new fields have to be added >> at the end of the existing version. Happy to stand corrected. >> >> Anyway, I *think* that MK/T messages are sufficiently small that >> random reading is not a MUST have requirement? > It depends on how the user design the messages of a MT procotol. > >> >>>> In fact I wonder if it isn't possible to simplify MK by replacing ZeroMQ >>>> and Protobuf with something like Cap'n Proto, >>>> Maybe ZeroMQ + Flatbuffers if the MK components are (as good as) stateless >>>> and even SBE if random reads of messages is not required? For what it is >>>> worth I think the Flatbuffers note, see [3], that Cap'n Proto has "no >>>> optional fields to allow deprecating fields or serializing with missing >>>> fields for which defaults exist" might not be all it appears to be when you >>>> review [1]. In my opinion, the feature comparison in [1] is more credible >>>> than that at [3]. >>> >>> Most of the other messaging middleware only support either RPC or >>> publish-subscribe. Machinetalk services are stateless on the server side and >>> stateful on the client side. >> >> Thanks this is very useful to know. >> >>> The use of multi-channel protocols brings some >>> additional advantages that we do not fully leverage yet. Such an advantage >>> would be to use a multicast protocol for publishing status updates >>> efficiently to multiple clients and at the same time having a reliable RPC >>> connection to execute commands. >> >> Do I understand correctly: >> - The RPC client/server is the responsibility of the language/library >> that is interfacing this. I now see that the RPC client/server events >> and states are defined in the SCXML files in the machinetalk-gsl repo >> - thanks. >> - The canonical RPC client/server implementation is in pymachinetalk? >> - Different languages will be using different implementations of all the FSM. >> >>> The only attractive alternative to >>> Machinetalk I have found so far is DDS. >> >> Interesting I had thought of DDS as an alternative ZeroMQ+ProtoBuf >> rather than Machinetalk. >> Wouldn't you still need some logic (MT) to interface 'politely' with MK? >> Anyway, even say you didn't: MT would still be needed as an API for >> which the MK community could build different implementations and link >> them > DDS indeed offers a little bit more than ZeroMQ + Protobuf. There is the > concept of global data, service discovery and some QoS > parameters. However, some might argue that DDS covers too much (such as the > QoS > parameters on the protocol level). This makes DDS really hard to use and > to take apart serialization, messaging and service discovery on its own.
Here’s a link of some time ago on a discussion on ROS2 Might be an interesting read. http://lists.ros.org/pipermail/ros-users/2015-September/069664.html http://design.ros2.org/articles/ros_with_zeromq.html > >> >>> However, the middleware is covered >>> by several software patents and encryption is only supported by >>> closed-source solutions. >> >> But if that wasn't an objection for you, could you implement the MT >> requirements using it and just link your implementtaion to MK/T. >> The closest project I can find to the MK world is the ROS 2 summary of >> the reasons to have an agnostic interface to the middleware, see here >> [1]. > Yes, ROS2 has a similar problem to solve. Writing an adapter is > definitely one way to achieve an abstraction from the middleware and to > make it agnostic of the actual implementation. > >> >> My understanding is that right now MT is tightly bound to the one >> implementation? >> If that is correct, are there any plans to changes this? > Thanks to Machinetalk GSL the specification of the MT protocols is done > with a language and platform agnostic model. This makes it possible to > replace the underlying technologies easily as used for WebVCP: > http://machinekoder.com/web-uis-for-machinekit/ > ZeroMQ is replaced by socket.io/WebSockets > mDNS/DNS-SD is replaced by a REST API > > The interfacing to ZeroMQ/Protobuf/mDNS Machinetalk is done with a small > broker component. > > On the other hand we still have to construct and decode the messages. So > the implementation layer code is still depending on Protobuf. A solution > would be to abstract message serialization as well. This would lead us > to a solution such as Apache Thrift. > >> >> [1]: http://design.ros2.org/articles/ros_middleware_interface.html >> >>>> >>>> The issue seems to come down to how stateless/stateful are the different >>>> components of MK. >>>> >>>> My naive understanding is that the important parts MK are stateful. I >>>> won't by surprised to find out that is naive - kinda like that moment you >>>> were exposed to the dual representation in LP. >>>> Nonetheles I found these interesting, [1], [2]. >>>> >>>> >>>> In particular [2] was interesting for the comment that, given their >>>> targeted use cases it would make more sense to build ZeroMQ on Cap'n Proto >>>> rather than pass Cap'n Proto messages around with ZeroMQ. >>>> >>>> I might have the wrong end of the stick here.... >>>> Earlier I posted a comment that I wondered if driving and interacting with >>>> a 3D-Printer or any CNC machine wouldn't be easier/best using a FSM (if >>>> this >>>> was true Ragel was the suggested building block), >>>> If that idea isn't nuts, then I also wonder if ZeroMQ + Protobuf aren't >>>> doing together what Cap'n Proto can do alone? >>>> Again I have little insight into how much method chaining there is between >>>> MachineTalk mediated components, so the benefits may not outweigh the costs >>>> of switching. >>> >>> Again, RPC won't cut it. >> >> Can you elaborate on this, or point to where this is elaborated on? >> I see we need a RPC client/server FSM, so RPC in that FSM context must >> mean something different? >> More on this below. > Yes, it adds hearbeating/keep-alive to the ZeroMQ Router/Dealer > messaging pattern. ZeroMQ supports this feature only for TCP as > transport protocol. > >> >>> Most of the interesting features of Machinetalk >>> (such a synchronization between clients) are the result of using >>> publish-subscribe to notify clients/subscribers instead of polling for >>> status changes. >> >> Is this client synchronization requirement different from this >> requirement (from part 3 of your MT explained blog series): >> >> <quote> >> Idempotent Connect and Reconnect >> Components shall be able to connect and reconnect to a running system >> without requiring a full restart of the real-time stack. This >> requirement supposes that the transport stack provides measures to >> detect disconnects and connects to nodes to allow state >> synchronization of components if necessary." >> </quote> >> >> Also you state there: >> >> <quote> >> ZeroMQ does partially support idempotent connect and reconnect. It >> automatically handles reconnects of sockets However, ZeroMQ does not >> provide measures to detect, disconnects and reconnects of peers. >> Therefore, Machinetalk uses an extra heartbeat and connection state >> detection mechanism. >> </quote> >> >> My understanding is that this heartbeat/pulse monitoring is done by >> the RPC client/server state machines. >> Is that understanding correct? > Exactly. > >> >> Again, your time and effort in responding is appreciated. >> >> Best wishes >> Hedge >> >> <snip> > > > -- > Alexander > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to machinekit+unsubscr...@googlegroups.com. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
