Re: Updated dataflow semantics for RTT

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-544101865-1442988859=:16193
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-ID: <alpine.DEB.2.11.1509231003541.17195@pma-15-011>
Content-Transfer-Encoding: quoted-printable

On Mon, 21 Sep 2015, Johannes Meyer wrote:

> Dear Orocos community,
> during the last few weeks we have been working on the concept and imple=
mentation of a major redesign of the Orocos
> RTT dataflow, that we would like to share and ask for your valuable fee=
dback. There was already a previous
> discussion on the mailing list about the topic earlier this year [1], a=
nd the following proposal tries to address
> all the issues mentioned there.
>=20
> With the version 2 of the Orocos toolchain some years ago, the previous=
 data flow architecture, which was based on a
> single data object and buffer shared between all ports participating at=
 the same connection, was replaced by a
> connection architecture based on data flow, where each pair of output a=
nd input ports (or streams) is connected
> through an individual channel, each having its own data object or buffe=
r. While there was a well substantiated
> motivation for this update and it solved some of the shortcomings in RT=
T version 1 [2], it also introduced some new,
> sometimes hidden, problems and broke other use cases. One example is an=
 input port with multiple connections, where
> due to the ambiguity in which channel to read from the result is someti=
mes unexpected to the user, who expects that
> each write overwrites previous samples in case of simple data connectio=
ns.
>=20
> We assembled a document (see attachment, or [3]) which introduces the v=
ersion 1 and version 2 data flow semantics
> for those who are not aware of the details, three example use cases and=
 presents the new dataflow architecture we
> have in mind, which ideally works for a superset of use cases that are =
supported by RTT version 1 and 2.=A0
>=20
> We do not want to go into details here, so only a short summary for tho=
se who do not want to read the full document:
> We propose to add two more boolean flags to the ConnPolicy struct that =
describes the type of connection between two
> ports: "shared" and "mandatory". Furthermore the existing "pull" flag, =
which was only meaningful for remote
> connections, now has a big influence for local connections.
>=20
> "push" vs. "pull"
>

Thanks for this nice effort. I think it is really time to consider a next
generation of Orocos RTT...

If you allow me to bring in my two cents... It's possible that you won't =
like the
message, or find it off-topic, but I think I should share it with you any=
way...

The best document I have read about communication that connects
high-performance with flexibility and configurability is this one:
  <https://engineering.linkedin.com/distributed-systems/log-what-every-so=
ftware-engineer-should-know-about-real-time-datas-unifying>

It cleanly separates the communication of "events" from (i) what they mea=
n,
(ii) who is interested in them, and (iii) with what policy they are consu=
med.

In our current research at KU Leuven, this is going to be _the_ basis for
all interaction between asynchronous activities.
The other basis will be the separation between (i) functional requirement=
s
of the application, (ii) "roles and responsibilities" of "components",
(iii) software components to implement both, and (iv) deployment of these
components on your hardware and OS platforms.

All of the above are not present in Orocos RTT, which I consider design f=
laws.
So solving these problems is definitely worthwhile. But, and this is a bi=
g
but, my view on solving them (which is currently being transformed into
a first set of models and code and tools) implies that we do not need
Orocos RTT at all anymore. The reasons why we started RTT more than fifte=
en
years ago have not disappeared, but have all been solved in more "mainstr=
eam"
software projects than Orocos. Fifteen years ago, what we where after was=
 a
"node-port-connector" modelling-and-coding interface, where nodes could b=
e
deployed in realtime activities on an operating system. It was the time o=
f
single core CPUs, with only proprietary solutions to fast networking. Tho=
se
days have gone, together with the need to use RTT as a software solution.

More in particular, the "communication" aspect (which is the core of the
document you distributed) is a lot better understood and supported in
mainstream than 15 years ago. Taking the model of the event log and the
corresponding log processing around it means that all the policies that
your document wants to introduce as "API" methods can (should...) better =
be
realised by configurations of the event log mechanism in your _applicatio=
n
architecture_; there is no need to provide APIs in "middleware",
"frameworks" or "libraries".

_The_ core functionalities of RTT that still survive after 15 years are:
- its introspection capabilities;
- the lock-free data buffer.
The latter is just a special case ("configuration") of the event log
mechanism, that provides all other policies that you mention (and more!)
just through other configurations.=20
The introspection is a form of "model based" implementation, which
considers models as first-class citizens in the software; this is great,
and should be extended, starting with modelling all the relevant event lo=
g
policies explicity. (KU Leuven is working on that; it takes a lot of
efforts...) Lock-free data buffers are the core of event log processing,
and are currently better known under the new buzzword "immutable data".

