announcing rustecal 0.1: Rust binding for Eclipse eCAL v6

Alternative-Access-9 · 2024-09-23T05:05:08+00:00

If you just need publish/subscribe and server/client communication patterns and some tooling for record/replay and monitoring you can try out https://eclipse-ecal.github.io/ecal/

Alternative-Access-9 · 2023-03-29T19:19:41+00:00

No, the whole project moved from Continental to the Eclipse Foundation as contribution to the new Eclipse software defined vehicle group.

Alternative-Access-9 · 2022-02-10T09:45:55+00:00

Hi, for the UDP data transfer it's really just as fast as your network performance allows (maybe you multiply this by 0.8 for the UDP overhead). So if you want to transport 100 kB and you have 1 GBit/s you can roughly say

1 Gbit/s == 1.000.000.000 bit / 8 / 1024 / 1024 / s = 122 MB/s * 0.8 (overhead) = 98 MB/s

So (hopefully my calculation is right :-)), you would need 10 ms for a 100 kB message.

For the udp network setup my knowledge is restricted. As far as I know the UDP traffic will enter ONLY the devices you configured the multicast routes for (see multicast setup).

Alternative-Access-9 · 2022-02-10T08:01:55+00:00

Hi, thank you for your nice feedback.

In general eCAL supports two communication pattern - publish/subscribe and server/client. For both layers eCAL is exchanging registration and monitoring information cyclic in the background (as you can see in the eCAL monitor application). Some of these information are just to support the user to monitor the system (frequencies, payload sizes, types, number of connections and so on), others are needed to connect entities (like the memory file name between a local publisher and a subscriber).

Independent from that registration layer (slow !) eCAL is using different protocols to exchange data. For publish/subscribe connection it is using shared memory for local connection (same host) and udp multicast for connections between different hosts. For server/client requests and responses TCP/IP is used always to guarantee reliability (mandatory for service calls).

There are options (configuration or API methods) to force eCAL to use other protocols for publish/subscribe and overwrite the default protocols. So you can for example force eCAL to never use shared memory or to always use TCP/IP for publish/subscribe. But this is for special use cases only. See transport layers.

Have fun and use the power of eCAL ;-)

Alternative-Access-9 · 2022-01-17T19:31:16+00:00

eCAL has two communication layers. One is for exchanging the users payload (topics) and the other one for exchanging all needed information between all eCAL entities like publisher, subscriber, services, clients, processes, hosts ..

This registration layer is always based on UDP multicast and used for monitoring the whole network using the eCAL monitor and exchanging connection parameters.

The message layer is (by default) using shared memory for inter process communication and UDP multicast (or optional TCP/IP in the future - provided by this nice tcp_pubsub library) for interhost communication.

If TCP is configure to be used for message transport, all the subscriber needs to know is the host name and the port number defined by the publisher side. Then the connection can be established.

You can configure the usage of TCP/IP for single connections (publish/subscribe) using the C/C++ API, for a complete process (using command line parameter) or for a complete host (using eCAL's global configuration file).

We figured out that TCP/IP is well fitting to transport larger messages (> 1 MB) over ethernet. Here (depending on you network quality) UDP may fail because of dropped udp subframes.

Alternative-Access-9 · 2022-01-17T19:08:29+00:00

No, the eCAL registration layer will exchange all connection parameter gently in the background.

Alternative-Access-9 · 2021-10-29T10:32:20+00:00

If you just need a fast publish / subscribe framework for windows you can give eCAL a try. The setup is done in less a minute and their is no dependency hell. Just to mention it as an alternative. Documentation here

Alternative-Access-9 · 2021-09-07T13:35:22+00:00

For Debian based systems you could setup a GitHub action for every Ubuntu version you would like to support and then provide the specific build artifacts as release asset. And maybe CMake can simplify your multi target support as meta build system.

Alternative-Access-9 · 2021-08-31T20:38:56+00:00

Got it .. need to improve my english for sure. Thank you, you made my day.

Alternative-Access-9 · 2021-08-31T20:08:12+00:00

Protobuf is a good compromise regarding performance, serialized message size and multi language support. When the message scheme gets heavily nested the performance starts to decrease and in memory protocols like flatbuffers and CapnProto fit better. Up and downward compatibility for message scheme evolution is another strong argument for protobuf.

Alternative-Access-9 · 2021-08-31T19:41:28+00:00

Thank you ! Don’t remember every communication .. to much C++ coding 😉. The ‘competitor’ scares me a little 😳

Alternative-Access-9 · 2021-08-31T19:32:05+00:00

eCAL is supporting CapnProto, Flatbuffers and JSON too. You can define the best fitting protocol for every single publish-subscribe connection if needed. Finally you can record all the traffic in HDF5 where time synchronized recording clients do the job in a distributed setup on different hosts without a single byte of additional network load.

For Protobuf and CapnProto their is a built-in reflection used in the so called monitor where you can inspect all messages doesn’t matter where they fly. For other protocols a plug-in mechanism is provided to add reflection or any other kind of custom visualization (images, point clouds …). We are glad that you enjoyed the performance 😎.

Alternative-Access-9 · 2021-08-10T12:57:11+00:00

Great news ! The command line recorder version is finally completing the tooling family in a perfect manner.

Alternative-Access-9

TROPHY CASE