The other "good-intuition-that-turned-out-to-be-badly-implemented" of
fifteen years ago is that of "stored procedures" (known under various
names, such as "microservices", proxy computations, etc.). RTT provides a
very complex and ambiguous API to let one component execute code for
another component. Again, that functionality should not be provided by an
"RPC API", but by models and tools of _deployment_.

The added value of Orocos as a project could shift from providing code to
providing professional quality documentation and tutorials for "best
practices" and "patterns", some specific realtime-optimized
implementations, or patches to the large amount of existing libraries tha=
t
support alul of the above.

It is up to the Orocos community to decide whether to go that direction o=
r
not. I would be glad to cooperate in that directoion, because otherwise w=
e
will be forced to start a "competing" project.

Note that this message does not contain threats to "fork" or whatever, bu=
t
just my insights after working with Orocos RTT for about a decade, and
having Orocos RTT work against the architectural requirements in our
robotics projects for the subsequent five years...

I frankly think it is time to reinvent the project. Big time.

The easiest way is to _deprecate_ things, to make the _core_ things simpl=
er
for users, throwing out more and more code and start using other already
existing software (ZeroMQ, libevent, the lock-free buffer library,
RethinkDB,...) instead of trying to squeeze in their functionalities with=
in
NIH APIs and implementations.  In the end, RTT will be empty, and the
development efforts can then finally shift to give Sylvain a much bigger
hand with ROCK :-)
(Just make sure to refactor ROCK in order to decouple the _models_ from t=
he
  Ruby and RTT _implementations_ :-))

Best regards,

Herman Bruyninckx

> Like it is already the case for remote connections via CORBA, the "pull=
" flag will decide whether the connection's
> data object or buffer is installed at the writer's side (pull) or the r=
eader's side (push) of the connection. The
> first case is equivalent to the current version 2 connection model and =
readers have to select the connection/output
> port to read from, while for push connections there will be only one si=
ngle buffer per input port. We think that the
> push connection should be the default connection type for local ports, =
but this might break existing applications
> which rely on having one buffer per connection now.
>=20
> "private" vs. "shared"
>=20
> The shared flag reintroduces the shared data connection model that was =
standard in RTT version 1. For shared
> connections multiple input ports read from the same data object or cons=
ume samples from the same buffer instance, so
> their read operations can influence each other. Shared connections are =
especially useful for producer/consumer
> applications with multiple consumers.
>=20
> "mandatory"
>=20
> The introduction of the "mandatory" flag was necessary to decide on the=
 return value of the write() operation on an
> output port. In RTT version 2 it was not possible anymore to get a feed=
back of whether a write operation was
> successful or failed, e.g. because of a full buffer or broken remote co=
nnection. Only connections with the mandatory
> flag set would be considered for the overall result of write() operatio=
ns, while failures of non-mandatory
> connections will be ignored.
>=20
>=20
> For those who want to take a look at the current state of the implement=
ation, this is the link to the working branch
> on GitHub:
> Tree: https://github.com/orocos-toolchain/rtt/tree/updated-dataflow-sem=
antics
> Diff to master:=A0https://github.com/orocos-toolchain/rtt/compare/maste=
r...updated-dataflow-semantics
>=20
> The implementation is not fully working yet for non-standard transports=
 (like Corba and mqueue), but especially the
> updated test ports_test.cpp already shows what would change from a user=
 perspective.
>=20
> Obviously, such a major refactoring cannot be done without changes in t=
he public API. However, we tried to keep the
> required changes in user code as minimal as possible.
> The new dataflow semantics are targeted for an upcoming version 2.9 rel=
ease (or even name it 3.0 to communicate this
> potentially breaking change?).
>=20
> We are planning to also come up with some comparative performance measu=
rements during this week, as people have
> asked for that before [1].
>=20
>=20
> Best regards,
> Johannes and Peter
>=20
> [1] http://www.orocos.org/forum/rtt/rtt-dev/limitations-v2-port-impleme=
ntation
> [2]=A0http://www.orocos.org/wiki/rtt/rtt-2.0/dataflow
> [3] https://docs.google.com/document/d/1zDnPPz4SiCVvfEFxYFUZBcVbXKj33o4=
KaotpCtXM4E0/pub
>=20
>=20
>
--8323329-544101865-1442988859=:16193
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

--8323329-544101865-1442988859=:16193--